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: <aWDhEBjy9b9_uzoR@smile.fi.intel.com>
Date: Fri, 9 Jan 2026 13:05:52 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Kartik Rajput <kkartik@...dia.com>, lenb@...nel.org,
	sakari.ailus@...ux.intel.com, 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 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.

> >  	match = acpi_match_device(acpi_ids, dev);
> 
> Should you check with !acpi_ids still here?

-- 
With Best Regards,
Andy Shevchenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ