| Message ID | 1420621722-7428-5-git-send-email-oliver+list@schinagl.nl |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jan 07, 2015 at 10:08:42AM +0100, Olliver Schinagl wrote: > From: Olliver Schinagl <oliver@schinagl.nl> > > The gpio document says we should not use unnamed bindings for gpios. > This patch uses the 'led-' prefix to the gpios and updates code and > documents. Because the devm_get_gpiod_from_child() falls back to using > old-style unnamed gpios, we can update the code first, and update > dts files as time allows. > > Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> > --- > Documentation/devicetree/bindings/leds/leds-gpio.txt | 12 ++++++------ > drivers/leds/leds-gpio.c | 2 +- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt > index d544cf1..2c138cc 100644 > --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt > +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt > @@ -7,7 +7,7 @@ Each LED is represented as a sub-node of the gpio-leds device. Each > node's name represents the name of the corresponding LED. > > LED sub-node properties: > -- gpios : Should specify the LED's GPIO, see "gpios property" in > +- led-gpios : Should specify the LED's GPIO, see "gpios property" in > Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be > indicated using flags in the GPIO specifier. > - label : (optional) > @@ -32,12 +32,12 @@ leds { > compatible = "gpio-leds"; > hdd { > label = "IDE Activity"; > - gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; > + led-gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; > linux,default-trigger = "ide-disk"; > }; > > fault { > - gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; > + led-gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; > /* Keep LED on if BIOS detected hardware fault */ > default-state = "keep"; > }; > @@ -46,11 +46,11 @@ leds { > run-control { > compatible = "gpio-leds"; > red { > - gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>; > + led-gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>; > default-state = "off"; > }; > green { > - gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; > + led-gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; > default-state = "on"; > }; > }; > @@ -59,7 +59,7 @@ leds { > compatible = "gpio-leds"; > > charger-led { > - gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; > + led-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; > linux,default-trigger = "max8903-charger-charging"; > retain-state-suspended; > }; > diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c > index 8e5af69..5b7bc84 100644 > --- a/drivers/leds/leds-gpio.c > +++ b/drivers/leds/leds-gpio.c > @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev) > struct gpio_led led = {}; > const char *state = NULL; > > - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); > + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); Would not this break existing boards using old bindings? You need to handle both cases: if you can't located "led-gpios" then you will have to try just "gpios". Thanks.
Hey Dmitry, On 08-01-15 00:55, Dmitry Torokhov wrote: > On Wed, Jan 07, 2015 at 10:08:42AM +0100, Olliver Schinagl wrote: >> From: Olliver Schinagl <oliver@schinagl.nl> >> >> The gpio document says we should not use unnamed bindings for gpios. >> This patch uses the 'led-' prefix to the gpios and updates code and >> documents. Because the devm_get_gpiod_from_child() falls back to using >> old-style unnamed gpios, we can update the code first, and update >> dts files as time allows. >> >> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> >> --- >> Documentation/devicetree/bindings/leds/leds-gpio.txt | 12 ++++++------ >> drivers/leds/leds-gpio.c | 2 +- >> 2 files changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt >> index d544cf1..2c138cc 100644 >> --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt >> +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt >> @@ -7,7 +7,7 @@ Each LED is represented as a sub-node of the gpio-leds device. Each >> node's name represents the name of the corresponding LED. >> >> LED sub-node properties: >> -- gpios : Should specify the LED's GPIO, see "gpios property" in >> +- led-gpios : Should specify the LED's GPIO, see "gpios property" in >> Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be >> indicated using flags in the GPIO specifier. >> - label : (optional) >> @@ -32,12 +32,12 @@ leds { >> compatible = "gpio-leds"; >> hdd { >> label = "IDE Activity"; >> - gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; >> + led-gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; >> linux,default-trigger = "ide-disk"; >> }; >> >> fault { >> - gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; >> + led-gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; >> /* Keep LED on if BIOS detected hardware fault */ >> default-state = "keep"; >> }; >> @@ -46,11 +46,11 @@ leds { >> run-control { >> compatible = "gpio-leds"; >> red { >> - gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>; >> + led-gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>; >> default-state = "off"; >> }; >> green { >> - gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; >> + led-gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; >> default-state = "on"; >> }; >> }; >> @@ -59,7 +59,7 @@ leds { >> compatible = "gpio-leds"; >> >> charger-led { >> - gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; >> + led-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; >> linux,default-trigger = "max8903-charger-charging"; >> retain-state-suspended; >> }; >> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c >> index 8e5af69..5b7bc84 100644 >> --- a/drivers/leds/leds-gpio.c >> +++ b/drivers/leds/leds-gpio.c >> @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev) >> struct gpio_led led = {}; >> const char *state = NULL; >> >> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); >> + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); > Would not this break existing boards using old bindings? You need to > handle both cases: if you can't located "led-gpios" then you will have to > try just "gpios". Very true. I was rather even hoping we could update all bindings, I don't mind going through the available dts files to fix them ... But need to know that that's the proper way to go before doing the work ;) Olliver > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@schinagl.nl> wrote: > Hey Dmitry, > > > On 08-01-15 00:55, Dmitry Torokhov wrote: >> >> On Wed, Jan 07, 2015 at 10:08:42AM +0100, Olliver Schinagl wrote: >>> >>> From: Olliver Schinagl <oliver@schinagl.nl> >>> >>> The gpio document says we should not use unnamed bindings for gpios. >>> This patch uses the 'led-' prefix to the gpios and updates code and >>> documents. Because the devm_get_gpiod_from_child() falls back to using >>> old-style unnamed gpios, we can update the code first, and update >>> dts files as time allows. [...] >>> --- a/drivers/leds/leds-gpio.c >>> +++ b/drivers/leds/leds-gpio.c >>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct >>> platform_device *pdev) >>> struct gpio_led led = {}; >>> const char *state = NULL; >>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); >>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); >> >> Would not this break existing boards using old bindings? You need to >> handle both cases: if you can't located "led-gpios" then you will have to >> try just "gpios". > > Very true. I was rather even hoping we could update all bindings, I don't > mind going through the available dts files to fix them ... But need to know > that that's the proper way to go before doing the work ;) That will not work. You cannot make changes that require a new dtb with a new kernel. This would also break for the other way around (i.e. a new dtb and old kernel). You would have to search for both led-gpios and gpios. I'm not sure if we can do that generically for all GPIOs. If you had a node with both "blah-gpios" and "gpios", it would break. I would hope there are no such cases like that. We also now have to consider how ACPI identifies GPIOs and whether this makes sense. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote: > On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@schinagl.nl> wrote: > > Hey Dmitry, > > > > > > On 08-01-15 00:55, Dmitry Torokhov wrote: > >> > >> On Wed, Jan 07, 2015 at 10:08:42AM +0100, Olliver Schinagl wrote: > >>> > >>> From: Olliver Schinagl <oliver@schinagl.nl> > >>> > >>> The gpio document says we should not use unnamed bindings for gpios. > >>> This patch uses the 'led-' prefix to the gpios and updates code and > >>> documents. Because the devm_get_gpiod_from_child() falls back to using > >>> old-style unnamed gpios, we can update the code first, and update > >>> dts files as time allows. > > [...] > > >>> --- a/drivers/leds/leds-gpio.c > >>> +++ b/drivers/leds/leds-gpio.c > >>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct > >>> platform_device *pdev) > >>> struct gpio_led led = {}; > >>> const char *state = NULL; > >>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); > >>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); > >> > >> Would not this break existing boards using old bindings? You need to > >> handle both cases: if you can't located "led-gpios" then you will have to > >> try just "gpios". > > > > Very true. I was rather even hoping we could update all bindings, I don't > > mind going through the available dts files to fix them ... But need to know > > that that's the proper way to go before doing the work ;) > > That will not work. You cannot make changes that require a new dtb > with a new kernel. This would also break for the other way around > (i.e. a new dtb and old kernel). > > You would have to search for both led-gpios and gpios. I'm not sure if > we can do that generically for all GPIOs. If you had a node with both > "blah-gpios" and "gpios", it would break. I would hope there are no > such cases like that. We also now have to consider how ACPI identifies > GPIOs and whether this makes sense. I think only the driver itself can know about such "legacy" mappings and make a decision. Thanks.
On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote: >> On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@schinagl.nl> wrote: >> >>> --- a/drivers/leds/leds-gpio.c >> >>> +++ b/drivers/leds/leds-gpio.c >> >>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct >> >>> platform_device *pdev) >> >>> struct gpio_led led = {}; >> >>> const char *state = NULL; >> >>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); >> >>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); >> >> >> >> Would not this break existing boards using old bindings? You need to >> >> handle both cases: if you can't located "led-gpios" then you will have to >> >> try just "gpios". >> > >> > Very true. I was rather even hoping we could update all bindings, I don't >> > mind going through the available dts files to fix them ... But need to know >> > that that's the proper way to go before doing the work ;) >> >> That will not work. You cannot make changes that require a new dtb >> with a new kernel. This would also break for the other way around >> (i.e. a new dtb and old kernel). >> >> You would have to search for both led-gpios and gpios. I'm not sure if >> we can do that generically for all GPIOs. If you had a node with both >> "blah-gpios" and "gpios", it would break. I would hope there are no >> such cases like that. We also now have to consider how ACPI identifies >> GPIOs and whether this makes sense. > > I think only the driver itself can know about such "legacy" mappings and > make a decision. Yeah leds-gpio.c will need to be patched to check for "led-gpios" first and then fall back to "gpios" if not found. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 14-01-15 13:45, Linus Walleij wrote: > On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: >> On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote: >>> On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@schinagl.nl> wrote: >>>>>> --- a/drivers/leds/leds-gpio.c >>>>>> +++ b/drivers/leds/leds-gpio.c >>>>>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct >>>>>> platform_device *pdev) >>>>>> struct gpio_led led = {}; >>>>>> const char *state = NULL; >>>>>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); >>>>>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); >>>>> Would not this break existing boards using old bindings? You need to >>>>> handle both cases: if you can't located "led-gpios" then you will have to >>>>> try just "gpios". >>>> Very true. I was rather even hoping we could update all bindings, I don't >>>> mind going through the available dts files to fix them ... But need to know >>>> that that's the proper way to go before doing the work ;) >>> That will not work. You cannot make changes that require a new dtb >>> with a new kernel. This would also break for the other way around >>> (i.e. a new dtb and old kernel). >>> >>> You would have to search for both led-gpios and gpios. I'm not sure if >>> we can do that generically for all GPIOs. If you had a node with both >>> "blah-gpios" and "gpios", it would break. I would hope there are no >>> such cases like that. We also now have to consider how ACPI identifies >>> GPIOs and whether this makes sense. >> I think only the driver itself can know about such "legacy" mappings and >> make a decision. > Yeah leds-gpio.c will need to be patched to check for "led-gpios" first > and then fall back to "gpios" if not found. yeah I've done the work, just need to double check it and resend a v2. Linus, I assume you want the already applied patches omitted from v2? Olliver > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl <oliver@schinagl.nl> wrote: > > On 14-01-15 13:45, Linus Walleij wrote: >> >> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov >> <dmitry.torokhov@gmail.com> wrote: >>> >>> On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote: >>>> >>>> On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@schinagl.nl> >>>> wrote: >>>>>>> >>>>>>> --- a/drivers/leds/leds-gpio.c >>>>>>> +++ b/drivers/leds/leds-gpio.c >>>>>>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv >>>>>>> *gpio_leds_create(struct >>>>>>> platform_device *pdev) >>>>>>> struct gpio_led led = {}; >>>>>>> const char *state = NULL; >>>>>>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, >>>>>>> child); >>>>>>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", >>>>>>> child); >>>>>> >>>>>> Would not this break existing boards using old bindings? You need to >>>>>> handle both cases: if you can't located "led-gpios" then you will have >>>>>> to >>>>>> try just "gpios". >>>>> >>>>> Very true. I was rather even hoping we could update all bindings, I >>>>> don't >>>>> mind going through the available dts files to fix them ... But need to >>>>> know >>>>> that that's the proper way to go before doing the work ;) >>>> >>>> That will not work. You cannot make changes that require a new dtb >>>> with a new kernel. This would also break for the other way around >>>> (i.e. a new dtb and old kernel). >>>> >>>> You would have to search for both led-gpios and gpios. I'm not sure if >>>> we can do that generically for all GPIOs. If you had a node with both >>>> "blah-gpios" and "gpios", it would break. I would hope there are no >>>> such cases like that. We also now have to consider how ACPI identifies >>>> GPIOs and whether this makes sense. >>> >>> I think only the driver itself can know about such "legacy" mappings and >>> make a decision. >> >> Yeah leds-gpio.c will need to be patched to check for "led-gpios" first >> and then fall back to "gpios" if not found. > > yeah I've done the work, just need to double check it and resend a v2. > > Linus, I assume you want the already applied patches omitted from v2? Yes, please base new revisions on Linus' devel branch, omitting any patches that he has already accepted. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 19, 2015 at 12:43 PM, Alexandre Courbot <gnurou@gmail.com> wrote: > On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl <oliver@schinagl.nl> wrote: >> >> On 14-01-15 13:45, Linus Walleij wrote: >>> >>> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov >>> <dmitry.torokhov@gmail.com> wrote: >>>> >>>> On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote: >>>>> >>>>> On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@schinagl.nl> >>>>> wrote: >>>>>>>> >>>>>>>> --- a/drivers/leds/leds-gpio.c >>>>>>>> +++ b/drivers/leds/leds-gpio.c >>>>>>>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv >>>>>>>> *gpio_leds_create(struct >>>>>>>> platform_device *pdev) >>>>>>>> struct gpio_led led = {}; >>>>>>>> const char *state = NULL; >>>>>>>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, >>>>>>>> child); >>>>>>>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", >>>>>>>> child); >>>>>>> >>>>>>> Would not this break existing boards using old bindings? You need to >>>>>>> handle both cases: if you can't located "led-gpios" then you will have >>>>>>> to >>>>>>> try just "gpios". >>>>>> >>>>>> Very true. I was rather even hoping we could update all bindings, I >>>>>> don't >>>>>> mind going through the available dts files to fix them ... But need to >>>>>> know >>>>>> that that's the proper way to go before doing the work ;) >>>>> >>>>> That will not work. You cannot make changes that require a new dtb >>>>> with a new kernel. This would also break for the other way around >>>>> (i.e. a new dtb and old kernel). >>>>> >>>>> You would have to search for both led-gpios and gpios. I'm not sure if >>>>> we can do that generically for all GPIOs. If you had a node with both >>>>> "blah-gpios" and "gpios", it would break. I would hope there are no >>>>> such cases like that. We also now have to consider how ACPI identifies >>>>> GPIOs and whether this makes sense. >>>> >>>> I think only the driver itself can know about such "legacy" mappings and >>>> make a decision. >>> >>> Yeah leds-gpio.c will need to be patched to check for "led-gpios" first >>> and then fall back to "gpios" if not found. >> >> yeah I've done the work, just need to double check it and resend a v2. >> >> Linus, I assume you want the already applied patches omitted from v2? > > Yes, please base new revisions on Linus' devel branch, omitting any > patches that he has already accepted. Actually on top of breaking backward compatibility, I think the case of LED GPIOs is one of thoses where it makes sense to not have a name (the GPIO usage is obvious from the DT hierarchy, and there cannot be another one). So I don't feel like this change is really needed (other patches in this series are still useful though). -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index d544cf1..2c138cc 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -7,7 +7,7 @@ Each LED is represented as a sub-node of the gpio-leds device. Each node's name represents the name of the corresponding LED. LED sub-node properties: -- gpios : Should specify the LED's GPIO, see "gpios property" in +- led-gpios : Should specify the LED's GPIO, see "gpios property" in Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be indicated using flags in the GPIO specifier. - label : (optional) @@ -32,12 +32,12 @@ leds { compatible = "gpio-leds"; hdd { label = "IDE Activity"; - gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; + led-gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; linux,default-trigger = "ide-disk"; }; fault { - gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; + led-gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; /* Keep LED on if BIOS detected hardware fault */ default-state = "keep"; }; @@ -46,11 +46,11 @@ leds { run-control { compatible = "gpio-leds"; red { - gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>; + led-gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>; default-state = "off"; }; green { - gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; + led-gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; default-state = "on"; }; }; @@ -59,7 +59,7 @@ leds { compatible = "gpio-leds"; charger-led { - gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; + led-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; linux,default-trigger = "max8903-charger-charging"; retain-state-suspended; }; diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index 8e5af69..5b7bc84 100644 --- a/drivers/leds/leds-gpio.c +++ b/drivers/leds/leds-gpio.c @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev) struct gpio_led led = {}; const char *state = NULL; - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); if (IS_ERR(led.gpiod)) { fwnode_handle_put(child); goto err;