On Mon, 5 Sep 2011, Felipe Balbi wrote: > Hi, > > On Mon, Sep 05, 2011 at 04:48:36PM +0200, Sebastian Andrzej Siewior wrote: > > >then, let's say ehci-tegra populates that... on ehci_probe() > > >(ehci-hcd.c::probe), we could have: > > > > > >... > > > > > >ehci->ops = pdev->dev.platform_data; > > > > I know where you go with this but as of now we can't do this because > > usb_add_hcd() allocates the ehci struct. > > sure, and that is also something else that should probably change. No, no. The ehci structure is allocated by usb_create_hcd(), which is invoked before usb_add_hcd(). > > >See that ehci-tegra, would only pass the fields which it needs and if > > >the pointer is NULL the default/generic implementations are used, > > >because it's assumed that this particular architecture doesn't need > > >anything different from what the standard says. > > > > I see. So ehci_platform_ops would contain all elements from hc_driver > > it doesn't to contain all elements either. We just need, as of today, to > cope with the most "interesting" architecture we have so far. If that > means we need 5 callbacks, then we add 5 callbacks. If in the future we > need more, it's easy to patch it up. You're jumping through all sorts of crazy hoops to avoid exporting anything. It makes no sense -- why avoid using a feature if it can help solve a problem? In this case, all we have to do is export a single symbol: ehci_hc_driver. Then ehci-tegra can copy that into a private structure and overwrite whatever fields it wants. Very simple, no extra tests or redirections needed. The other ehci-<arch> drivers can use ehci_hc_driver directly when they call usb_create_hcd(). 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
