[U-Boot] [PATCH] usb: new board-specific USB init interface

[Marek Vasut]

Dear Mateusz Zalega,

> On 08/22/13 21:37, Marek Vasut wrote:
> > Dear Mateusz Zalega,
> > 
> >>>>> The EHCI supports multi-bus thing (passing the controller *), will
> >>>>> this be viable to pass in this case too, so the busses can be inited
> >>>>> selectively in host/gadget functions?
> >>>> 
> >>>> Hello, Marek.
> >>>> I need more context. Could you show me the part of code in which you'd
> >>>> like to pass/use additional arguments?
> >>> 
> >>> Please grep the 'controller' pointer that is passed to various
> >>> functions at least in the EHCI case. It would be nice to pass that to
> >>> the init functions too, no?
> >> 
> >> It may be possible, but note that board_usb_init() is not used solely by
> >> EHCI code (please grep or cscope function calls). In order to do that,
> >> we would need to devise some generic interface.
> >> 
> >> Is it worth the time? Are there targets that would benefit from this
> >> change?
> > 
> > In case you want to separatelly init one port for USB peripheral mode and
> > one for Host mode, yes.
> 
> We could add another argument: "int controller_index" (or maybe "const
> char* controller_id"), which would correspond to node names or aliases
> defined in devicetree source files (ie. see: tegra30.dtsi).

Device tree is completely ortogonal to this. See how "int usb_lowlevel_init(int 
index, void **controller)" is declared. Pass something similar, index at least. 
Also pass the mode in which the controller should operate.

> List of
> available controllers would be accesible via ie. "usb list" command.
> Implementations of board_usb_init() would lookup applicable hardware in
> gd_t.

DT is not present on all platforms, so you _MUST_ handle the non-DT case too.

> We would need to find a way to differentiate between these controllers
> in cases when it would be expected from u-boot to automatically
> initialize devices it needs. It looks easy in case of ehci-tegra.c.
> 
> Devicetree-agnostic boards would have their own "usb list"
> implementation, and those of them that can't initialize their
> controllers selectively would be left the way they are with just one
> additional, unused board_usb_init() argument.

Best regards,
Marek Vasut