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