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

Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
Changes in v3:
        * Swap arguments while comparing HID against PRP0001.
        * Check value of adev against NULL.
        * Declare variables in reversed xmas tree order.
        * Update commit message.
Changes in v2:
        * Fix build errors.
---
 drivers/acpi/bus.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 5e110badac7b..e960df2fcea7 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1030,9 +1030,13 @@ static const void *acpi_of_device_get_match_data(const struct device *dev)
 const void *acpi_device_get_match_data(const struct device *dev)
 {
 	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);
 
 	match = acpi_match_device(acpi_ids, dev);
-- 
2.43.0

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().
> 
> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> ---
> Changes in v3:
>         * Swap arguments while comparing HID against PRP0001.
>         * Check value of adev against NULL.
>         * Declare variables in reversed xmas tree order.
>         * Update commit message.
> Changes in v2:
>         * Fix build errors.
> ---
>  drivers/acpi/bus.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 5e110badac7b..e960df2fcea7 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -1030,9 +1030,13 @@ static const void *acpi_of_device_get_match_data(const struct device *dev)
>  const void *acpi_device_get_match_data(const struct device *dev)
>  {
>  	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);
>  
>  	match = acpi_match_device(acpi_ids, dev);

Should you check with !acpi_ids still here?

> -- 
> 2.43.0

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

Hi Andy,

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.

-- 
Regards,

Sakari Ailus

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

On Fri, Jan 9, 2026 at 6:02 PM Andy Shevchenko
<andriy.shevchenko@linux.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);

Hi Rafael, Andy,

On Fri, Jan 09, 2026 at 10:11:26PM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 9, 2026 at 6:02 PM Andy Shevchenko
> <andriy.shevchenko@linux.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);

That would mean that any ACPI (or PNP) ID has priority over compatible
matching, wouldn't it? AFAIU the documentation says effectively that
_HID/_CID priority is upheld, whether matching with PRP0001 or without.

-- 
Regards,

Sakari Ailus

On 12/01/26 03:31, Sakari Ailus wrote:
> External email: Use caution opening links or attachments
> 
> 
> Hi Rafael, Andy,
> 
> On Fri, Jan 09, 2026 at 10:11:26PM +0100, Rafael J. Wysocki wrote:
>> On Fri, Jan 9, 2026 at 6:02 PM Andy Shevchenko
>> <andriy.shevchenko@linux.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);
> 
> That would mean that any ACPI (or PNP) ID has priority over compatible
> matching, wouldn't it? AFAIU the documentation says effectively that
> _HID/_CID priority is upheld, whether matching with PRP0001 or without.
> 
> --
> Regards,
> 
> Sakari Ailus


Hi Rafael, Sakari, Andy,

Since we seem to be using __acpi_match_device() match the device.
What if we directly utilise __acpi_match_device() here?

Something like:

	if (!__acpi_match_device(adev, acpi_ids, of_ids, &acpi_id, &of_id))
		return NULL;

	if (acpi_id)
		return (const void *)acpi_id->driver_data;

	if (of_id)
		return of_id->data;

	return NULL;

Then, we can also remove acpi_of_device_get_match_data()?

Thanks,
Kartik

On Mon, Jan 12, 2026 at 02:12:49PM +0530, Kartik Rajput wrote:
> On 12/01/26 03:31, Sakari Ailus wrote:
> > On Fri, Jan 09, 2026 at 10:11:26PM +0100, Rafael J. Wysocki wrote:
> > > On Fri, Jan 9, 2026 at 6:02 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.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:

...

> > > > > > 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);
> > 
> > That would mean that any ACPI (or PNP) ID has priority over compatible
> > matching, wouldn't it? AFAIU the documentation says effectively that
> > _HID/_CID priority is upheld, whether matching with PRP0001 or without.
> 
> Since we seem to be using __acpi_match_device() match the device.
> What if we directly utilise __acpi_match_device() here?
> 
> Something like:
> 
> 	if (!__acpi_match_device(adev, acpi_ids, of_ids, &acpi_id, &of_id))
> 		return NULL;
> 
> 	if (acpi_id)
> 		return (const void *)acpi_id->driver_data;
> 
> 	if (of_id)
> 		return of_id->data;
> 
> 	return NULL;
> 
> Then, we can also remove acpi_of_device_get_match_data()?

At brief look it's indeed seems to be a good optimisation as well.

-- 
With Best Regards,
Andy Shevchenko

Hi Kartik, Andy,

On Mon, Jan 12, 2026 at 10:55:57AM +0200, Andy Shevchenko wrote:
> > 	if (!__acpi_match_device(adev, acpi_ids, of_ids, &acpi_id, &of_id))
> > 		return NULL;
> > 
> > 	if (acpi_id)
> > 		return (const void *)acpi_id->driver_data;
> > 
> > 	if (of_id)
> > 		return of_id->data;
> > 
> > 	return NULL;
> > 
> > Then, we can also remove acpi_of_device_get_match_data()?
> 
> At brief look it's indeed seems to be a good optimisation as well.

Looks good to me, too!

-- 
Sakari Ailus