Re: [PATCH 1/2] acpi: bgrt: Fix the way the BGRT status field is used.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/29/2019 10:43 PM, Peter Jones wrote:
> Around 8 months *after* that discussion, ASWG (the keepers of the ACPI
> spec) had a discussion about an ECR that added both the orientation
> bits and this clarification:
> 
> - 1-byte status field indicating current status.
> + 1-byte status field indicating current status of the image.
> 
> But that change did not change the version field.  This was considered
> an erratum, though I don't have enough context to know why - my guess is
> that someone thought adding bits would be a harmless forward-compatible
> change, without thinking about how our implementation might work with
> respect to the version field or the reserved bits.

Thanks for this information.

I have been CC-ed on changes to this file after my own patch to it in 2016, and
one thing that I noticed is that the error handling code has caused multiple
issues for people; and this has happened both ways (too strict and too lax).

The approach that is useful on the most hardware seems to me the best one. But
that is probably a hard question to answer.

> I share your dismay, but I think it's now clear that these bits aren't
> intended as the status of the BGRT, but rather they merely describe the
> image it refers to.  With that in mind, it doesn't appear reasonable to
> go on dismissing the whole thing based on the reserved bits of that
> field - we can still use the image just fine.  But that's just my
> opinion :)

I imagine the counter argument goes like this: A firmware that cannot correctly
follow "must be zero", shouldn't be trusted to get the size of a potentially
large memory copy during boot correct either.

However, as long as the pro's and con's have been considered, I see no reason
to personally object to your change. My view on what real world firmwares are
actually doing is too limited to make a reasonable argument either way.

Greetings, Môshe

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux