The other day, Long (Tom) posted:
During testing we have found many currently shipping
PCI/PCI-X MSI-capable devices have silicon bugs specific to
MSI support. Most of these will cause system failures when
MSI is enabled. To filter out MSI buggy hardware requires the
kernel to detect and disable the MSI support on specific hardware.
So far we've got two options based on the input from the community
(Jeff, Zwane, etc., thanks) to deal with this problem:
(1) the blacklist approach
(2) the new API (enable_msi, for example) approach
We would like to solicit more input to close this, to finalize the
solution.
Thanks,
Jun
======
"Blacklist" approach using PCI_quirks.c
---------------------------------------
Pros
- Places the burden to fix broken HW on the HW owners
- Consistent with the current MSI patch (enable all by default)
- A simple fix and minimum patch size (Patch already exists)
Cons
- Core kernel impact (larger image size)
- Added entries will require a kernel rebuild (core kernel code
change)
New API approach (enable_msi, for example)
-------------------------------------------
Pros
- Only working devices will be enabled via modification of the device
driver.
- Minimum impact (image size increase very small)
Cons
- All devices desiring MSI support will be required to modify
associated
device drivers
- Validation burden - known good devices not know until the driver is
modified and device tested
- The burden for MSI support is on devices that work and not those
that
are broken
"Nakajima, Jun" <[email protected]> writes:
> "Blacklist" approach using PCI_quirks.c
> ---------------------------------------
> Pros
> - Places the burden to fix broken HW on the HW owners
> - Consistent with the current MSI patch (enable all by default)
> - A simple fix and minimum patch size (Patch already exists)
> Cons
> - Core kernel impact (larger image size)
And worse one has to submit patches for the core kernel all the time.
And it's a single table, which means there will be lots of conflicts
when merging patches.
I think the new API approach is much better. Best would be if there
was a relatively simple standard way to add it to drivers (like a
standard module option). Then one could add it to a lot of drivers
with default to off. Users can test then and if it works the default
can be changed.
-Andi
On Tue, 17 Sep 2003, Andi Kleen wrote:
> And worse one has to submit patches for the core kernel all the time.
> And it's a single table, which means there will be lots of conflicts
> when merging patches.
>
> I think the new API approach is much better. Best would be if there
> was a relatively simple standard way to add it to drivers (like a
> standard module option). Then one could add it to a lot of drivers
> with default to off. Users can test then and if it works the default
> can be changed.
Just to add another point for the per driver/new API approach, you can
debug on a per device basis much easier whilst having MSI functioning on
other devices.
Zwane