The regulator for vled-supply is unused in the driver.
It is just assigned from DT and disabled in lp50xx_remove.
So the code can be removed from the driver.
Part 1 updates the documentation
Part 2 removes the code
Signed-off-by: Sven Schuchmann <[email protected]>
---
drivers/leds/leds-lp50xx.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
index f13117eed976..b0871495bae3 100644
--- a/drivers/leds/leds-lp50xx.c
+++ b/drivers/leds/leds-lp50xx.c
@@ -11,7 +11,6 @@
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/regmap.h>
-#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <uapi/linux/uleds.h>
@@ -275,7 +274,6 @@ struct lp50xx_led {
/**
* struct lp50xx -
* @enable_gpio: hardware enable gpio
- * @regulator: LED supply regulator pointer
* @client: pointer to the I2C client
* @regmap: device register map
* @dev: pointer to the devices device struct
@@ -286,7 +284,6 @@ struct lp50xx_led {
*/
struct lp50xx {
struct gpio_desc *enable_gpio;
- struct regulator *regulator;
struct i2c_client *client;
struct regmap *regmap;
struct device *dev;
@@ -462,10 +459,6 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
return ret;
}
- priv->regulator = devm_regulator_get(priv->dev, "vled");
- if (IS_ERR(priv->regulator))
- priv->regulator = NULL;
-
device_for_each_child_node(priv->dev, child) {
led = &priv->leds[i];
ret = fwnode_property_count_u32(child, "reg");
@@ -583,13 +576,6 @@ static int lp50xx_remove(struct i2c_client *client)
return ret;
}
- if (led->regulator) {
- ret = regulator_disable(led->regulator);
- if (ret)
- dev_err(&led->client->dev,
- "Failed to disable regulator\n");
- }
-
mutex_destroy(&led->lock);
return 0;
--
2.17.1
On Wed 2021-02-03 08:34:08, Sven Schuchmann wrote:
> The regulator for vled-supply is unused in the driver.
> It is just assigned from DT and disabled in lp50xx_remove.
> So the code can be removed from the driver.
Dan, what is going on here? Do we need to also enable the regulator,
or is the removal correct thing to do?
Best regards,
Pavel
> Part 1 updates the documentation
> Part 2 removes the code
>
> Signed-off-by: Sven Schuchmann <[email protected]>
>
> ---
> drivers/leds/leds-lp50xx.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> index f13117eed976..b0871495bae3 100644
> --- a/drivers/leds/leds-lp50xx.c
> +++ b/drivers/leds/leds-lp50xx.c
> @@ -11,7 +11,6 @@
> #include <linux/of.h>
> #include <linux/of_gpio.h>
> #include <linux/regmap.h>
> -#include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> #include <uapi/linux/uleds.h>
>
> @@ -275,7 +274,6 @@ struct lp50xx_led {
> /**
> * struct lp50xx -
> * @enable_gpio: hardware enable gpio
> - * @regulator: LED supply regulator pointer
> * @client: pointer to the I2C client
> * @regmap: device register map
> * @dev: pointer to the devices device struct
> @@ -286,7 +284,6 @@ struct lp50xx_led {
> */
> struct lp50xx {
> struct gpio_desc *enable_gpio;
> - struct regulator *regulator;
> struct i2c_client *client;
> struct regmap *regmap;
> struct device *dev;
> @@ -462,10 +459,6 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
> return ret;
> }
>
> - priv->regulator = devm_regulator_get(priv->dev, "vled");
> - if (IS_ERR(priv->regulator))
> - priv->regulator = NULL;
> -
> device_for_each_child_node(priv->dev, child) {
> led = &priv->leds[i];
> ret = fwnode_property_count_u32(child, "reg");
> @@ -583,13 +576,6 @@ static int lp50xx_remove(struct i2c_client *client)
> return ret;
> }
>
> - if (led->regulator) {
> - ret = regulator_disable(led->regulator);
> - if (ret)
> - dev_err(&led->client->dev,
> - "Failed to disable regulator\n");
> - }
> -
> mutex_destroy(&led->lock);
>
> return 0;
--
http://www.livejournal.com/~pavelmachek
Pavel
On 2/3/21 3:02 AM, Pavel Machek wrote:
> On Wed 2021-02-03 08:34:08, Sven Schuchmann wrote:
>> The regulator for vled-supply is unused in the driver.
>> It is just assigned from DT and disabled in lp50xx_remove.
>> So the code can be removed from the driver.
> Dan, what is going on here? Do we need to also enable the regulator,
> or is the removal correct thing to do?
>
I think it would be better to do an enable as opposed to removing the code.
This would be needed especially in applications that have to meet strict
power management requirements.
Users may want to disable or enable the regulator during suspend/resume.
Otherwise it would be considered always-on and the regulator does not
need to be populated.
Dan
On Wed 2021-02-03 07:49:35, Dan Murphy wrote:
> Pavel
>
> On 2/3/21 3:02 AM, Pavel Machek wrote:
> > On Wed 2021-02-03 08:34:08, Sven Schuchmann wrote:
> > > The regulator for vled-supply is unused in the driver.
> > > It is just assigned from DT and disabled in lp50xx_remove.
> > > So the code can be removed from the driver.
> > Dan, what is going on here? Do we need to also enable the regulator,
> > or is the removal correct thing to do?
> >
> I think it would be better to do an enable as opposed to removing the code.
>
> This would be needed especially in applications that have to meet strict
> power management requirements.
>
> Users may want to disable or enable the regulator during suspend/resume.
> Otherwise it would be considered always-on and the regulator does not need
> to be populated.
Do you have set up where this is needed and you can test this? Will
you submit the fixes?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
Pavel
On 2/3/21 8:23 AM, Pavel Machek wrote:
> On Wed 2021-02-03 07:49:35, Dan Murphy wrote:
>> Pavel
>>
>> On 2/3/21 3:02 AM, Pavel Machek wrote:
>>> On Wed 2021-02-03 08:34:08, Sven Schuchmann wrote:
>>>> The regulator for vled-supply is unused in the driver.
>>>> It is just assigned from DT and disabled in lp50xx_remove.
>>>> So the code can be removed from the driver.
>>> Dan, what is going on here? Do we need to also enable the regulator,
>>> or is the removal correct thing to do?
>>>
>> I think it would be better to do an enable as opposed to removing the code.
>>
>> This would be needed especially in applications that have to meet strict
>> power management requirements.
>>
>> Users may want to disable or enable the regulator during suspend/resume.
>> Otherwise it would be considered always-on and the regulator does not need
>> to be populated.
> Do you have set up where this is needed and you can test this? Will
> you submit the fixes?
No I use an always on regulator in my setup. I have no managed supplies
exposed.
Dan
> Best regards,
>
> Pavel
Hello Dan, hello Pavel,
> > Do you have set up where this is needed and you can test this? Will
> > you submit the fixes?
>
> No I use an always on regulator in my setup. I have no managed supplies
> exposed.
I am also sorry I do not have a setup ready for testing this.
I think we should ignore this patch then?`
For now I am working on the enable pin in the driver.
The enablement seems it does not work. The order of I2C-Reset
and Enable is wrong and the pin is used before initialized.
But I do not have any patches ready.
Is the enable pin working on your side?
Best Regards,
Sven
On Wed 2021-02-03 10:02:00, Dan Murphy wrote:
> Pavel
>
> On 2/3/21 8:23 AM, Pavel Machek wrote:
> > On Wed 2021-02-03 07:49:35, Dan Murphy wrote:
> > > Pavel
> > >
> > > On 2/3/21 3:02 AM, Pavel Machek wrote:
> > > > On Wed 2021-02-03 08:34:08, Sven Schuchmann wrote:
> > > > > The regulator for vled-supply is unused in the driver.
> > > > > It is just assigned from DT and disabled in lp50xx_remove.
> > > > > So the code can be removed from the driver.
> > > > Dan, what is going on here? Do we need to also enable the regulator,
> > > > or is the removal correct thing to do?
> > > >
> > > I think it would be better to do an enable as opposed to removing the code.
> > >
> > > This would be needed especially in applications that have to meet strict
> > > power management requirements.
> > >
> > > Users may want to disable or enable the regulator during suspend/resume.
> > > Otherwise it would be considered always-on and the regulator does not need
> > > to be populated.
> > Do you have set up where this is needed and you can test this? Will
> > you submit the fixes?
>
> No I use an always on regulator in my setup. I have no managed supplies
> exposed.
Hmm, that is not ideal :-(. Can you try to provide patch, anyway?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek