[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <314e59da-48e1-545b-3ee9-6e5056b90fd9@kernel.org>
Date: Tue, 20 Nov 2018 16:02:21 -0500
From: Sinan Kaya <okaya@...nel.org>
To: Alex_Gagniuc@...lteam.com, mr.nuke.me@...il.com,
keith.busch@...el.com
Cc: baicar.tyler@...il.com, Austin.Bolen@...l.com, Shyam.Iyer@...l.com,
lukas@...ner.de, bhelgaas@...gle.com, rjw@...ysocki.net,
lenb@...nel.org, ruscur@...sell.cc, sbobroff@...ux.ibm.com,
oohall@...il.com, linux-pci@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns
AER
On 11/20/2018 3:44 PM, Alex_Gagniuc@...lteam.com wrote:
> I'd prefer "sure" instead of "think". "I think it breaks some system I'm
> not telling you about" doesn't help much in figuring out how not to
> break said system(s).:)
Sorry, I thought I mentioned why it would break but let me repeat.
The systems I have seen rely on the HEST table presence as an indicator
to the OS that firmware first is enabled. If you go look at the _OSC bits
on such systems, it still says OS owns the AER service.
The assumption here is that HEST table has precedence over the _OSC bits.
That's what needs to be clarified in the UEFI forum.
If this code is to go in and ignore the HEST table presence, then firmware
will think that it owns AER service and OS will think that it owns AER
service too.
Powered by blists - more mailing lists