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.
In addition to the Tigon3 cases, I added quirk entries for the
SB700/800 SATA chips and the IXP SB400 USB controllers.
Signed-off-by: David S. Miller <[email protected]>
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*
From: Daniel Barkalow <[email protected]>
Date: Wed, 24 Oct 2007 00:58:45 -0400 (EDT)
> 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.
I don't think it's a real concern.
> 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.
I noticed these cases as well, and I would hope that Jeff would help
out here using the infrastructure my patches created.
On Tue, 23 Oct 2007, David Miller wrote:
> From: Daniel Barkalow <[email protected]>
> Date: Wed, 24 Oct 2007 00:58:45 -0400 (EDT)
>
> > 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.
>
> I don't think it's a real concern.
Okay, good. As long as someone more clueful than me has thought about it,
because I couldn't tell off hand.
> > 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.
>
> I noticed these cases as well, and I would hope that Jeff would help
> out here using the infrastructure my patches created.
Or coordinate with someone with the quirky hardware, yes.
-Daniel
*This .sig left intentionally blank*
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.
>
> In addition to the Tigon3 cases, I added quirk entries for the
> SB700/800 SATA chips and the IXP SB400 USB controllers.
>
> Signed-off-by: David S. Miller <[email protected]>
I'm happy with this patch series. A quirk is better than a
sledgehammer, and MSI-mode SATA is better than INTX-mode SATA :)
Jeff