On Thu, 25 Aug 2011, Felipe Balbi wrote: > > Then why not start making modifications to ehci-hcd by uniting all > > those different platform drivers into a single source file? You'd have > > to do that anyway; might as well begin now since it's > > non-controversial. > > > > If that can be made to work well, it will be a very strong argument for > > making PCI use a platform device too. > > Yes, that can be done. Sounds to me, though, like we will have a > duplication of effort. To see how things look like when we have a PCI > device bridging to a platform device, you just have to look into Greg's > for-next branch. The DesignWare USB3 driver which I wrote with > Sebastian follow that approach and we have PCI and OMAP glue layers. That's not what I meant. DesignWare is a single platform, but I want to see how it looks when somebody handles a bunch of platforms in a single source file. For example, is it possible to merge ehci-fsl.c, ehci-xilinx-of.c, ehci-sh.c, and ehci-omap.c into a single file without getting something that looks like Frankenstein's monster? > > > I remember proposing that long ago and Dave was against it because it > > > would make "copies" of the entire ehci stack right ? So if we had an > > > OMAP board with a PCIe controller, we would have two big ehci drivers. > > > My proposal was to reuse ehci-hcd.ko without having to link it to every > > > single ehci-<arch>.o > > > > It wouldn't have to be linked to every ehci-<arch>.o; only the one > > that the kernel is configured for. Right now you can't build more than > > one of them, right? Otherwise there would be multiple definitions for > > the PLATFORM_DRIVER symbol. > > You don't seem to get the big picture. At the end of the day we want to > have a distro-like kernel for embedded too. And that would mean e.g. > building all ehci-<arch>.o which are ARM-based plus the PCI since few > ARM-based board have PCI. Ah, that's a different matter. In fact, right now there's no way to bundle all those drivers in a single distribution, is there? I didn't realize you were concerned about this; I thought you were just bothered by all the #ifdefs. > > For that matter, why does ehci-hcd.c have separate code for registering > > OF_PLATFORM_DRIVER and XILINX_OF_PLATFORM_DRIVER? Why don't they use > > the same old PLATFORM_DRIVER symbol as everything else? > > That's a good question, but why do you think I'm the one to answer that? > I believe it would be better to send that question straight to the > authors/maintainers of those files ? Maybe even Cc yourself :-p Good point. :-) > > > > The one disadvantage would be that you couldn't have a single driver > > > > module to handle both PCI and a platform device; they would have to be > > > > separate drivers. > > > > > > true. > > > > There's also the PS3 system bus thingy -- yet another bus. > > So we _do_ agree that it's time to unify all of those, that's great. We > just need to agree on the implementation details. Yes. There is another model to consider, the one used by usb-storage. The main usb-storage module handles devices that use the standard CB, CBI, and BBB transports, but there's a bunch of submodules that handle other devices using proprietary transports. It works like this: usb-storage contains a usb_device_id table that matches the standard subclass/protocol values, and it exports routines that can be used by the submodules to do their work. Each submodule has an id table that matches only the devices it can support. The end result is that if you plug in a standard mass-storage device, the main usb-storage module gets loaded and acts as the driver. If you plug in one of the non-standard devices then the appropriate submodule acts as a driver, and the main module is also loaded in order to satisfy the export dependencies. xhci-hcd could be made to work similarly, except that there would be no "standard" driver -- there would just be a submodule driver for PCI plus one or more for various platform devices. The main module would contain only the xHCI core routines. I realize this involves an extra layer of software compared to what you want, but it might end up being cleaner -- especially if other vendors design their own USB-3 IP blocks that are not sufficiently compatible with your DesignWare code. We could handle them simply by adding another IP-specific platform-driver submodule, whereas your scheme really couldn't handle them without great difficulty. 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
