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
approach.
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
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.
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?
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?
Niko
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
