On Wed, Aug 12, 2015 at 10:45:37AM -0400, Alan Stern wrote:
> On Wed, 12 Aug 2015, Peter Chen wrote:
>
> > On Tue, Aug 11, 2015 at 09:43:13AM +0000, Barry Song wrote:
> > > From: Rong Wang <Rong.Wang@xxxxxxx>
> > >
> > > Chipidea puts ci information to drvdata, but this overwrites the drvdata
> > > placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
> > > from codes like ehci-sysfs.c:
> > > static ssize_t show_companion(struct device *dev,
> > > struct device_attribute *attr,
> > > char *buf)
> > > {
> > > struct ehci_hcd *ehci;
> > >
> > > ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
> > > ...
> > > }
> > >
> > > So overwritting drvdata from chipidea driver actually breaks a part of
> > > functionalities of EHCI core.
> > >
> > > Since the platform_data would not be accessed after the device is added
> > > to system after the probe process, so it's safe to move to platform_data
> > > here. This fix is not elegant but currently it is the quickest fix.
> >
> > Yes, it is indeed a fix, but using platform_data as driver private data
> > is not so good, let me consider if we have a better solution.
> >
> > Add Alan
> > Alan, do you have any suggestions? Currently, IP core driver and ehci
> > core both takes its internal structure as driver data. Thanks.
>
> It's not just ehci-hcd: The USB core stores the hcd address as driver
> data. usb_create_shared_hcd() does:
>
> dev_set_drvdata(dev, hcd);
>
> (The core uses this value only in usb_hcd_platform_shutdown(), but
> other platform-glue drivers also store the hcd address there.)
>
> The standard answer is to put the Chipidea private data in the
> ehci_ci_priv structure. That's what it's meant for.
>
> Is that okay for you?
Thanks, Alan. It is ok for ehci glue layer as a separate driver.
But it is not ok for the drivers like having all hcd/gadget/otg
part together, the IP core driver's suspend/resume/remove,
sysfs will use driver's private data, unless the ehci platform
device as child for IP core device, but it is not for gadget.
If there is no better solution, I will use Rong's solution.
> It might be troublesome in cases where the
> system acts as a USB peripheral only -- then you might not have an
> ehci_hcd structure at all. One solution is always to create the
> ehci_hcd; another solution is to store the Chipidea private data as
> driver data whenever you don't create the ehci_hcd. But that would
> also be difficult, because then you would have to know which case you
> were in.
>
> I'm open to other suggestions.
>
> Alan Stern
>
--
Best Regards,
Peter Chen
--
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
