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

[Kartik Rajput <kkartik@nvidia.com>]

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