Re: [PATCH] PCI: Add quirk to clear MSI-X

[Bjorn Helgaas <helgaas@kernel.org>]

On Mon, Mar 20, 2023 at 04:37:17PM -0500, Limonciello, Mario wrote:
> > > When I say "BIOS" I mean collectively "all" of this firmware.
> > 
> > I don't understand the point you're making here.  I don't think it
> > matters whether this device-specific knowledge is in APU
> > microcontroller firmware, BIOS, Linux, etc.
> > 
> > I'm trying to suggest that if we zoom all the way in and look just at
> > the PCIe TLPs, we would see two config writes that put the device in
> > D3hot, then back in D0.  A working device should end up either back in
> > D0active with MSI-X fully enabled (if No_Soft_Reset is set and MSI-X
> > was originally enabled), or in D0uninitialized (if No_Soft_Reset is
> > clear).
> > 
> > But with this device, apparently some additional software intervention
> > is required, i.e., after the config write to go back to D0, we need
> > two more writes to clear and set the MSI-X enable bit.
> 
> My point is that's only needed if the hardware wasn't initialized correctly.
> If it's initialized properly then it behaves like you expect.

So is this something that BIOS must initialize, and then it's locked
so that by the time Linux shows up, this one-time initialization can
no longer be done?

If Linux *could* do this one-time initialization, and subsequent
D0/D3hot transitions worked per spec, that would be awesome because we
wouldn't have to worry about making sure we run the quirk at every
possible transition.

> > Let's say somebody runs coreboot on this platform.  Does coreboot need
> > this device-specific knowledge?
> 
> Yes; the exact same bug will happen with a coreboot implementation that had
> the initialization done improperly.

My claim is that this means the device doesn't conform to the spec.

If we add a conforming PCI device that neither the OS nor the firmware
has ever seen before, standard generic functionality like power
management should just work.

Bjorn