Hi, On Tue, Aug 23, 2011 at 08:50:55PM +0200, Sebastian Andrzej Siewior wrote: > On 08/23/2011 08:48 PM, Alan Stern wrote: > >On Tue, 23 Aug 2011, Sebastian Andrzej Siewior wrote: > > > >>>I didn't see a proposal yet. In fact, all you said was this might not be > >>>a good approach. So, if you _do_ have a better approach, please show it > >>>to us. But to me splitting the IP into its own platform_device has > >> > >>Another approach that comes to mind would be (looking from my tree where > >>this series is applied) > >>- take what is in xhci_probe() with following arguments:irq, memory and > >> reset callback > >>- everyone who wants a XHCI device (pci or platform device) would use > >> this function and provide the information. > >>- ->self.controller would be still struct device which is part of > >> struct pci_dev. However the xhci is not allowed to touch this since > >> it may be part of platform_device so only the xhci-pci may touch it. > >> This should not be a problem pm and msi-x would need a callback for > >> that. > > > >That's what I was proposing. But to make this work, I think > >xhci_probe() would have to be an exported routine that was called > >directly from the PCI or platform driver, rather than being invoked > >automatically as a platform driver's probe routine. > > So something like I did for the isp1760 where we have one driver > (-hcd.c) with several bus interfaces (-if.c)PCI, platform or OF > interface, right? > > If so, is there anything against it from your side Felipe? 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. 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). -- balbi
Attachment:
signature.asc
Description: Digital signature
