Re: kirkwood devicetree respin

On Wed, Mar 21, 2012 at 01:17:38PM +0000, Arnd Bergmann wrote:

On Wednesday 21 March 2012, Felipe Balbi wrote:

quoted

I have explained an easy way to achieve that to Alan Stern, but he did
not like it. Basically, we should add a platform_device to ehci-hcd.ko
and make ehci-{omap,mv,fsl,atmel,etc} a parent device/driver which
basically passes the correct resources and handle platform-specific
details.

That way, we could build everything together and udev would load the
correct modules for us.

For an example of what I mean, see drivers/usb/dwc3/core.c,
drivers/usb/dwc3/dwc3-omap.c, and drivers/usb/dwc3/dwc3-pci.c

While that way clearly works and can solve the problem we have
with ehci today, I think it's easier and more consistent with
other drivers to do it the opposite way, as we have recently
discussed in the context of ohci:

Make the base driver a loadable module that does not register
any struct device_driver at all, but just exports functions to
other module. The hardware specific drivers then each register
to their own bus and use the functions exported by the
main driver, with a way to override them with their own versions.

Alan suggested a variation of that where we actually export
a default "struct hc_driver" instead of the individual functions,
which has the advantage of having to export fewer symbols, but
otherwise is similar to what we do elsewhere.

See libata, sdhci, serial-8250 or xhci for examples of this way.

that is likely to work, indeed. My suggestion would make PM simpler
though and avoid some code duplication in the long run, meaning that
ehci-hcd.ko could have its own dev_pm_ops which e.g. knows how to save
EHCI's context while ehci-omap.c knows how to save OMAP-specific
context, toggle clocks, set pads in safe mode (when needed) and so on.

But fair enough, both ways would work fine.

-- 
balbi