Re: [PATCH] ACPI: utils: Ignore leading root scope prefix in string _UID match

On 9/4/26 08:26, Rafael J. Wysocki (Intel) wrote:
> On Mon, Aug 31, 2026 at 8:02 PM Mario Limonciello
> <[email protected]> wrote:
>>
>> Firmware may express an ACPI namespace path used as a _UID with or
>> without the leading root scope character ('\'). For example, an AMD
>> IVRS IVHD ACPI HID device entry may carry a character UID of
>> "\_SB.MHSP" while the corresponding device's _UID evaluates to
>> "_SB.MHSP" (or vice versa).  This semantic difference is due to how
>> Windows PnP enumerates and uses devices.
> 
> Can you please elaborate a bit more?
> 
> I would expect _UID to return the string without the leading
> backslash, so where does the other one come from, exactly?

It comes from the ACPI IVRS table.

https://docs.amd.com/v/u/en-US/48882_3.11_IOMMU_PUB

p306-307 talk about this field.

Here is a sample entry decoded with iasl -d
(from BIOS on an affected system)

[223h 0547 001h]               Subtable Type : F0 [Device Entry: ACPI 
HID Named Device]
[224h 0548 002h]                   Device ID : 0068
[226h 0550 001h] Data Setting (decoded below) : 40
                                     INITPass : 0
                                     EIntPass : 0
                                      NMIPass : 0
                                     Reserved : 0
                                  System MGMT : 0
                                   LINT0 Pass : 1
                                   LINT1 Pass : 0
[227h 0551 008h]                    ACPI HID : "MSFT0201"
[22Fh 0559 008h]                    ACPI CID : 0000000000000000
[237h 0567 001h]                  UID Format : 02
[238h 0568 001h]                  UID Length : 09
[239h 0569 009h]                         UID : "\_SB.XHSP"

Setting this field to _SB.XHSP does fix the issue for Linux, but this 
has problems on Windows.  So my hope was to let \_SB.XHSP work for Linux 
too.

> 
>> acpi_str_uid_match() compared the two strings verbatim, so such
>> entries failed to match on the UID even though they refer to the same
>> object. In the AMD IOMMU case (get_acpihid_device_id()) this caused
>> the exact HID+UID match to be missed and the code to fall through to
>> the HID-only path, spuriously raising a FW_BUG.
>>
>> Skip a single leading '\' on either string before comparing so that
>> paths that differ only by the root scope prefix are treated as a
>> match. The integer _UID path is unaffected.
> 
> But this sort of assumes that the string returned by _UID will always
> be a namespace path, but is that the case really?

For IVRS entries this would be true since this is what is in the spec:

 > If defined as a character string, the ACPI UID marks the instances of
 > DMA-capable devices with the defined DeviceID (e.g. IOMMU visible
 > Routing ID). It should match the ACPI device namespace strings with
 > unit number, but without a trailing \0 character (as the UID length
 > specifies the size of the string already).

But I don't know universally it would be true.

I suppose one possible modification could be to look for the length of 
the string being at least 2 on the string before incrementing the pointer.

> 
>> Signed-off-by: Mario Limonciello <[email protected]>
>> ---
>>   include/acpi/acpi_bus.h | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
>> index 1a45e0d521d8e..e0bec35953ef1 100644
>> --- a/include/acpi/acpi_bus.h
>> +++ b/include/acpi/acpi_bus.h
>> @@ -835,7 +835,15 @@ static inline bool acpi_str_uid_match(struct acpi_device *adev, const char *uid2
>>   {
>>          const char *uid1 = acpi_device_uid(adev);
>>
>> -       return uid1 && uid2 && !strcmp(uid1, uid2);
>> +       if (!uid1 || !uid2)
>> +               return false;
>> +
>> +       if (*uid1 == '\\')
>> +               uid1++;
>> +       if (*uid2 == '\\')
>> +               uid2++;
>> +
>> +       return !strcmp(uid1, uid2);
>>   }
>>
>>   static inline bool acpi_int_uid_match(struct acpi_device *adev, u64 uid2)
>> --
>> 2.43.0
>>