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
