linux-kernel - Re: [PATCH v3] ACPI: bus: Use OF match data for PRP0001 matched devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0ijTQC2cFTt+hW-ofJwMqdEeES8d5MMbbq8_Bqg+_9E3g@mail.gmail.com>
Date: Fri, 9 Jan 2026 22:11:26 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>, 
	Mika Westerberg <mika.westerberg@...ux.intel.com>, Kartik Rajput <kkartik@...dia.com>, lenb@...nel.org, 
	thierry.reding@...il.com, jonathanh@...dia.com, linux-acpi@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ACPI: bus: Use OF match data for PRP0001 matched devices

On Fri, Jan 9, 2026 at 6:02 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Fri, Jan 09, 2026 at 01:29:59PM +0200, Sakari Ailus wrote:
> > On Fri, Jan 09, 2026 at 01:05:52PM +0200, Andy Shevchenko wrote:
> > > On Fri, Jan 09, 2026 at 11:13:02AM +0100, Mika Westerberg wrote:
> > > > On Fri, Jan 09, 2026 at 03:23:58PM +0530, Kartik Rajput wrote:
> > > > > During pre-production development, drivers may provide both ACPI and OF
> > > > > match tables while a formal ACPI HID for the device is not yet
> > > > > allocated. Such devices are enumerated via PRP0001. In this case,
> > > > > acpi_device_get_match_data() consults only the driver’s ACPI match table
> > > > > and returns NULL, even though the device was successfully matched via
> > > > > PRP0001.
> > > > >
> > > > > This behavior also risks breaking existing PRP0001 setups if a driver
> > > > > later gains an ACPI HID, as the presence of an ACPI match table changes
> > > > > the match-data lookup path.
> > > > >
> > > > > Explicitly detect PRP0001 and fetch match data from the driver's
> > > > > OF match table via acpi_of_device_get_match_data().
>
> ...
>
> > > > >         const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table;
> > > > > +       struct acpi_device *adev = ACPI_COMPANION(dev);
> > > > >         const struct acpi_device_id *match;
> > > > >
> > > > > -       if (!acpi_ids)
> > > > > +       if (!adev)
> > > > > +               return NULL;
> > > > > +
> > > > > +       if (!strcmp(acpi_device_hid(adev), ACPI_DT_NAMESPACE_HID))
> > > > >                 return acpi_of_device_get_match_data(dev);
> > >
> > > On top of what Mika asked, shouldn't we check CID as well? Theoretically it's
> > > possible that some device may have HID "blablabla" and CID PRP0001, I don't
> > > remember what documentation says about this case, though.
> >
> > According to Documentation/firmware-guide/acpi/enumeration.rst PRP0001 is
> > also valid for _CID. So yes, I think this should be checked as well -- I'd
> > loop over the &device->pnp.ids list.
>
> Yeah, but if we have a device with
>
> HID "blablabla"
> CID "PRP0001"
>
> and at the same time the driver has ACPI ID listed, we should probably use that
> one as HID should have higher weight for matching. Logic here is not just as simple
> as looping over pnp.ids how I see it.

Right.

What about:

if (acpi_ids) {
       match = acpi_match_device(acpi_ids, dev);
       if (match)
               return (const void *)match->driver_data;
}
return acpi_of_device_get_match_data(dev);