All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Johan Adolfsson <johan.adolfsson@axis.com>,
	Pavel Machek <pavel@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Andrew Davis <afd@ti.com>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, kernel@axis.com
Subject: Re: [PATCH RFC v4 1/2] leds: leds-lp50xx: Handle reg to get correct multi_index
Date: Thu, 12 Jun 2025 11:53:41 +0100	[thread overview]
Message-ID: <20250612105341.GC381401@google.com> (raw)
In-Reply-To: <2bb62450-df35-4063-ac5e-60bc1ef8f5e7@gmail.com>

On Mon, 26 May 2025, Jacek Anaszewski wrote:

> Hi Johan,
> 
> On 5/26/25 16:54, Johan Adolfsson wrote:
> > mc_subled used for multi_index needs well defined array indexes,
> > to guarantee the desired result, optionally use reg for that.
> > 
> > If devicetree child nodes is processed in random or reverse order
> > you may end up with multi_index "blue green red" instead of the expected
> > "red green blue".
> > If user space apps uses multi_index to deduce how to control the leds
> > they would most likely be broken without this patch if devicetree
> > processing is reversed (which it appears to be).
> > 
> > arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts has reg set
> > but I don't see how it can have worked without this change.
> > 
> > If reg is not set, the previous behavior is kept, index will be in
> > the order nodes are processed.
> 
> This is a bug and I don't see any value in keeping buggy code.
> Just expect reg to be present and make sure that all in-tree
> dts files using these bindings use them in a proper way.
> 
> To not break existing users of stable releases, if any of them
> implement DT subnodes without 'reg' property, we can just not mark this
> commit with "Fixed" tag, so that it wasn't applied to stable releases.
> Although I am not sure if we should not fix it there as well.
> I'm leaving it to Lee.

We cannot assume that a patch won't end up in LTS just by omitting the
Fixes: tag.  Sasha's AUTOSEL tooling it still likely to pick it up if we
describe the commit as a fix, which we do and is correct.

I see no reason not to apply it.  If users are relying on broken
semantics, then those should be fixed also.

Is everyone happy with this patch as-is?

> > If reg is out of range, an error is returned.
> > reg within led child nodes starts with 0, to map to the iout in each bank.
> > 
> > Signed-off-by: Johan Adolfsson <johan.adolfsson@axis.com>
> > ---
> >   drivers/leds/leds-lp50xx.c | 8 +++++++-
> >   1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> > index 02cb1565a9fb..8067aaa916bf 100644
> > --- a/drivers/leds/leds-lp50xx.c
> > +++ b/drivers/leds/leds-lp50xx.c
> > @@ -476,6 +476,7 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
> >   			return -ENOMEM;
> >   		fwnode_for_each_child_node(child, led_node) {
> > +			int multi_index = num_colors;
> >   			ret = fwnode_property_read_u32(led_node, "color",
> >   						       &color_id);
> >   			if (ret) {
> > @@ -483,8 +484,13 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
> >   				dev_err(priv->dev, "Cannot read color\n");
> >   				return ret;
> >   			}
> > +			ret = fwnode_property_read_u32(led_node, "reg", &multi_index);
> > +			if (ret == 0 && multi_index >= LP50XX_LEDS_PER_MODULE) {
> > +				dev_err(priv->dev, "reg %i out of range\n", multi_index);
> > +				return -EINVAL;
> > +			}
> > -			mc_led_info[num_colors].color_index = color_id;
> > +			mc_led_info[multi_index].color_index = color_id;
> >   			num_colors++;
> >   		}
> > 
> 
> -- 
> Best regards,
> Jacek Anaszewski
> 

-- 
Lee Jones [李琼斯]

  reply	other threads:[~2025-06-12 10:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-26 14:53 [PATCH RFC v4 0/2] leds-lp50xx: Support reg to set multi_index Johan Adolfsson
2025-05-26 14:54 ` [PATCH RFC v4 1/2] leds: leds-lp50xx: Handle reg to get correct multi_index Johan Adolfsson
2025-05-26 21:54   ` Jacek Anaszewski
2025-06-12 10:53     ` Lee Jones [this message]
2025-06-14 13:38       ` Jacek Anaszewski
2025-06-19 10:02         ` Lee Jones
2025-05-26 14:54 ` [PATCH RFC v4 2/2] dt-bindings: leds: lp50xx: Document child reg, fix example Johan Adolfsson
2025-05-26 15:34   ` Krzysztof Kozlowski
2025-05-26 16:42     ` Johan Adolfsson
2025-05-27  5:48       ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250612105341.GC381401@google.com \
    --to=lee@kernel.org \
    --cc=afd@ti.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=johan.adolfsson@axis.com \
    --cc=kernel@axis.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.