On Thu, 25 Aug 2011, Felipe Balbi wrote: > > > > All right, try this instead: Merely because OMAP and a bunch of other > > > > SoC architectures require a bridge device between the PCI and USB > > > > layers, that doesn't mean the Intel implementation should be forced to > > > > use one. > > > > > > that doesn't mean either that Intel couldn't license the same IP the ARM > > > SoCs are licensing. > > > > Of course. And when they do, maybe adding the glue layer will be > > appropriate. Until then, it isn't. > > Are you sure they aren't already ? If they are, it hasn't affected the way the kernel interacts with the hardware, which means the kernel isn't aware of the bridge. > > In the end, this comes down to a tradeoff. Do we implement a fake > > "glue" platform device that has no real meaning in order to simplify > > some drivers by removing their need to support the PCI bus as well as > > the platform bus? Or do we keep the device model data structures > > accurate, but complicate the drivers? > > > > I can't help thinking that other subsystems have solved the same > > problem, and it might be a good idea to do what they do. The example > > I'm most familiar with is SCSI; it supports host adapters of any type. > > Following the SCSI model would mean _always_ sticking a new device > > between the controller (whether PCI or platform) and the root hub. > > The new device would belong to the USB bus_type, not the platform bus. > > Then let's add that. Bus as of today the usb_bus_type is for USB device > drivers (a USB camera, or USB Storage, etc). You would need to add some > extra bus_type for USB Host Controllers and why would you add a whole > new bus when there's already the platform bus ready to use and very well > tested ? No, not a new bus_type -- a new device_type. We already have usb_device_type, usb_intf_device_type, and usb_ep_device_type. It would be necessary to add usb_hc_device_type (or usb_host_device_type or usb_controller_device_type or whatever you prefer). The problem is that this would mean all the host controller drivers would have to be changed. I'd prefer to avoid that. With your plan, I don't see how you can hope to make a single driver source work for all the different IP blocks. Passing the resources via devicetree will help, but the different hardware implementations will still require vendor-specific code to run at various times, right? Otherwise all the ehci-*.c files would resemble each other more closely. If your main concern is getting rid of the #ifdefs in ehci-hcd.c (and preventing the equivalent from being added to xhci.c), there's a simpler way to accomplish it: Use conditional linking rather than conditional compilation. All that complexity would be moved out of the C source files and into the Makefile instead. That is, instead of obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o which is what we currently have, we could have obj-$(CONFIG_PCI) += ehci-pci.o ehci-hcd.o obj-$(CONFIG_USB_EHCI_FSL) += ehci-fsl.o ehci-hcd.o obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o ehci-hcd.o etc. 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. 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
