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 cutThis is no abuse but exactly what PRP0001 is meant for. The basic idea of
approach.
PRP0001 is to reuse DT "compatible" strings in ACPI namespace, see
Documentation/acpi/enumeration.txt. Reusing also means getting access to the
of_device_id.
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.
Allocating an ACPI id for an already existing DT driver is redundant, isn't
it?
It is not.