On Tue, 23 Aug 2011, Felipe Balbi wrote: > Personally, I don't like the idea of exporting xhci_probe() function. > This approach will also make other developers add xhci-<arch>.c files > just to call xhci-probe. Why would anyone do that? xhci-pci and xhci-platform should be sufficient. > The way I suggested, we would have the OMAP > wrapper driver (see drivers/mfd/omap-usb-host.c - that still needs quite > some love) just instantiate and add the platform_device. There would be > not a single new exported function. But if you guys wanna do it that > way, fine. Just be prepared for the same ifdeffery that we have on > ehci-hcd.c. I'm sure they will come in the long run. > > To me, this all sounds very similar to what many drivers were doing > before Thomas has finished the threaded IRQ and GENIRQ infrastructure > where we had drivers providing <drivername>_request_irq() calls to their > children. While that works, it's better to use the infrastructure we > have in kernel. > > IMHO, the same applies here. Driver core will allow us to completely > decouple these entities and have PM, probe/remove, shutdown, etc all > called automatically using the device hierarchy. IOW, we get many things > for free from driver core just by splitting these two entities (glue > layer and xhci-core). Look, we could do this equally easily by changing the platform code instead of changing the PCI code. For example, have the OMAP wrapper driver register a fake PCI device, and bind that to xhci-hcd. Then xhci-hcd wouldn't need any changes at all -- a definite plus over Sebastian's approach! In addition, all the #ifdef stuff could be removed from [eou]hci-hcd. Of course I'm not serious. The point is, what you're asking for is just as silly. But you don't seem to realize it. 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
