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?
Alan Stern
Sebastian
--
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
