Re: [RFC PATCH] ACPI: bus: match of_device_id using acpi device

From: Nikolaus Voss
Date: Wed Jul 04 2018 - 06:50:26 EST

On Wed, 4 Jul 2018, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 1:17 PM, Nikolaus Voss
<nikolaus.voss@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 4 Jul 2018, Sudeep Holla wrote:
On 04/07/18 10:32, Andy Shevchenko wrote:
On Wed, Jul 4, 2018 at 6:37 AM, Srinath Mannam
<srinath.mannam@xxxxxxxxxxxx> wrote:

+1 on NACK for this and anything else that abuse PRP0001 as a short cut
This is no abuse but exactly what PRP0001 is meant for. The basic idea of
PRP0001 is to reuse DT "compatible" strings in ACPI namespace, see
Documentation/acpi/enumeration.txt. Reusing also means getting access to the

The idea was for almost DIY and / or manufacturer to develop a
prototype without modifying match code and faking ACPI IDs.
That's why the target of PRP0001 is almost sensors connected to I2C and SPI.

That's why I agreed on your patch to help with this. But! The proper
solution for the devices (device manufacturer) is to allocate an ACPI
ID and provide a corresponding table to the driver.

This is my understanding of that exercise. Rafael can correct me.

This is not meant as a short cut for device manufacturers. The patch is meant to make PRP0001 work when access to specific driver_data is needed. I see nothing bad with it.

Allocating an ACPI id for an already existing DT driver is redundant, isn't

It is not.

The driver won't work any better with it. The driver code gets another table as big as of_device_id table. Can you give me a hint what the added value is?