Matthew Wilcox <matthew@xxxxxx> writes:
>> Doesn't look wrong at first, but do notice the PCI_VENDOR_ID_INTEL in
>> the last entry. This doesn't just match megaraid devices, but anything
>> using an Intel i960 processor...
>>
>>
>> $ grep 1960 include/linux/pci_ids.h
>> #define PCI_DEVICE_ID_AMI_MEGARAID3 0x1960
>> #define PCI_DEVICE_ID_INTEL_80960_RP 0x1960
>
> So AMI/LSI already know about this problem. You can see it in the
> megaraid_probe_one function:
>
> /*
> * The megaraid3 stuff reports the ID of the Intel part which is not
> * remotely specific to the megaraid
> */
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> u16 magic;
> /*
> * Don't fall over the Compaq management cards using the same
> * PCI identifier
> */
> if (pdev->subsystem_vendor == PCI_VENDOR_ID_COMPAQ &&
> pdev->subsystem_device == 0xC000)
> return -ENODEV;
Ah, thanks. Didn't notice that.
Still, any reason why they have to do this inverse subvendor/id matching?
>> bjorn@canardo:~$ lspci -vvnns 04:00
>> 04:00.0 PCI bridge [0604]: Intel Corporation 80960RP (i960RP) Microprocessor/Bridge [8086:0960] (rev 05)
>> Kernel modules: shpchp
>
> How interesting. shpchp shouldn't attach to this bridge; it's not a
> hotplug bridge.
>
>> 04:00.1 Memory controller [0580]: Intel Corporation 80960RP (i960RP) Microprocessor [8086:1960] (rev 05)
>> Subsystem: Compaq Computer Corporation Device [0e11:c000]
>> Kernel modules: megaraid
>>
>> This is a Compaq "Remote Insight Lights Out Edition" card.
>
> I don't understand how megaraid manages to attach to that when it should
> be returning -ENODEV from the probe function as shown above.
These drivers are not attached. lspci just lists the drivers that match
hotplugwise. Attached drivers are labeled "Kernel driver in use: "
Bjørn
--
How can you be so perverted
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
