On Wed, 2012-01-11 at 14:28 -0800, Sarah Sharp wrote: > On Wed, Jan 11, 2012 at 04:51:00PM +0800, Alex,Shi wrote: > > On Wed, 2012-01-11 at 16:39 +0800, Andiry Xu wrote: > > > On 01/11/2012 04:17 PM, Alex,Shi wrote: > > > >> Since this device ID is not used by anyone, you'd better put it in xhci > > > >> driver. > > > > > > > > how about to move to xhci_pci.c file as following new patch > > > > > > This looks better. > > > > > > >> > > > >> And I don't think PCI_DEVICE_ID_INTEL_USB_XHCI is a good enough name - > > > >> are you sure all the Intel xHCI host controllers will share the same PCI > > > >> device ID? > > > > > > > > I don't have better name for it. :( > > > > > > Perhaps you can use the chipset name. For example, panther point? :) > > > > Maybe. Let's wait for Sarah's comments. :) > > You do need a better name. In fact, it's already there in pci_ids.h: > > #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI 0x1e31 Thanks! > > However, you've told me that this behavior only occurs on one particular > Intel BIOS. The BIOS I have on my Panther Point board doesn't fail when > legacy PCI interrupts are enabled for the xHCI host. So I think you > need to also somehow check the BIOS or platform name, instead of turning > on this quirk for all Intel Panther Point xHCI hosts. Rui, do you has more info of this BIOS? :) If we try to enable MSI first for xhci, like others' suggestion. we may can skip this detailed device ID. > > Let's figure out internally which BIOS versions actually have this > problem, and how to differentiate between the two. Do you mean we can ignore such BIOS issue? If you can skip such problem in BIOS and make HCD with MSI work like Windows, why not? And guess there always have BIOS engineers forgetting do test for Linux. -- 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
