Add UEFI locator for bus_get_device_path, pci acpi

[imp]

Summary

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

[imp]

rebase + ping

[jhb]

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(...));
}

[imp]

update per review.

[jhb]

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?

[imp]

In D32749#749543, @jhb wrote:

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?)

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...

[jhb]

In D32749#749587, @imp wrote:

In D32749#749543, @jhb wrote:

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?)

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...

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.

[imp]

In D32749#750267, @jhb wrote:

In D32749#749587, @imp wrote:

In D32749#749543, @jhb wrote:

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?)

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...

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.

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...