On Wed, 31 Aug 2011, Felipe Balbi wrote:
> Hi,
>
> (sorry for the delay)
>
> On Fri, Aug 26, 2011 at 11:06:42AM -0400, Alan Stern wrote:
> > On Fri, 26 Aug 2011, Felipe Balbi wrote:
> >
> > > While it might possible to merge them. I think we should take smaller
> > > steps at a time. Those files are already there anyway. So at first we
> > > find a way to clean up the ifdeferry and allow all of those to be built
> > > on all archs (it's definitely possible)
> >
> > Just how did you want all these different drivers to be built? You
> > said you don't want a separate module containing an entire copy of the
> > ehci core for each arch; you want the core to be shared. That means
> > one of two things:
> >
> > Build a single monolithic module containing all the drivers.
> > This is quite likely to require a large bunch of #ifdefs.
> >
> > Build a minimal driver module for each arch, and have the ehci
> > core in a single separate module that gets loaded for
> > dependency resolution. This is likely to require a bunch of
> > exported symbols.
> >
> > Which approach are you advocating?
>
> let udev do its thing:
>
> - arch code will add a platform_device to the driver model, e.g.:
> platform_device_register(&omap_ehci_device);
>
> - based on the device add uevent, udev will load the correct module (in
> this case ehci-omap.ko)
>
> - ehci-omap.ko instantiates and add EHCI-core platform_device:
> ehci = platform_device_alloc("ehci", -1);
> platform_device_add(ehci);
>
> - based on the device add uevent, udev will load the correct module (in
> this case ehci-hcd.ko)
>
> So, there aren't only two approaches for this, can't you see ? There's
> no need for exported symbols, or a monolithic driver.
Okay, I completely misunderstood what you wanted to do. Now I've got
it. I didn't realize that you wanted to add a new platform device
child beneath the arch-specific platform device.
I'm willing to go along with the idea of adding an extra device layer
between the controller and the root hub. But I'm not so keen about
making it a platform_device. What we need here is a general usb_host
device that can be a new device_type on the USB bus, like we discussed
earlier.
Ideally this could be done in a way that allows relatively easy
conversion of the existing [eoux]hci drivers while also allowing all
the other special-purpose host controller drivers to continue as they
are with only minimal changes.
If we want to get ambitious, we could use this as an opportunity to
separate the usb_hcd and usb_bus structures. The usb_hcd should be
closely associated with the new usb_host while the usb_bus should
remain associated with the root hub. This will make Sarah very happy,
as her driver needs a good way to cope with having two buses on the
same controller. However this would require more widespread changes
and it can be put off until later.
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
