Re: [PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks.

Daniel Barkalow
2007-10-24T04:58:57Z

On Tue, 23 Oct 2007, David Miller wrote:

>
> The forthcoming patches are also available from:
>
> kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
>
> and clean up the handling of the common quirk wherein setting
> INTX_DISABLE will mistakedly disable MSI generation for some
> devices.
>
> For devices without that problem, we want to keep the pci_intx() calls
> in drivers/pci/msi.c because those help protect against devices
> with the opposite problem. Such devices always generate INTX
> interrupts even when MSI is enabled, unless INTX_DISABLE is set.
>
> Michael, please pay special attention to patch #3. I think I
> picked the correct PCI device IDs to match for the quirk
> (5714* and 5780*) but it's possible we might need more elaborate
> checks here. It at least worked properly for the chips in my
> Niagara system.

I'm not sure all of the pci_intx() calls in msi.c should be skipped when
the quirk applies; I think some of them might be there so that the legacy
interrupt won't be delivered while MSI is turned off (since the handler
isn't listening for the legacy interrupts). I'd guess this would cause
people to have their MSI-capable device kill their non-MSI-capable device
when they restore their laptop (and the shared interrupt fires and gets
stuck at just the wrong time). No idea if this is a real concern, but I'm
pretty sure that not all of those calls are recent.

> In addition to the Tigon3 cases, I added quirk entries for the
> SB700/800 SATA chips and the IXP SB400 USB controllers.

There's a couple of ATA drivers that look like they might be trying to
work around the same bug, but it's a bit hard to tell. It might be good to
have them use the quirk (or set the flag) because it's cleaner.

-Daniel
*This .sig left intentionally blank*