Re: MSI fix for buggy PCI/PCI-X hardware

[Jeff Garzik]

Nakajima, Jun wrote:
> How about the default behavior? I'm not a fan of disable_msi(), because
> we need to update the driver as we find problems, and we cannot predict
> which PCI/PCI-X devices in the world have such a problem, although we
> know some will. The workaround in drivers/pci/quirk.c is much better,
> compared to modifying the driver, but we still need to update the file
> (and rebuild the kernel) as we find problems.

Agreed.

That's the pain of buggy hardware.  The solution is to not produce buggy 
hardware ;-)  Failing that, it is unavoidable that the kernel would need 
to be updated to notice or work around buggy hardware.  That's precisely 
the reason for quirks/dmi_scan existence:  the special cases.  Special 
cases are never easy or enjoyable to maintain ;-)


> In my opinion, we might want to use drivers/pci/quirk.c to blacklist PCI
> Express devices if any (hope not). For PCI/PCI-X devices, we might want
> to enable MSI once verified for it. To that end we can also use
> drivers/pci/quirk.c to whitelist them (or it's abuse?). That way we can
> avoid situations like "it hangs, it does not get interrupts", "disable
> ACPI, oh no, MSI".


Five points here:

1) If we did that with ACPI, you guys would have only recieved a 
_fraction_ of the feedback you received.  IMO we want to turn on MSI 
(where supported), and see what breaks.  It _should_ work, otherwise the 
hardware guys wouldn't have put MSI on their PCI device :)

You'll never get feedback and testing if it's turned off by default.

2) MSI is more optimal than standard (should I start calling them 
legacy?) x86 interrupts.  And I think they're just plain cool.  So of 
course I will push to default MSI to on!  ;-)

3) I think this view is colored by "right now".  The current MSI errata 
may be worrying you, but...   MSI is the future.  If you choose to 
whitelist, then you're creating a maintenance nightmare for the future. 
 You would have to qualify _every_ MSI device!  Think how much it would 
suck if we have to do that with PCI devices today.

Furthermore, a whitelist unfairly punishes working MSI hardware and 
perhaps unfairly highlights a few key vendors at the start ;-)  This is 
why I like blacklists.

Broken hardware is a special case, and not something we should invest a 
whole lot of time worrying about.  _Assume_ the hardware is working, 
then deal with the cases where it isn't.  _That_ is the Linus Torvalds 
model of an optimal system (IMO :))

4) I have a real-life example:  tg3.  The BroadCom 57xx chips are 
MSI-brain-damaged.  So we unconditionally program the hardware in 
non-MSI mode.  No special APIs needed at all.

5) Another option is to enable MSI only for devices which call 
request_msi().  This idea follows the current model of 
pci_enable_device():  PCI resources and interrupts are guaranteed to be 
assigned and set up only after a successful call to pci_enable_device(). 
 Then, later on, the driver will call request_irq(), which will unmask 
the irq (if it's not already shared).  Continuing this model, a driver's 
call to request_msi() would signal that MSI is to be enabled for that 
device....  and ensure that the PCI core does not unconditionally enable 
MSI for any device outside of request_msi() call.

	Jeff



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