On Thu, Nov 7, 2019 at 12:02 PM Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> wrote: > > Hi, > > On 10/25/19 1:20 PM, Bjorn Helgaas wrote: > > On Wed, Oct 23, 2019 at 12:22:05PM -0700, Olof Johansson wrote: > >> In commit eed85ff4c0da7 ("PCI/DPC: Enable DPC only if AER is available"), > >> the behavior was changed such that native (kernel) handling of DPC > >> got tied to whether the kernel also handled AER. While this is what > >> the standard recommends, there are BIOSes out there that lack the DPC > >> handling since it was never required in the past. > > Some systems do not grant OS control of AER via _OSC. I guess the > > problem is that on those systems, the OS DPC driver used to work, but > > after eed85ff4c0da7, it does not. Right? > > I need some clarification on this issue. Do you mean in these systems, > firmware expects OS to handle DPC and AER, but it does not let OS know > about it via _OSC ? The OS and BIOS both assumed behavior as before eed85ff4c0da7 -- AER handled by firmware but DPC handled by kernel. I.e. a classic case of "Sure, the spec says this, but in reality implementations relied on actual behavior", and someone had a regression and need a way to restore previous behavior. -Olof