Re: [PATCH] ACPI: Provide !ACPI stub for acpi_device_uid()

[Rafael J. Wysocki (Intel)]

On Tue, Sep 22, 2026 at 5:17 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
>
> On 22/09/2026 12:40 pm, Rafael J. Wysocki (Intel) wrote:
> > On Fri, Sep 18, 2026 at 5:27 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
> >>
> >> While the likes of acpi_dev_uid_to_integer() and acpi_dev_uid_match()
> >> already have stubs for !ACPI, the basic acpi_device_uid() getter does
> >> not. As with acpi_device_hid(), add one for the convenience of portable
> >> drivers who just want the string itself - in fact they are so much alike
> >> that we can simply alias the exact same stub definition.
> >>
> >> Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx>
> >> ---
> >>   include/acpi/acpi_bus.h | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> >> index 1a45e0d521d8..ed309ea4785d 100644
> >> --- a/include/acpi/acpi_bus.h
> >> +++ b/include/acpi/acpi_bus.h
> >> @@ -963,6 +963,7 @@ static inline const char *acpi_device_hid(struct acpi_device *device)
> >>   {
> >>          return "";
> >>   }
> >> +#define acpi_device_uid acpi_device_hid
> >>
> >>   static inline bool
> >>   acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld_info **pld)
> >> --
> >
> > Sashiko has reservations that look valid:
> >
> > https://sashiko.dev/#/patchset/513319f19ed6b0b6d4c76dc517074531966b98f5.1789745223.git.robin.murphy%40arm.com
>
> Oops, indeed apparently I missed that acpi_device_pnp::unique_id isn't
> actually const - it probably should be IMO, but that would be a whole
> other patch.
>
> FWIW I can't see that the return value itself actually matters here
> since !ACPI code couldn't have a valid acpi_device to legitimately call
> this with at runtime. In fact even for compile-testing, references
> should usually be under a condition like has_acpi_companion() which
> would lead to them getting DCE's under !ACPI without needing the stub -
> this was really just for completeness to shut up annoying Sashiko noise
> on that point.

But I think that returning NULL in the !ACPI case would be more
consistent with the ACPI case anyway.