On Fri, Aug 16, 2013 at 02:22:43AM +0000, Wang, Yu Y wrote: > > On Thu, Aug 15, 2013 at 06:43:59PM -0700, Sarah Sharp wrote: > > > The xHCI platform driver calls into usb_add_hcd to register the irq > > > for its platform device. It does not want the xHCI generic driver to > > > register an interrupt for it at all. The original code did that by > > > setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not > > > enable MSI or MSI-X for a PCI host. > > > > > > Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is > > > enabled, the xHCI generic driver will attempt to register a legacy PCI > > > interrupt for the xHCI platform device in xhci_try_enable_msi(). This > > > will result in a bogus irq being registered, since the underlying > > > device is a platform_device, not a pci_device, and thus the > > > pci_device->irq pointer will be bogus. > > > > What shipping hardware has this problem today? > > > > In other words, doesn't seem like late -rc material to me. > > > > thanks, > > > > greg k-h > > [Yu:] I met this issue on Intel mobile SOC(Merrifield). But to my > understanding, this issue > should not depend on hardware. This is one software issue. > > When system enabled CONFIG_PCI and xHCI driver registered as platform > device driver. Then xHCI-plat driver will be met initialization failed.
Yes, but what "normal" system ever registers the xHCI driver as a platform driver? Does this happen today with systems? Which ones? And is Merrifield shipping in devices today (sorry, I don't know the Intel mobile codenames anymore, it's been almost a year since I saw my last Intel powerpoint presentation... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
