Re: [PATCH v3 3/7] acpi: add acpi_of_match_device_ids

From: Markus Probst

Date: Tue Mar 24 2026 - 11:41:29 EST


On Mon, 2026-03-23 at 20:57 +0100, Rafael J. Wysocki wrote:
> On Fri, Mar 13, 2026 at 8:03 PM Markus Probst via B4 Relay
> <devnull+markus.probst.posteo.de@xxxxxxxxxx> wrote:
> >
> > From: Markus Probst <markus.probst@xxxxxxxxx>
> >
> > Add a function to match acpi devices against of_device_ids. This will be
> > used in the following commit ("mfd: match acpi devices against PRP0001")
> > to match mfd sub-devices against a of compatible string.
>
> Please always spell ACPI in capitals in patch subjects, comments,
> changelogs, etc. It is not a regular word.
Ok.
>
> > Signed-off-by: Markus Probst <markus.probst@xxxxxxxxx>
> > ---
> > drivers/acpi/bus.c | 7 +++++++
> > include/acpi/acpi_bus.h | 2 ++
> > 2 files changed, 9 insertions(+)
> >
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index f6707325f582..5ddcc56edc87 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -1044,6 +1044,13 @@ int acpi_match_device_ids(struct acpi_device *device,
> > }
> > EXPORT_SYMBOL(acpi_match_device_ids);
> >
>
> Missing kerneldoc.
The same amount of kerneldoc as `acpi_match_device_ids`, if I am not
mistaken.
>
> > +int acpi_of_match_device_ids(struct acpi_device *device,
> > + const struct of_device_id *ids)
> > +{
> > + return __acpi_match_device(device, NULL, ids, NULL, NULL) ? 0 : -ENOENT;
> > +}
> > +EXPORT_SYMBOL(acpi_of_match_device_ids);
>
> Are you aware of the consensus that using PRP0001 in production
> platform firmware will be regarded as invalid?
>
> Because of that, it is not an option for a driver to avoid providing
> ACPI match data on a platform that uses ACPI.
First of all, the driver that would have made use of it has been
restructed to not use mfd subdevices. It would not be affected anymore
through this patch set. Not sure if I should still send it as its own
patch series though.

The device of the driver has no ACPI ID allocated by the manufacturer,
as it is only used on a proprietary Linux OS (with their own modified
kernel).

The driver would have only been useful via device tree or an ACPI
Overlay. Obviously, I don't have a PNP or ACPI Vendor ID, so I can't
assign one. The parent/main driver does only have a of compatible id.
As it needs to use PRP0001 anyway on ACPI, I thought it makes more
sense to also use PRP0001 there instead of matching it with a _ADR
which is "a grey area in the ACPI specification".

Thanks
- Markus Probst

>
> > +
> > bool acpi_driver_match_device(struct device *dev,
> > const struct device_driver *drv)
> > {
> > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> > index aad1a95e6863..0081b9e4aaee 100644
> > --- a/include/acpi/acpi_bus.h
> > +++ b/include/acpi/acpi_bus.h
> > @@ -677,6 +677,8 @@ void acpi_bus_trim(struct acpi_device *start);
> > acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
> > int acpi_match_device_ids(struct acpi_device *device,
> > const struct acpi_device_id *ids);
> > +int acpi_of_match_device_ids(struct acpi_device *device,
> > + const struct of_device_id *ids);
> > void acpi_set_modalias(struct acpi_device *adev, const char *default_id,
> > char *modalias, size_t len);
> >
> >
> > --
> > 2.52.0
> >
> >

Attachment: signature.asc
Description: This is a digitally signed message part