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: <aWE0uuZjB1iMGF2B@smile.fi.intel.com>
Date: Fri, 9 Jan 2026 19:02:50 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: 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 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.

-- 
With Best Regards,
Andy Shevchenko