On Wed, 9 Sep 2015, Roger Quadros wrote: > (adding back folks in cc) > > On 08/09/15 20:35, Alan Stern wrote: > > On Tue, 8 Sep 2015, Roger Quadros wrote: > > > >>>> What if there is another architecture like so? > >>>> > >>>> C: > >>>> [Parent] > >>>> | > >>>> | > >>>> |------------------|--------------| > >>>> [OTG core] [gadget] [host] > >>>> > >>>> We need a more flexible mechanism to link the gadget and > >>>> host device to the otg core for non DT case. > >>>> > >>>> How about adding struct usb_otg parameter to usb_otg_register_hcd()? > >>>> > >>>> e.g. > >>>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..) > >>>> > >>>> If otg is NULL it will try DT otg-controller property or parent to > >>>> get the otg controller. > >>> > >>> This seems a lot like something Peter and I discussed recently. See > >>> > >>> http://marc.info/?l=linux-usb&m=143977568021328&w=2 > >>> > >>> and the following messages in that thread. > >>> > >> > >> If I understood right, your proposal was to add a usb_pointers data > >> struct to the device's drvdata? > > > > Right. > > > >> This is fine only if the otg/gadget/host share the same device. > >> It does not solve the problem where each have different platform devices. > > > > Why not? Each of the platform devices can store a pointer to the same > > usb_pointers structure. Wouldn't that be suitable? > > > > I didn't understand how all of them get the reference to the > same usb_pointer structure (or contents) when their respective platform devices > get created so that they can store it in their respective drvdata. > > Worst case, the 3 devices could be totally independent of each other without a > common parent, and get registered at different times. > > The common resource here is the physical USB port for which the 3 drivers > otg/host/gadget are being registered. > There should be a mechanism for each device to tell that it is part of > this particular USB port. (or usb_pointers struct) True, it's not clear how to set up the common relationship among the three drivers. But there must be some way to do it if they all are talking to the same port or PHY. The details are an issue for the platform-specific code to handle. I'm not sure what would be involved; maybe you can invent something. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
