[PATCH v1] leds: lp3952: Remove ACPI support for lp3952

[PATCH v1] leds: lp3952: Remove ACPI support for lp3952

[Andy Shevchenko]

In ACPI world any ID should be carefully chosen and registered
officially. The discussion as I read it gets to wilful assignment an ID
for non-existing real DSDT example.

Rafael already told [2] how this device would be enumerated using
compatible string.

Based on above, remove non-official ACPI IDs and enumeration from the
driver.

[1] https://e2e.ti.com/support/power_management/led_driver/f/192/t/524926
[2] http://article.gmane.org/gmane.linux.acpi.devel/85252

Cc: Tony Makkiel <tony.makkiel@daqri.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/leds/leds-lp3952.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/leds/leds-lp3952.c b/drivers/leds/leds-lp3952.c
index 4847e89883a7..4c320f22ab84 100644
--- a/drivers/leds/leds-lp3952.c
+++ b/drivers/leds/leds-lp3952.c
@@ -10,7 +10,6 @@
  *
  */
 
-#include <linux/acpi.h>
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/i2c.h>
@@ -122,9 +121,9 @@ static int lp3952_register_led_classdev(struct lp3952_led_array *priv)
 	};
 
 	for (i = 0; i < LP3952_LED_ALL; i++) {
-		acpi_ret = lp3952_get_label(&priv->client->dev, led_name_hdl[i],
-					    priv->leds[i].name);
-		if (acpi_ret)
+		ret = lp3952_get_label(&priv->client->dev, led_name_hdl[i],
+				       priv->leds[i].name);
+		if (ret)
 			continue;
 
 		priv->leds[i].cdev.name = priv->leds[i].name;
@@ -276,19 +275,9 @@ static const struct i2c_device_id lp3952_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, lp3952_id);
 
-#ifdef CONFIG_ACPI
-static const struct acpi_device_id lp3952_acpi_match[] = {
-	{"TXNW3952", 0},
-	{}
-};
-
-MODULE_DEVICE_TABLE(acpi, lp3952_acpi_match);
-#endif
-
 static struct i2c_driver lp3952_i2c_driver = {
 	.driver = {
 			.name = LP3952_NAME,
-			.acpi_match_table = ACPI_PTR(lp3952_acpi_match),
 	},
 	.probe = lp3952_probe,
 	.remove = lp3952_remove,
-- 
2.11.0

Re: [PATCH v1] leds: lp3952: Remove ACPI support for lp3952

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Tue 2017-03-21 21:33:15, Andy Shevchenko wrote:
> In ACPI world any ID should be carefully chosen and registered
> officially. The discussion as I read it gets to wilful assignment an ID
> for non-existing real DSDT example.
> 
> Rafael already told [2] how this device would be enumerated using
> compatible string.
> 
> Based on above, remove non-official ACPI IDs and enumeration from the
> driver.

Hmm. Do any "real users" have hardware with TXNW3952 ACPI ID?

									Pavel

> -static const struct acpi_device_id lp3952_acpi_match[] = {
> -	{"TXNW3952", 0},
> -	{}
> -};
> -
> -MODULE_DEVICE_TABLE(acpi, lp3952_acpi_match);
> -#endif
> -
>  static struct i2c_driver lp3952_i2c_driver = {
>  	.driver = {
>  			.name = LP3952_NAME,
> -			.acpi_match_table = ACPI_PTR(lp3952_acpi_match),
>  	},
>  	.probe = lp3952_probe,
>  	.remove = lp3952_remove,

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v1] leds: lp3952: Remove ACPI support for lp3952

[Andy Shevchenko]

On Tue, 2017-03-21 at 21:17 +0100, Pavel Machek wrote:
> On Tue 2017-03-21 21:33:15, Andy Shevchenko wrote:
> > In ACPI world any ID should be carefully chosen and registered
> > officially. The discussion as I read it gets to wilful assignment an
> > ID
> > for non-existing real DSDT example.
> > 
> > Rafael already told [2] how this device would be enumerated using
> > compatible string.
> > 
> > Based on above, remove non-official ACPI IDs and enumeration from
> > the
> > driver.
> 
> Hmm. Do any "real users" have hardware with TXNW3952 ACPI ID?

I googled for it and found only discussions I put links to (besides few
mention of the driver code itself). So, it makes me to be confident
there is quite unlikely existing one in the wild (esp. TI answers).

> 
> 									
> Pavel
> 
> > -static const struct acpi_device_id lp3952_acpi_match[] = {
> > -	{"TXNW3952", 0},
> > -	{}
> > -};
> > -
> > -MODULE_DEVICE_TABLE(acpi, lp3952_acpi_match);
> > -#endif
> > -
> >  static struct i2c_driver lp3952_i2c_driver = {
> >  	.driver = {
> >  			.name = LP3952_NAME,
> > -			.acpi_match_table =
> > ACPI_PTR(lp3952_acpi_match),
> >  	},
> >  	.probe = lp3952_probe,
> >  	.remove = lp3952_remove,
> 
> 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH v1] leds: lp3952: Remove ACPI support for lp3952

[Andy Shevchenko]

On Wed, 2017-03-22 at 14:08 +0000, tony makkiel wrote:
> 
> On 22/03/17 13:15, Andy Shevchenko wrote:
> > On Tue, 2017-03-21 at 21:17 +0100, Pavel Machek wrote:
> > > On Tue 2017-03-21 21:33:15, Andy Shevchenko wrote:
> > > > In ACPI world any ID should be carefully chosen and registered
> > > > officially. The discussion as I read it gets to wilful
> > > > assignment an
> > > > ID
> > > > for non-existing real DSDT example.
> > > > 
> > > > Rafael already told [2] how this device would be enumerated
> > > > using
> > > > compatible string.
> > > > 
> > > > Based on above, remove non-official ACPI IDs and enumeration
> > > > from
> > > > the
> > > > driver.
> > > 
> > > Hmm. Do any "real users" have hardware with TXNW3952 ACPI ID?
> > 
> > I googled for it and found only discussions I put links to (besides
> > few
> > mention of the driver code itself). So, it makes me to be confident
> > there is quite unlikely existing one in the wild (esp. TI answers).
> > 
> 
> [3] https://www.spinics.net/lists/linux-acpi/msg67125.html
> [4] http://www.uefi.org/ACPI_ID_List?search=texas
> [5] http://www.spinics.net/lists/linux-leds/msg06353.html
> 
> Following 2 links, copied from previous post
> 
> 
> [1] https://e2e.ti.com/support/power_management/led_driver/f/192/t/524
> 926
> [2] http://article.gmane.org/gmane.linux.acpi.devel/85252
> 
> 
>   For some reason cant open link [2].

Doesn't matter, it's the same as [3].

> 
> [3] lead to [1]. The name was chosen based on 5th post on [1]. I
> tried 
> to use 'PRP0001'. But was told not to use it [5].

No, you didn't just get how it's supposed to work.

You may read [6] as example how PRP0001 would be used if needed.

http://marc.info/?l=linux-i2c&m=149012370204924&w=2


Rafael is right there, you can't add PRP0001 *explicitly* in the list.

Moreover, Rafael explicitly told you what to do:

"So the entire ACPI block can be dropped for now.
And the driver doesn't have to depend on CONFIG_ACPI any more, does it?"

By some unknown reason you decide on your own how to proceed.

> 
> I can confirm, the driver gets probed, and works if ACPI string
> match. 
> [Was tested on Minnowboard with SSDT overlay].
> 
> > > 
> > > 									
> > > Pavel
> > > 
> > > > -static const struct acpi_device_id lp3952_acpi_match[] = {
> > > > -	{"TXNW3952", 0},
> > > > -	{}
> > > > -};
> > > > -
> > > > -MODULE_DEVICE_TABLE(acpi, lp3952_acpi_match);
> > > > -#endif
> > > > -
> > > >  static struct i2c_driver lp3952_i2c_driver = {
> > > >  	.driver = {
> > > >  			.name = LP3952_NAME,
> > > > -			.acpi_match_table =
> > > > ACPI_PTR(lp3952_acpi_match),
> > > >  	},
> > > >  	.probe = lp3952_probe,
> > > >  	.remove = lp3952_remove,
> > > 
> > > 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy