public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@gentoo.org>
To: Sergey Vlasov <vsu@altlinux.ru>
Cc: Jeff Garzik <jeff@garzik.org>,
	greg@kroah.com, akpm@osdl.org, cw@f00f.org, harmon@ksu.edu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list
Date: Fri, 14 Jul 2006 14:20:19 +0100	[thread overview]
Message-ID: <44B79A13.4020905@gentoo.org> (raw)
In-Reply-To: <20060714165100.6950813a.vsu@altlinux.ru>

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


  reply	other threads:[~2006-07-14 13:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-14  9:52 [PATCH] Add SATA device to VIA IRQ quirk fixup list Daniel Drake
2006-07-14 11:08 ` Jeff Garzik
2006-07-14 11:40   ` Daniel Drake
2006-07-14 11:51     ` Jeff Garzik
2006-07-14 12:15       ` Daniel Drake
2006-07-14 12:51         ` Sergey Vlasov
2006-07-14 13:20           ` Daniel Drake [this message]
2006-07-14 14:43       ` Andrew Morton
2006-07-14 15:42         ` Chris Wedgwood
2006-07-14 16:01           ` Scott J. Harmon
2006-07-14 16:17           ` Daniel Drake
2006-07-14 16:16             ` Chris Wedgwood
2006-07-14 16:24             ` Daniel Drake
2006-07-14 16:33               ` Chris Wedgwood
2006-07-14 16:51                 ` Daniel Drake
2006-07-14 16:48               ` Sergio Monteiro Basto
2006-07-14 17:06                 ` Daniel Drake
2006-07-14 17:21                   ` Sergey Vlasov
2006-07-14 15:46         ` Sergio Monteiro Basto
2006-07-14 16:13           ` Chris Wedgwood
2006-07-15  0:10             ` Sergio Monteiro Basto
2006-07-16 14:09         ` Daniel Drake
2006-07-16 18:31           ` Greg KH
2006-07-17  0:34             ` Chris Wedgwood
2006-07-25  4:40               ` Andrew Morton
2006-07-26  0:42                 ` Alan Cox
2006-07-26 12:45                   ` Sergio Monteiro Basto
2006-07-26 13:59                     ` Daniel Drake
2006-07-26 14:06                       ` Sergio Monteiro Basto
2006-07-26 14:31                         ` Daniel Drake
2006-07-26 15:11                           ` Sergio Monteiro Basto
2006-07-26 22:14                           ` Sergio Monteiro Basto
2006-07-14 23:58   ` Chris Wedgwood
  -- strict thread matches above, loose matches on Subject: below --
2006-07-14 19:26 Brown, Len

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44B79A13.4020905@gentoo.org \
    --to=dsd@gentoo.org \
    --cc=akpm@osdl.org \
    --cc=cw@f00f.org \
    --cc=greg@kroah.com \
    --cc=harmon@ksu.edu \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vsu@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox