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

+Andy

On Fri, Sep 4, 2026 at 7:32 PM Mario Limonciello
<[email protected]> wrote:
>
>
>
> 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.

So how does Linux process this table?  Maybe the leading backslash can
be removed in that path?

But I guess it may not help because _UID may contain a string with a
leading backslash.

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

In general, they can be free-form strings AFAICS.

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

I guess this change can be made because it will only possibly cause
problems when the only difference between the supplied UID and the
string returned by _UID is the leading backslash and they are not
supposed to match, which is unlikely to happen.

However, the kerneldoc comment of acpi_str_uid_match() needs to be
updated to mention this.