(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) cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
