Add a UEFI locator type. It prints the UEFI device names for a FreeBSD
device_t name. It works with PCI and ACPI device nodes. USB forthcoming.
Sponsored by: Netflix
Details
Details
- Reviewers
jhb - Commits
- rGd0a20e401ef1: Add UEFI locator for bus_get_device_path, pci acpi
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 42785 Build 39673: arc lint + arc unit
Event Timeline
Comment Actions
I would perhaps defer adding the UEFI locator constant and words in the manpages until this commit?
| sys/dev/acpica/acpi.c | ||
|---|---|---|
| 960–1006 | Hmm, so perhaps refine my earlier suggestion to still keep a helper routine for ACPI, but the ACPI bus itself would also need to still use a wrapper that handled UEFI as is done here). That may affect how you want to name the shared helper routine. | |
| sys/dev/acpica/acpi_pci.c | ||
| 207 | I would maybe make this function use pci_get_device_path_method as its default at the bottom rather than only for UEFI, so something like: static int
acpi_pci_get_device_path(...)
{
if (strcmp(locator, BUS_LOCATOR_ACPI) == 0) {
return (acpi_get_device_path(...));
return (pci_get_device_path_method(...));
} | |
Comment Actions
So I guess one thing that is perhaps not clear here is that this permits the UEFI path to be "inherited" by child devices (by virtue of the bus_generic method just returning the parent's result for children when you have a non-UEFI-aware bus? E.g. a foophy0 child of a miibus will have the UEFI path of the parent NIC?)
| sys/dev/pci/pci.c | ||
|---|---|---|
| 141 | Would maybe just leave this blank line here to not add noise to the diff? | |
Comment Actions
Yes. If the children don't know about or there is no UEFI path defined for them, the children will have the same name. This is to allow for the fact that the UEFI device model is an imperfect match for ours. UEFI doesn't have MIIs in its device model: they are considered to be part of the NIC itself, so in this case, having the same path I think is actually as close a match as we can get (though there are NIC device paths which we don't implement that are an imperfect match to mii, except for those PHYs that determine the MAC address for the NIC...
Comment Actions
So that seems a bit odd to me as we create various pseudo devices. miibus is one example, but if CAM starts using new-bus there will be several more. I'm not sure things like 'scbus' in CAM should have valid UEFI paths but instead only periphs? I do think though that if we want locator inheritance for a given locator type it explicit we should make that explicit vs having the bus_generic version default to inheriting any "unknown" locators. I suspect for FDT we will want it more like ACPI where we only match on exact devices and not pseudo devices that are sub-children.
Comment Actions
Yea, I'd propose we defer this point until we get to FDT/OFW trees. Ideally, the locator would know the policy, but we currently have no locator object to ask...