On Wed, Jul 22, 2015 at 01:09:06PM -0400, Peter Jones wrote:

On Wed, Jul 22, 2015 at 09:53:57AM -0700, Josh Triplett wrote:

quoted

On Wed, Jul 22, 2015 at 12:40:53PM -0400, Peter Jones wrote:

quoted

BGRT can legitimately be a different version from what we support, and
that's a problem with the driver not supporting something, not an error
that needs to be surfaced to the user.

Signed-off-by: Peter Jones <redacted>

Are you actually seeing this error on a real system?  Or is this just a
theoretical concern with some future version?

Yeah, I have several systems where I see it every boot - and with
"quiet", it's the only message I see.  In all cases the version is 0,
i.e. the code was written before it was included in the standard, and
it's a version the driver legitimately does not handle.  Admittedly
these are mostly machines for developing UEFI on (including the Intel
S1200RP board with the UDK2014 B2 firmware.)  But the fact is there are
systems you can *buy* which will show this as an error, and it really
isn't an error.  It's just an earlier version than we support.

We should support version 0.  Is the structure layout and semantic the
same?  Could you submit a patch to handle version 0?

quoted

While I agree that this doesn't need to be pr_err, I don't think
pr_debug is appropriate either.  It may mean the driver needs updating,
or it may mean that a system in the wild is actually broken and has an
invalid version number.  I'd prefer at least pr_warn so that people see
it and report it, but I could live with pr_notice; that should hide it
from systems booting in quiet mode, while still having it in the log
even on non-debug kernels.

I'd be okay with pr_notice.  I'll send a follow-up.

If we can handle 0, I'd prefer to do that and then have a pr_warn for
versions other than 0 and 1.

- Josh Triplett