All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Alban Bedel <alban.bedel@lht.dlh.de>
Cc: Lee Jones <lee@kernel.org>,
	linux-leds@vger.kernel.org, Pavel Machek <pavel@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] leds: class: Use firmware nodes for device lookup
Date: Wed, 10 Jun 2026 18:48:07 +0200	[thread overview]
Message-ID: <aimVRwJPhlGxsIUj@tom-desktop> (raw)
In-Reply-To: <20260610170541.5d3b20d3@OMT-CWNXR4TFW5-LHT>

On Wed, Jun 10, 2026 at 05:05:41PM +0200, Alban Bedel wrote:
> On Wed, 10 Jun 2026 16:08:49 +0200
> Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> wrote:
> 
> > Hi Alban,
> > Thanks for your comments.
> > 
> > On Tue, Jun 09, 2026 at 06:54:29PM +0200, Alban Bedel wrote:
> > > On Tue, 9 Jun 2026 16:46:36 +0200
> > > Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> wrote:
> > >   
> > > > Hi Lee,
> > > > Thanks for your patch.
> > > > 
> > > > On Wed, May 20, 2026 at 04:22:25PM +0100, Lee Jones wrote:
> > > > [...]  
> > > > > What happens if fwnode_property_match_string() returns an
> > > > > error?    
> > > > 
> > > > Agree.
> > > > 
> > > > I think we need to check index:
> > > > 		if (index < 0)
> > > > 			return ERR_PTR(-ENOENT);  
> > > 
> > > I don't think that's the right solution. The documentation of
> > > fwnode_property_get_reference_args() says that it return -ENOENT
> > > when the index is out range. So it looks like the OF implementation
> > > has a bug.

On second thought, given the following call stack:

fwnode_led_get()
    fwnode_property_match_string() -> "led-names" not exist -> index = -EINVAL (-22, int)
    fwnode_find_reference(fwnode, "leds", index)
        /* int(-22) -> unsigned int( index > INT_MAX), fwnode_find_reference takes unsigned int */
        fwnode_property_get_reference_args(fwnode, name, NULL, 0, index, &args)
            of_fwnode_get_reference_args()
                /* index is already unsigned int( index > INT_MAX) */
                of_parse_phandle_with_fixed_args(, index,)
                    /* unsigned int(index > INT_MAX) -> int(-22), takes int */
                    __of_parse_phandle_with_args()
                        if (index < 0)
                            return -EINVAL;

The caller shouldn't pass a signed error as an unsigned int.
I think index should be check into fwnode_led_get().

Thanks, Tommaso

> > > 
> > > Looking at of_fwnode_get_reference_args() it directly pass the
> > > return value of __of_parse_phandle_with_args(), which return
> > > -EINVAL when the index is out of range. We should rather fix the OF
> > > implementation of fwnode_property_get_reference_args() to respect
> > > the documented interface.  
> > 
> > Maybe into of_fwnode_get_reference_args() first thing to do is to
> > check index with:
> > 
> > 	if (index > INT_MAX)
> > 		return -ENOENT;
> 
> Either that or fix it in __of_parse_phandle_with_args() which currently
> return -EINVAL for negative indexes. It is used for all variations of
> of_parse_phandle_with[_fixed|_optional|]_args() but none of these
> documented their error values.
> 
> A quick search showed that the vast majority of users either pass a
> constant index or a value from a loop under their control, so those
> would not be affected by such a change. From the one left all the one I
> checked overwrote the returned value with either -ENODEV or -ENOENT,
> but I haven't checked them all.
> 
> I would tend to do the fix in __of_parse_phandle_with_args() as I don't
> really see the value in differentiating negative index from too large
> ones in this API.
> 
> Alban
> 

  reply	other threads:[~2026-06-10 16:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 11:58 [PATCH v2] leds: class: Use firmware nodes for device lookup Alban Bedel
2026-05-20 15:22 ` Lee Jones
2026-06-09 14:46   ` Tommaso Merciai
2026-06-09 16:54     ` Alban Bedel
2026-06-10 14:08       ` Tommaso Merciai
2026-06-10 15:05         ` Alban Bedel
2026-06-10 16:48           ` Tommaso Merciai [this message]
2026-05-27 15:12 ` (subset) " Lee Jones

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=aimVRwJPhlGxsIUj@tom-desktop \
    --to=tommaso.merciai.xr@bp.renesas.com \
    --cc=alban.bedel@lht.dlh.de \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@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.