Hi, On Thu, Aug 25, 2011 at 11:24:04AM -0400, Alan Stern wrote: > 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. not sure if this is a fair comment. The other way around would be exactly the same if the core ehci had been initially written for OMAP and we would be discussing about adding PCI support it, I guess. > > > 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. Don't you think they are ? Other than the very intial HW configuration all they do is provide struct hc_driver with the exact same fields. Maybe a few differences here an there, but most of them, just reuse the functions exported by ehci-hcd. > 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. 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 > 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
