On Fri, 14 Aug 2015, Peter Chen wrote:
> > In the old days, a single device could be a USB host controller and
> > nothing else. Then later, a single device could be either a host
> > controller or a device controller. Now a single device can be both.
> >
> > Obviously this causes problems for our original design, where the
> > device's drvdata stored a pointer to the hcd structure or the udc
> > structure.
> >
> > In principle, the drvdata should point to something that contains
> > pointers to both the hcd and udc structures. Maybe also an otg
> > structure. That would require a lot of changes to existing code but it
> > might be worthwhile.
> >
>
> Yes, the core device drvdata should contain standard hcd, gadget,
> otg structure together. Currently, the gadget is child device
> for core device, it is reasonable the same for hcd, and we can
> create device for chipidea host to achieve it. The dwc3 driver
> does the similar things.
>
> Below is the reference device hierarchy for current IP driver:
>
> Glue Layer Device
> |
> |
> |
> IP Core Device
> |
> |----|----|
> | | |
> Gadget hcd otg
>
> Alan/Felipe, what do you think?
That's not quite what I had in mind. I was thinking of something more
like this:
Platform device ---- drvdata ----> struct usb_pointers
|
|
|-------|-------|
| | |
gadget hcd otg
where struct usb_pointers (maybe you can think of a better name) looks
like this:
struct usb_pointers {
struct usb_hcd *hcd;
struct usb_gadget *gadget;
struct usb_otg *otg;
};
If you want, you can use your IP Core device in place of my platform
device. All that matters is that the parent device of the root hub
(for hosts) or gadget (for peripherals) should store the address of a
usb_pointers structure in its drvdata.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
