Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sergey Vlasov wrote:
I still do not understand what will break in this case - won't the
external device just ignore the value which the quirk will write into
its PCI_INTERRUPT_LINE register?

Can someone point me at examples of breakage caused by the original
quirk matching non-builtin devices?  The examples of breakage caused by
missing devices are everywhere now :(

I know relatively little about PCI, so I'll leave this for someone else to answer. I'm just looking to find an acceptable solution which will allow these VIA SATA users to be able to boot again...

Now this changelog is obviously wrong...

Yep, forgot to update/remove it after the original patch.

This table is even more incomplete than the original.  I found these ISA
bridge IDs from VIA in my copy of pci.ids:

        0586  VT82C586/A/B PCI-to-ISA [Apollo VP]
        0596  VT82C596 ISA [Mobile South]
        0686  VT82C686 [Apollo Super South]
        3074  VT8233 PCI to ISA Bridge
        3109  VT8233C PCI to ISA Bridge
        3147  VT8233A ISA Bridge
        3177  VT8235 ISA Bridge
        3227  VT8237 ISA bridge [KT600/K8T800/K8T890 South]
        3287  VT8251 PCI to ISA Bridge
        3337  VT8237A PCI to ISA Bridge
        8231  VT8231 [PCI-to-ISA Bridge]

The major problem with this approach is that this PCI ID list will
inevitably get stale, and there will be no easy way to boot the kernel
on a newer system.  And there is no sign that VIA turns away from their
habit of using PCI_INTERRUPT_LINE for IRQ routing...

However, what about triggering the quirk on any ISA bridge from VIA:

	{
		.vendor 	= PCI_VENDOR_ID_VIA,
		.device		= PCI_ANY_ID,
		.subvendor	= PCI_ANY_ID,
		.subdevice	= PCI_ANY_ID,
		.class		= PCI_CLASS_BRIDGE_ISA << 8,
		.class_mask	= 0xffff00,
	}

Sounds sensible, but has the disadvantage that we'd be running on all future VIA hardware, even if they fixed it. The original quirk code also has this issue, but it could be argued that the current ID list does not.

That said, I'm happy to write and test a new patch with your suggestions, if it would be acceptable to Greg/Jeff.

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux