On Sunday 26 February 2012, Alan Stern wrote: > On Sun, 26 Feb 2012, Arnd Bergmann wrote: > > > We are doing a major rework of the ARM architecture tree right now > > to allow building multiple SoC platforms together, which has not > > been possible traditionally. The "PLATFORM_DRIVER" macro in ohci > > and ehci is one of many things standing in the way still and will have > > to be dealt with at some point. > > Is there anybody in particular who is going to attack this issue? Not the USB portion, we're still busy with more fundamental issues like conflicting header files between the various subarchitectures. > > > A little progress has been made already. We just received a submission > > > for a "generic" platform bus glue file that will be able to take over > > > the jobs of several of the existiing files. If anyone wants to take > > > this further I won't object, but I don't plan to work on it myself > > > soon. > > > > Ok, good to know. The approach of a generic glue is exactly what I > > was going to suggest. As we get to ARM platforms that are currently > > using PLATFORM_DRIVER, I will then ask people to convert the ohci > > glue to use that generic glue instead of adding another *_DRIVER > > macro to ohci/ehci. > > The problem is that several platforms have highly specialized needs > that can't sanely be handled in a single generic driver. Although a > lot of drivers can be converted over, not all of them will. Can you give an example? We have recently converted the sdhci mmc drivers in a similar way, and we have the libata drivers that have always worked in this manner. > > I'm not sure about what we should do for lpc32xx. Is that > > generic glue going into v3.4? > > That's up to Greg. At the moment it isn't used by anything, and unless > an existing driver can be converted over I'd guess it's not likely to > get merged right away. Where is that patch? Maybe I can help out by converting the PCI variants of ohci and ehci to the generic glue, because they are easy to test. > > If so, we could convert the > > pnx4008 driver to use that and abstract it in a way that works > > nicely for pnx4008 and lpc32xx. OTOH, we might just let this > > one go in as before and ask people to do it right for the next > > one. > > I don't know anything about these two platforms. If they are > sufficiently similar then it does make sense to combine the drivers > into a single file, with various platform-specific decisions made at > runtime. These decisions don't necessarily have to use a machine_is_* > kind of test (although they can); it might be simpler to do such a > test once during probe and store the result in a flag for later reuse. > Or then again, it might not since there's no obvious place to keep > such a flag... > > At the moment, switching the pnx4008 driver to use the generic bus glue > doesn't look easy. The generic code doesn't know anything about i2c. Maybe I misunderstood what the generic bus glue does then, because I would not expect that it should know about i2c ;-) I would think the generic bus glue would be a very simple library that just exports the various symbols that are defined in ohci-hcd.c and used in the bus specific driver so that the driver can be a separate module. Is it something different from that? Arnd -- 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
