On Fri, 30 Jan 2015, Peter Chen wrote:

> > The chipidea driver is structured in an odd way.  It looks like the PCI 
> > device combines a host controller and a device controller (and maybe 
> > even an OTG controller) into a single device.
> > 
> 
> Any problems for that?

No, but it is odd and it requires some code to be duplicated.

> > That's why the chipidea driver has to duplicate ehci-pci.c and register
> > various platform devices.  If ehci-pci were allowed to bind to the
> > device then the gadget controller (and OTG controller?) would be
> > unusable, because ehci-pci doesn't know how to use them.
> > 
> 
> If the chipidea has host function, it doesn't need any drivers at
> usb/host/ehci-*.c, the v1 patch for this thread, it just doesn't
> compile ehci-pci.c, and it should work too.

Yes, it will work.  But if you go back to the second message in this 
thread (http://marc.info/?l=linux-usb&m=142229289226237&w=2) you will 
see why that patch isn't a good idea: It means that the Intel MID 
platform cannot use a universal kernel build -- that is, one where 
every driver is included.

> Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init
> is still needed to call? The chipidea driver has already done the same
> thing in ehci_pci_init.

You're right; ehci_pci_init isn't needed.  But there's no way to 
eliminate it and still have a universal kernel build.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to