[PATCH V4 0/2] leds: pwm: Add optional GPIO enable pin support

[PATCH V4 0/2] leds: pwm: Add optional GPIO enable pin support

[LI Qingwu]

Add support for an optional GPIO enable pin to the PWM LED driver.
Some LED controllers require an additional enable GPIO to be enabled
on the device before PWM control can take effect.

Testing:
- Tested on i.MX8MP EVK board with TPS92380 LED backlight driver
- Verified GPIO enable/disable functionality works correctly
- Confirmed both GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW polarities
  work properly


Device tree configuration used for testing:

	backlight_keypad: backlight-keypad {
		compatible = "pwm-leds";

		led {
			color = <LED_COLOR_ID_WHITE>;
			enable-gpios = <&pca6416 11 GPIO_ACTIVE_HIGH>;
			function = LED_FUNCTION_KBD_BACKLIGHT;
			max-brightness = <100>;
			pwms = <&pwm3 0 2500 0>;
		};
	};

Changes in V4:
- Reword commit message to specify the LED driver chip TPS92380
- Add tested device tree configuration to cover letter

Changes in V3:
- fix make dt_binding_check failed on check leds-pwm.yaml




LI Qingwu (2):
  dt-bindings: leds: pwm: add enable-gpios property
  leds: pwm: Add optional GPIO enable pin support

 .../devicetree/bindings/leds/leds-pwm.yaml    |  7 ++++++
 drivers/leds/leds-pwm.c                       | 22 +++++++++++++++++++
 2 files changed, 29 insertions(+)

-- 
2.43.0

[PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[LI Qingwu]

some pwm led driver chips like tps92380 require a separate enable signal
in addition to pwm control. this property allows device trees to specify
such gpio, which will be controlled automatically by the driver based
on the led brightness state.

Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
---
 Documentation/devicetree/bindings/leds/leds-pwm.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
index 61b97e8bc36d0..6c4fcefbe25f9 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
@@ -40,6 +40,13 @@ patternProperties:
           initialization. If the option is not set then max brightness is used.
         $ref: /schemas/types.yaml#/definitions/uint32
 
+      enable-gpios:
+        description:
+          GPIO for LED hardware enable control. Set active when brightness is
+          non-zero and inactive when brightness is zero.
+          The GPIO default state follows the "default-state" property.
+        maxItems: 1
+
     required:
       - pwms
       - max-brightness
-- 
2.43.0

[PATCH V4 2/2] leds: pwm: Add optional GPIO enable pin support

[LI Qingwu]

add support for optional GPIO-based enable pin control to PWM LED driver.
some PWM LED chips,e.g.tps92380, have a dedicated enable GPIO, adds the
support to specify such GPIO, activating the pin when LED brightness
is non-zero and deactivating it when off.
tested on imx8mp platform with led driver tps92380.

Link: https://www.ti.com/lit/gpn/tps92380
Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
---
 drivers/leds/leds-pwm.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index c73134e7b9514..1397149464b35 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -17,6 +17,7 @@
 #include <linux/err.h>
 #include <linux/pwm.h>
 #include <linux/slab.h>
+#include <linux/gpio/consumer.h>
 
 struct led_pwm {
 	const char	*name;
@@ -29,6 +30,7 @@ struct led_pwm_data {
 	struct led_classdev	cdev;
 	struct pwm_device	*pwm;
 	struct pwm_state	pwmstate;
+	struct gpio_desc	*enable_gpio;
 	unsigned int		active_low;
 };
 
@@ -51,6 +53,9 @@ static int led_pwm_set(struct led_classdev *led_cdev,
 	if (led_dat->active_low)
 		duty = led_dat->pwmstate.period - duty;
 
+	gpiod_set_value_cansleep(led_dat->enable_gpio,
+				 brightness == LED_OFF ? 0 : 1);
+
 	led_dat->pwmstate.duty_cycle = duty;
 	/*
 	 * Disabling a PWM doesn't guarantee that it emits the inactive level.
@@ -132,6 +137,23 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
 		break;
 	}
 
+	/* Claim the GPIO as ASIS and set the value
+	 * later on to honor the different default states
+	 */
+	led_data->enable_gpio =
+		devm_fwnode_gpiod_get(dev, fwnode, "enable", GPIOD_ASIS, NULL);
+
+	/* enable_gpio is optional */
+	if (IS_ERR(led_data->enable_gpio)) {
+		if (PTR_ERR(led_data->enable_gpio) == -ENOENT)
+			led_data->enable_gpio = NULL;
+		else
+			return PTR_ERR(led_data->enable_gpio);
+	}
+
+	gpiod_direction_output(led_data->enable_gpio,
+			       !!led_data->cdev.brightness);
+
 	ret = devm_led_classdev_register_ext(dev, &led_data->cdev, &init_data);
 	if (ret) {
 		dev_err(dev, "failed to register PWM led for %s: %d\n",
-- 
2.43.0

Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[Krzysztof Kozlowski]

On 03/07/2025 11:34, LI Qingwu wrote:
> some pwm led driver chips like tps92380 require a separate enable signal

Sentence starts with capital letter.

tps92380 does not have dedicated enable pin. It has VDDIO, which serves
also enable purpose, but it is a supply.

Best regards,
Krzysztof

RE: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[LI Qingwu]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, July 3, 2025 5:59 PM
> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
> pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; linux-leds@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: GEO-CHHER-bsp-development
> <bsp-development.geo@leica-geosystems.com>
> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On 03/07/2025 11:34, LI Qingwu wrote:
> > some pwm led driver chips like tps92380 require a separate enable
> > signal
> 
> Sentence starts with capital letter.
> 
> tps92380 does not have dedicated enable pin. It has VDDIO, which serves also
> enable purpose, but it is a supply.

So this patch is unacceptable anyway?
 
> Best regards,
> Krzysztof

Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[Krzysztof Kozlowski]

On 03/07/2025 12:27, LI Qingwu wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Thursday, July 3, 2025 5:59 PM
>> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
>> pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
>> conor+dt@kernel.org; linux-leds@vger.kernel.org; devicetree@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Cc: GEO-CHHER-bsp-development
>> <bsp-development.geo@leica-geosystems.com>
>> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property
>>
>> This email is not from Hexagon’s Office 365 instance. Please be careful while
>> clicking links, opening attachments, or replying to this email.

Please drop this, it is not relevant in upstream discussions. Use normal
email client which will not produce useless header above.


>>
>>
>> On 03/07/2025 11:34, LI Qingwu wrote:
>>> some pwm led driver chips like tps92380 require a separate enable
>>> signal
>>
>> Sentence starts with capital letter.
>>
>> tps92380 does not have dedicated enable pin. It has VDDIO, which serves also
>> enable purpose, but it is a supply.
> 
> So this patch is unacceptable anyway?

If you make this patch for tps92380, I think it is not correct. You have
entire commit msg to explain the hardware and all unusual things. Having
VDDIO and EN pin is unusual, because you do not supply power directly
from GPIOs of a SoC. All this should be explained.

Best regards,
Krzysztof

RE: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[LI Qingwu]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, July 3, 2025 6:55 PM
> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
> pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; linux-leds@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: GEO-CHHER-bsp-development
> <bsp-development.geo@leica-geosystems.com>
> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On 03/07/2025 12:27, LI Qingwu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzk@kernel.org>
> >> Sent: Thursday, July 3, 2025 5:59 PM
> >> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
> >> pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> >> conor+dt@kernel.org; linux-leds@vger.kernel.org;
> >> conor+devicetree@vger.kernel.org;
> >> linux-kernel@vger.kernel.org
> >> Cc: GEO-CHHER-bsp-development
> >> <bsp-development.geo@leica-geosystems.com>
> >> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios
> >> property
> >>
> >> This email is not from Hexagon’s Office 365 instance. Please be
> >> careful while clicking links, opening attachments, or replying to this email.
> 
> Please drop this, it is not relevant in upstream discussions. Use normal email
> client which will not produce useless header above.
> 
> 
> >>
> >>
> >> On 03/07/2025 11:34, LI Qingwu wrote:
> >>> some pwm led driver chips like tps92380 require a separate enable
> >>> signal
> >>
> >> Sentence starts with capital letter.
> >>
> >> tps92380 does not have dedicated enable pin. It has VDDIO, which
> >> serves also enable purpose, but it is a supply.
> >
> > So this patch is unacceptable anyway?
> 
> If you make this patch for tps92380, I think it is not correct. You have entire
> commit msg to explain the hardware and all unusual things. Having VDDIO and
> EN pin is unusual, because you do not supply power directly from GPIOs of a SoC.
> All this should be explained.

Thank you for the feedback, what about rename to power-supply with regulator support ? 
Convert this patch to add regulator support instead of GPIO, using "power-supply" property to control 
LED power, or drop this patch and give up upstream, or what's the better from your point of view?
appreciate your guidance!

> 
> Best regards,
> Krzysztof

Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[Krzysztof Kozlowski]

On Thu, Jul 03, 2025 at 11:36:10AM +0000, LI Qingwu wrote:
> 
> 
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > Sent: Thursday, July 3, 2025 6:55 PM
> > To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
> > pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> > conor+dt@kernel.org; linux-leds@vger.kernel.org; devicetree@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Cc: GEO-CHHER-bsp-development
> > <bsp-development.geo@leica-geosystems.com>
> > Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property
> > 
> > This email is not from Hexagon’s Office 365 instance. Please be careful while
> > clicking links, opening attachments, or replying to this email.
> > 
> > 
> > On 03/07/2025 12:27, LI Qingwu wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Krzysztof Kozlowski <krzk@kernel.org>
> > >> Sent: Thursday, July 3, 2025 5:59 PM
> > >> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
> > >> pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> > >> conor+dt@kernel.org; linux-leds@vger.kernel.org;
> > >> conor+devicetree@vger.kernel.org;
> > >> linux-kernel@vger.kernel.org
> > >> Cc: GEO-CHHER-bsp-development
> > >> <bsp-development.geo@leica-geosystems.com>
> > >> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios
> > >> property
> > >>
> > >> This email is not from Hexagon’s Office 365 instance. Please be
> > >> careful while clicking links, opening attachments, or replying to this email.
> > 
> > Please drop this, it is not relevant in upstream discussions. Use normal email
> > client which will not produce useless header above.
> > 
> > 
> > >>
> > >>
> > >> On 03/07/2025 11:34, LI Qingwu wrote:
> > >>> some pwm led driver chips like tps92380 require a separate enable
> > >>> signal
> > >>
> > >> Sentence starts with capital letter.
> > >>
> > >> tps92380 does not have dedicated enable pin. It has VDDIO, which
> > >> serves also enable purpose, but it is a supply.
> > >
> > > So this patch is unacceptable anyway?
> > 
> > If you make this patch for tps92380, I think it is not correct. You have entire
> > commit msg to explain the hardware and all unusual things. Having VDDIO and
> > EN pin is unusual, because you do not supply power directly from GPIOs of a SoC.
> > All this should be explained.
> 
> Thank you for the feedback, what about rename to power-supply with regulator support ? 
> Convert this patch to add regulator support instead of GPIO, using "power-supply" property to control 
> LED power, or drop this patch and give up upstream, or what's the better from your point of view?
> appreciate your guidance!

Does it solve your problem? It is surprising that once you say it is
GPIO and once as regulator. How is it in your board?

Regulator is looking as correct hardware description, so that patch
would be fine.

Best regards,
Krzysztof

RE: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[LI Qingwu]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Friday, July 4, 2025 3:51 PM
> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
> Cc: lee@kernel.org; pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; linux-leds@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; GEO-CHHER-bsp-development
> <bsp-development.geo@leica-geosystems.com>
> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On Thu, Jul 03, 2025 at 11:36:10AM +0000, LI Qingwu wrote:
> >
> >
> > > -----Original Message-----
> > > From: Krzysztof Kozlowski <krzk@kernel.org>
> > > Sent: Thursday, July 3, 2025 6:55 PM
> > > To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>; lee@kernel.org;
> > > pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> > > conor+dt@kernel.org; linux-leds@vger.kernel.org;
> > > conor+devicetree@vger.kernel.org;
> > > linux-kernel@vger.kernel.org
> > > Cc: GEO-CHHER-bsp-development
> > > <bsp-development.geo@leica-geosystems.com>
> > > Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios
> > > property
> > >
> > > This email is not from Hexagon’s Office 365 instance. Please be
> > > careful while clicking links, opening attachments, or replying to this email.
> > >
> > >
> > > On 03/07/2025 12:27, LI Qingwu wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Krzysztof Kozlowski <krzk@kernel.org>
> > > >> Sent: Thursday, July 3, 2025 5:59 PM
> > > >> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>;
> > > >> lee@kernel.org; pavel@kernel.org; robh@kernel.org;
> > > >> krzk+dt@kernel.org;
> > > >> conor+dt@kernel.org; linux-leds@vger.kernel.org;
> > > >> conor+devicetree@vger.kernel.org;
> > > >> linux-kernel@vger.kernel.org
> > > >> Cc: GEO-CHHER-bsp-development
> > > >> <bsp-development.geo@leica-geosystems.com>
> > > >> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add
> > > >> enable-gpios property
> > > >>
> > > >> This email is not from Hexagon’s Office 365 instance. Please be
> > > >> careful while clicking links, opening attachments, or replying to this email.
> > >
> > > Please drop this, it is not relevant in upstream discussions. Use
> > > normal email client which will not produce useless header above.
> > >
> > >
> > > >>
> > > >>
> > > >> On 03/07/2025 11:34, LI Qingwu wrote:
> > > >>> some pwm led driver chips like tps92380 require a separate
> > > >>> enable signal
> > > >>
> > > >> Sentence starts with capital letter.
> > > >>
> > > >> tps92380 does not have dedicated enable pin. It has VDDIO, which
> > > >> serves also enable purpose, but it is a supply.
> > > >
> > > > So this patch is unacceptable anyway?
> > >
> > > If you make this patch for tps92380, I think it is not correct. You
> > > have entire commit msg to explain the hardware and all unusual
> > > things. Having VDDIO and EN pin is unusual, because you do not supply
> power directly from GPIOs of a SoC.
> > > All this should be explained.
> >
> > Thank you for the feedback, what about rename to power-supply with
> regulator support ?
> > Convert this patch to add regulator support instead of GPIO, using
> > "power-supply" property to control LED power, or drop this patch and give up
> upstream, or what's the better from your point of view?
> > appreciate your guidance!
> 
> Does it solve your problem? It is surprising that once you say it is GPIO and once
> as regulator. How is it in your board?
> 
> Regulator is looking as correct hardware description, so that patch would be
> fine.


Thank you for your feedback and clarification.
On our hardware, the TPS92380's VDDIO/EN pin is connected to a GPIO,
which is used to enable or disable the device.
According to the datasheet, this pin is described as 
"enable input for the device as well as supply input (VDDIO) for digital 
pins". If describing this as a supply is the preferred and correct way for
upstream, I can implement as supply regulator controlled by GPIO, and to
model this behavior in device tree. 

or if you have a better suggestion for such cases.

> 
> Best regards,
> Krzysztof

RE: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property

[LI Qingwu]

> -----Original Message-----
> From: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
> Sent: Friday, July 4, 2025 4:36 PM
> To: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: lee@kernel.org; pavel@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; linux-leds@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; GEO-CHHER-bsp-development
> <bsp-development.geo@leica-geosystems.com>
> Subject: RE: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios property
> 
> 
> 
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > Sent: Friday, July 4, 2025 3:51 PM
> > To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
> > Cc: lee@kernel.org; pavel@kernel.org; robh@kernel.org;
> > krzk+dt@kernel.org;
> > conor+dt@kernel.org; linux-leds@vger.kernel.org;
> > conor+devicetree@vger.kernel.org;
> > linux-kernel@vger.kernel.org; GEO-CHHER-bsp-development
> > <bsp-development.geo@leica-geosystems.com>
> > Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add enable-gpios
> > property
> > On Thu, Jul 03, 2025 at 11:36:10AM +0000, LI Qingwu wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Krzysztof Kozlowski <krzk@kernel.org>
> > > > Sent: Thursday, July 3, 2025 6:55 PM
> > > > To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>;
> > > > lee@kernel.org; pavel@kernel.org; robh@kernel.org;
> > > > krzk+dt@kernel.org;
> > > > conor+dt@kernel.org; linux-leds@vger.kernel.org;
> > > > conor+devicetree@vger.kernel.org;
> > > > linux-kernel@vger.kernel.org
> > > > Cc: GEO-CHHER-bsp-development
> > > > <bsp-development.geo@leica-geosystems.com>
> > > > Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add
> > > > enable-gpios property
> > > >
> > > >
> > > >
> > > > On 03/07/2025 12:27, LI Qingwu wrote:
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Krzysztof Kozlowski <krzk@kernel.org>
> > > > >> Sent: Thursday, July 3, 2025 5:59 PM
> > > > >> To: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>;
> > > > >> lee@kernel.org; pavel@kernel.org; robh@kernel.org;
> > > > >> krzk+dt@kernel.org;
> > > > >> conor+dt@kernel.org; linux-leds@vger.kernel.org;
> > > > >> conor+devicetree@vger.kernel.org;
> > > > >> linux-kernel@vger.kernel.org
> > > > >> Cc: GEO-CHHER-bsp-development
> > > > >> <bsp-development.geo@leica-geosystems.com>
> > > > >> Subject: Re: [PATCH V4 1/2] dt-bindings: leds: pwm: add
> > > > >> enable-gpios property
> > > > >>
> > > >
> > > >
> > > > >>
> > > > >>
> > > > >> On 03/07/2025 11:34, LI Qingwu wrote:
> > > > >>> some pwm led driver chips like tps92380 require a separate
> > > > >>> enable signal
> > > > >>
> > > > >> Sentence starts with capital letter.
> > > > >>
> > > > >> tps92380 does not have dedicated enable pin. It has VDDIO,
> > > > >> which serves also enable purpose, but it is a supply.
> > > > >
> > > > > So this patch is unacceptable anyway?
> > > >
> > > > If you make this patch for tps92380, I think it is not correct.
> > > > You have entire commit msg to explain the hardware and all unusual
> > > > things. Having VDDIO and EN pin is unusual, because you do not
> > > > supply
> > power directly from GPIOs of a SoC.
> > > > All this should be explained.
> > >
> > > Thank you for the feedback, what about rename to power-supply with
> > regulator support ?
> > > Convert this patch to add regulator support instead of GPIO, using
> > > "power-supply" property to control LED power, or drop this patch and
> > > give up
> > upstream, or what's the better from your point of view?
> > > appreciate your guidance!
> >
> > Does it solve your problem? It is surprising that once you say it is
> > GPIO and once as regulator. How is it in your board?
> >
> > Regulator is looking as correct hardware description, so that patch
> > would be fine.
> 
> 
> Thank you for your feedback and clarification.
> On our hardware, the TPS92380's VDDIO/EN pin is connected to a GPIO, which
> is used to enable or disable the device.
> According to the datasheet, this pin is described as "enable input for the device
> as well as supply input (VDDIO) for digital pins". If describing this as a supply is
> the preferred and correct way for upstream, I can implement as supply
> regulator controlled by GPIO, and to model this behavior in device tree.
> 
> or if you have a better suggestion for such cases.
LT3743 also has also such EN/UVLO pin and it has serval microampere current
https://www.analog.com/en/products/lt3743.html#documentation

> >
> > Best regards,
> > Krzysztof