[PATCH 5.10,5.15,6.1,6.6 RESEND] leds: spi-byte: Initialize device node before access

[PATCH 5.10,5.15,6.1,6.6 RESEND] leds: spi-byte: Initialize device node before access

[Tiffany Yang]

Commit 7f9ab862e05c ("leds: spi-byte: Call of_node_put() on error path")
was merged in 6.11 and then backported to stable trees through 5.10. It
relocates the line that initializes the variable 'child' to a later
point in spi_byte_probe().

Versions < 6.9 do not have commit ccc35ff2fd29 ("leds: spi-byte: Use
devm_led_classdev_register_ext()"), which removes a line that reads a
property from 'child' before its new initialization point. Consequently,
spi_byte_probe() reads from an uninitialized device node in stable
kernels 6.6-5.10.

Initialize 'child' before it is first accessed.

Fixes: 7f9ab862e05c ("leds: spi-byte: Call of_node_put() on error path")
Signed-off-by: Tiffany Yang <ynaffit@google.com>

---

As an alternative to moving the initialization of 'child' up,
Fedor Pchelkin proposed [1] backporting the change that removes the
intermediate access.

[1] https://lore.kernel.org/stable/20241029204128.527033-1-pchelkin@ispras.ru/
---
 drivers/leds/leds-spi-byte.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-spi-byte.c b/drivers/leds/leds-spi-byte.c
index afe9bff7c7c1..4520df1e2341 100644
--- a/drivers/leds/leds-spi-byte.c
+++ b/drivers/leds/leds-spi-byte.c
@@ -96,6 +96,7 @@ static int spi_byte_probe(struct spi_device *spi)
 	if (!led)
 		return -ENOMEM;
 
+	child = of_get_next_available_child(dev_of_node(dev), NULL);
 	of_property_read_string(child, "label", &name);
 	strscpy(led->name, name, sizeof(led->name));
 	led->spi = spi;
@@ -106,7 +107,6 @@ static int spi_byte_probe(struct spi_device *spi)
 	led->ldev.max_brightness = led->cdef->max_value - led->cdef->off_value;
 	led->ldev.brightness_set_blocking = spi_byte_brightness_set_blocking;
 
-	child = of_get_next_available_child(dev_of_node(dev), NULL);
 	state = of_get_property(child, "default-state", NULL);
 	if (state) {
 		if (!strcmp(state, "on")) {
-- 
2.52.0.351.gbe84eed79e-goog

Re: [PATCH 5.10,5.15,6.1,6.6 RESEND] leds: spi-byte: Initialize device node before access

[Andy Shevchenko]

On Tue, Dec 30, 2025 at 04:45:11PM -0800, Tiffany Yang wrote:
> Commit 7f9ab862e05c ("leds: spi-byte: Call of_node_put() on error path")
> was merged in 6.11 and then backported to stable trees through 5.10. It
> relocates the line that initializes the variable 'child' to a later
> point in spi_byte_probe().
> 
> Versions < 6.9 do not have commit ccc35ff2fd29 ("leds: spi-byte: Use
> devm_led_classdev_register_ext()"), which removes a line that reads a
> property from 'child' before its new initialization point. Consequently,
> spi_byte_probe() reads from an uninitialized device node in stable
> kernels 6.6-5.10.

I'm wondering if in long term the easier maintenance will be with that patch
also being backported rather than this being applied.

> Initialize 'child' before it is first accessed.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 5.10,5.15,6.1,6.6 RESEND] leds: spi-byte: Initialize device node before access

[Greg KH]

On Fri, Jan 02, 2026 at 02:37:19PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 30, 2025 at 04:45:11PM -0800, Tiffany Yang wrote:
> > Commit 7f9ab862e05c ("leds: spi-byte: Call of_node_put() on error path")
> > was merged in 6.11 and then backported to stable trees through 5.10. It
> > relocates the line that initializes the variable 'child' to a later
> > point in spi_byte_probe().
> > 
> > Versions < 6.9 do not have commit ccc35ff2fd29 ("leds: spi-byte: Use
> > devm_led_classdev_register_ext()"), which removes a line that reads a
> > property from 'child' before its new initialization point. Consequently,
> > spi_byte_probe() reads from an uninitialized device node in stable
> > kernels 6.6-5.10.
> 
> I'm wondering if in long term the easier maintenance will be with that patch
> also being backported rather than this being applied.

I agree, that might be simplest.

thanks,

greg k-h

Re: [PATCH 5.10,5.15,6.1,6.6 RESEND] leds: spi-byte: Initialize device node before access

[Lee Jones]

On Fri, 02 Jan 2026, Andy Shevchenko wrote:

> On Tue, Dec 30, 2025 at 04:45:11PM -0800, Tiffany Yang wrote:
> > Commit 7f9ab862e05c ("leds: spi-byte: Call of_node_put() on error path")
> > was merged in 6.11 and then backported to stable trees through 5.10. It
> > relocates the line that initializes the variable 'child' to a later
> > point in spi_byte_probe().
> > 
> > Versions < 6.9 do not have commit ccc35ff2fd29 ("leds: spi-byte: Use
> > devm_led_classdev_register_ext()"), which removes a line that reads a
> > property from 'child' before its new initialization point. Consequently,
> > spi_byte_probe() reads from an uninitialized device node in stable
> > kernels 6.6-5.10.
> 
> I'm wondering if in long term the easier maintenance will be with that patch
> also being backported rather than this being applied.

Works for me.

-- 
Lee Jones [李琼斯]

Re: [PATCH 5.10,5.15,6.1,6.6 RESEND] leds: spi-byte: Initialize device node before access

[Tiffany Yang]

Lee Jones <lee@kernel.org> writes:

> On Fri, 02 Jan 2026, Andy Shevchenko wrote:

>> On Tue, Dec 30, 2025 at 04:45:11PM -0800, Tiffany Yang wrote:
>> > Commit 7f9ab862e05c ("leds: spi-byte: Call of_node_put() on error  
>> path")
>> > was merged in 6.11 and then backported to stable trees through 5.10. It
>> > relocates the line that initializes the variable 'child' to a later
>> > point in spi_byte_probe().
>> >
>> > Versions < 6.9 do not have commit ccc35ff2fd29 ("leds: spi-byte: Use
>> > devm_led_classdev_register_ext()"), which removes a line that reads a
>> > property from 'child' before its new initialization point.  
>> Consequently,
>> > spi_byte_probe() reads from an uninitialized device node in stable
>> > kernels 6.6-5.10.

>> I'm wondering if in long term the easier maintenance will be with that  
>> patch
>> also being backported rather than this being applied.

> Works for me.

Makes sense to me too! Thanks everyone for taking a look, and thanks to
Fedor for originally suggesting this :)

-- 
Tiffany Y. Yang