lkml.org 
[lkml]   [2018]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
From
Date
On 11/19/2018 12:24 PM, Sinan Kaya wrote:
> On 11/19/2018 1:10 PM, Keith Busch wrote:
>>> We can't really turn off firmware first in the kernel without asking
>>> help
>>> from the firmware.
>> The _OSC method this patch utilizes is the ACPI spec defined way for
>> the kernel to wrest control from firmware. BIOS specific menu settings
>> shouldn't be our only recourse when we have a spec authority defining
>> generic OS interfaces to accomplish the same thing.
>>
>> Unless there is a disagreement on the _OSC interpreation, we'd have to
>> accept that platforms breaking from this patch are non-compliant.
>>
>
> It depends on which spec you look :)
>
> UEFI HEST table specification also claims that it should be the ultimate
> table for when PCI firmware-first should be disabled/enabled.

IIRC, EFI absorbed ACPI before FFS was a thing. Could you point me to
the UEFI chapter that says HEST is authoritative?
(not being a smartie, just that my free software PDF readers can't
search within a file that large)


> I think somebody needs to fix these. I saw an email from Harb Abdulhamid
> sent to aswg this morning.
>
> That's why I suggested circulating this idea in UEFI forums first.
> Let's see what everybody thinks. We can go from there.

However you look at it, we have a glaring inconsistency in how we handle
AER control in linux. I'm surprised we didn't see huge issues because of
mixing HEST/_OSC.

What systems rely on the HEST definition as opposed to _OSC? It doesn't
make sense to me that you could have a system with mixed FFS and native
AER on the same root port. The granularity of HEST shouldn't matter here
because of how AER works.

I'd like see how exactly we break one of those elusive systems with
_OSC. I suspect _OSC and HEST end up having the same information, and
that's why we didn't see any real-life issue with mixing the approaches.

Alex


P.S.
(SARCASM ALERT) Isn't UEFI is a pile of stuff that didn't stick to the wall?

P.P.S
I remember someone asking why we don't disable FFS in the BIOS. I think
it would be next to impossible to get certain platform vendors to
relinquish FFS control, unless the specs required things to be that way
-- and had a "standard" way to do so.

Then getting the specs to change in that direction is also a battle.

\
 
 \ /
  Last update: 2018-11-19 20:13    [W:0.073 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site