When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
Fixes: 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput kkartik@nvidia.com --- Changes in v2: * Fix build errors. --- drivers/acpi/bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 5e110badac7b..6658c4339656 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match; + struct acpi_device *adev = ACPI_COMPANION(dev);
- if (!acpi_ids) + if (!strcmp(ACPI_DT_NAMESPACE_HID, acpi_device_hid(adev))) return acpi_of_device_get_match_data(dev);
match = acpi_match_device(acpi_ids, dev);
Hi Kartik,
On Wed, Jan 07, 2026 at 05:33:18PM +0530, Kartik Rajput wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
Fixes: 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput kkartik@nvidia.com
Changes in v2:
- Fix build errors.
Thanks for the update.
drivers/acpi/bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 5e110badac7b..6658c4339656 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match;
- struct acpi_device *adev = ACPI_COMPANION(dev);
- if (!acpi_ids)
- if (!strcmp(ACPI_DT_NAMESPACE_HID, acpi_device_hid(adev)))
I'd swap the arguments to have the static one on the right, i.e.
if (!strcmp(acpi_device_hid(adev), ACPI_DT_NAMESPACE_HID))
The patch looks good apart from that IMO.
return acpi_of_device_get_match_data(dev);match = acpi_match_device(acpi_ids, dev);
On 07/01/26 18:08, Sakari Ailus wrote:
External email: Use caution opening links or attachments
Hi Kartik,
On Wed, Jan 07, 2026 at 05:33:18PM +0530, Kartik Rajput wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
Fixes: 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput kkartik@nvidia.com
Changes in v2: * Fix build errors.
Thanks for the update.
drivers/acpi/bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 5e110badac7b..6658c4339656 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match;
struct acpi_device *adev = ACPI_COMPANION(dev);
if (!acpi_ids)
if (!strcmp(ACPI_DT_NAMESPACE_HID, acpi_device_hid(adev)))I'd swap the arguments to have the static one on the right, i.e.
if (!strcmp(acpi_device_hid(adev), ACPI_DT_NAMESPACE_HID))The patch looks good apart from that IMO.
return acpi_of_device_get_match_data(dev); match = acpi_match_device(acpi_ids, dev);-- Kind regards,
Sakari Ailus
Hi Sakari,
Thanks for reviewing the patch!
I will make this change in the next version of this patch.
Thanks, Kartik
On Wed, Jan 7, 2026 at 1:03 PM Kartik Rajput kkartik@nvidia.com wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
Fixes: 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput kkartik@nvidia.com
Changes in v2: * Fix build errors.
drivers/acpi/bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 5e110badac7b..6658c4339656 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match;
struct acpi_device *adev = ACPI_COMPANION(dev);
if (!acpi_ids)
You still need to check acpi_ids against NULL or (better) check adev against NULL.
if (!strcmp(ACPI_DT_NAMESPACE_HID, acpi_device_hid(adev))) return acpi_of_device_get_match_data(dev); match = acpi_match_device(acpi_ids, dev);--
On 07/01/26 18:24, Rafael J. Wysocki wrote:
External email: Use caution opening links or attachments
On Wed, Jan 7, 2026 at 1:03 PM Kartik Rajput kkartik@nvidia.com wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
Fixes: 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput kkartik@nvidia.com
Changes in v2: * Fix build errors.
drivers/acpi/bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 5e110badac7b..6658c4339656 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match;
struct acpi_device *adev = ACPI_COMPANION(dev);
if (!acpi_ids)You still need to check acpi_ids against NULL or (better) check adev against NULL.
Hi Rafael,
Thanks for reviewing the patch.
Yes, it looks like adev should be NULL-checked. acpi_of_device_get_match_data() also uses the adev reference and passes it to acpi_of_match_device(), which checks it against NULL.
I will make this change in the next revision.
Thanks, Kartik
On Wed, Jan 07, 2026 at 05:33:18PM +0530, Kartik Rajput wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Since we have both tables, why the actual ACPI HID of the device in question (actually which one?) can't be used?
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
In principle we can go this way, but can you tell a bit more of a story? Why the device in question can't use existed or a newly allocated ACPI HID for that?
...
@@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match;
- struct acpi_device *adev = ACPI_COMPANION(dev);
Please, keep it in reversed xmas tree order.
- if (!acpi_ids)
- if (!strcmp(ACPI_DT_NAMESPACE_HID, acpi_device_hid(adev)))
return acpi_of_device_get_match_data(dev);match = acpi_match_device(acpi_ids, dev);
Hi Andy,
Thanks for reviewing the patch!
On 07/01/26 21:17, Andy Shevchenko wrote:
External email: Use caution opening links or attachments
On Wed, Jan 07, 2026 at 05:33:18PM +0530, Kartik Rajput wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Since we have both tables, why the actual ACPI HID of the device in question (actually which one?) can't be used?
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
In principle we can go this way, but can you tell a bit more of a story? Why the device in question can't use existed or a newly allocated ACPI HID for that?
While testing PRP0001-based matching with the Tegra fuse driver on an SoC that does not yet have an allocated ACPI HID, device_get_match_data() returned NULL because the driver also provides an acpi_match_table.
Commit 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") was intended to address this by honoring PRP0001 when retrieving match data. However, when a driver provides an ACPI match table, acpi_device_get_match_data() currently consults only that table, resulting in NULL match data despite a successful PRP0001 match.
...
@@ -1031,8 +1031,9 @@ const void *acpi_device_get_match_data(const struct device *dev) { const struct acpi_device_id *acpi_ids = dev->driver->acpi_match_table; const struct acpi_device_id *match;
struct acpi_device *adev = ACPI_COMPANION(dev);Please, keep it in reversed xmas tree order.
Ack. I will update this in the next revision.
Thanks, Kartik
On Thu, Jan 08, 2026 at 05:57:35PM +0530, Kartik Rajput wrote:
On 07/01/26 21:17, Andy Shevchenko wrote:
On Wed, Jan 07, 2026 at 05:33:18PM +0530, Kartik Rajput wrote:
When a device is matched via PRP0001, the driver's OF (DT) match table must be used to obtain the device match data. If a driver provides both an acpi_match_table and an of_match_table, the current acpi_device_get_match_data() path consults the driver's acpi_match_table and returns NULL (no ACPI ID matches).
Since we have both tables, why the actual ACPI HID of the device in question (actually which one?) can't be used?
Explicitly detect PRP0001 and fetch match data from the driver's of_match_table via acpi_of_device_get_match_data().
In principle we can go this way, but can you tell a bit more of a story? Why the device in question can't use existed or a newly allocated ACPI HID for that?
While testing PRP0001-based matching with the Tegra fuse driver on an SoC that does not yet have an allocated ACPI HID,
Which means in the production you do not need this patch. Allocate ID and go with it.
device_get_match_data() returned NULL because the driver also provides an acpi_match_table.
Commit 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data") was intended to address this by honoring PRP0001 when retrieving match data. However, when a driver provides an ACPI match table, acpi_device_get_match_data() currently consults only that table, resulting in NULL match data despite a successful PRP0001 match.
Which is expected behaviour. So there are two cases I can see that might make this patch valid:
1) the preproduction development when the driver has both tables and formal ACPI HID is not allocated yet (this what has to be the main "why" point in the commit message);
2) a driver that got ACPI HID from somebody else and breaks the PRP0001 setups for others (no evidences so far, but I admit there is a potential to have a such).
That said, having the Fixes tag is unrequired.
linux-stable-mirror@lists.linaro.org