Page MenuHomeFreeBSD

stand: libefi: swap /Pci() printing around
ClosedPublic

Authored by kevans on Mar 12 2022, 5:26 AM.
Tags
None
Referenced Files
F96178649: D34539.id104946.diff
Mon, Sep 23, 11:34 PM
Unknown Object (File)
Sun, Sep 22, 3:03 PM
Unknown Object (File)
Sat, Sep 21, 12:58 AM
Unknown Object (File)
Fri, Sep 20, 8:08 AM
Unknown Object (File)
Fri, Sep 20, 5:17 AM
Unknown Object (File)
Tue, Sep 17, 9:11 PM
Unknown Object (File)
Tue, Sep 17, 8:52 AM
Unknown Object (File)
Sat, Sep 14, 8:47 PM
Subscribers

Details

Summary

Printing device followed by interface matches, e.g., edk2.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mar 12 2022, 5:28 AM

So why do we even use this function at all?

I mean, the change is right, but it's wrong that we use this function still anywhere at all. We should be calling back to UEFI to format this...

In D34539#782498, @imp wrote:

So why do we even use this function at all?

I mean, the change is right, but it's wrong that we use this function still anywhere at all. We should be calling back to UEFI to format this...

The firmware isn't guaranteed to provide the formatting protocol, so this is the fallback... working on a project right now where we actually exercise this path, and it caused me a couple of gray hairs.

This matches what I did in the UEFI wiring code and it matches the UEFI standard.

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

So it does...

I've held off on this in the past because I also entertained the idea of switching the EDK2 APIs so we can also pull in ACPI parsing...

In D34539#782504, @imp wrote:
In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

So it does...

I've held off on this in the past because I also entertained the idea of switching the EDK2 APIs so we can also pull in ACPI parsing...

For us, the value is diagnostics - I did add those bits because there was some case about distinguishing those block devices...

This revision was automatically updated to reflect the committed changes.