[PATCH] gpio-uclass: fix gpio lookup by label

[Simon Glass]

Hi Rasmus,

On Tue, 4 Oct 2022 at 07:43, Rasmus Villemoes
<rasmus.villemoes at prevas.dk> wrote:
>
> On 04/10/2022 01.49, Simon Glass wrote:
> > On Mon, 3 Oct 2022 at 03:03, Rasmus Villemoes
> > <rasmus.villemoes at prevas.dk> wrote:
> >>
> >> Matching anything that just happens to have the sought-for label as a
> >> prefix is wrong. For example, if the board designer has designated 10
> >> lines for debug purposes, named "debug1" through "debug10", and we are
> >> looking up "debug1", if debug10 happens to be met first during the
> >> iteration we'd wrongly return that.
> >>
> >> In theory, this can break existing users that could rely on this
> >> quirk, but OTOH keeping the current broken semantics can cause a lot
> >> of grief for people hitting this in the future and not understanding
> >> why they don't find the line they expect. Considering how few in-tree
> >> defconfigs currently set DM_GPIO_LOOKUP_LABEL (ignoring sandbox, only
> >> four "real" boards), let's fix it before the use becomes more
> >> widespread.
> >>
> >> Signed-off-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>
> >> ---
> >>  drivers/gpio/gpio-uclass.c | 4 +---
> >>  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > Reviewed-by: Simon Glass <sjg at chromium.org>
> >
> > It seems like we need a one-sided strncmp():
> >
> > int strncmp(const char *match, const char *str, int max_len_of_str)
>
> Eh, could you spell out what the semantics of that one would be? I can't
> think of anything that would differ from actual strncmp().
>
>   for (i = 0; i < m; ++i) {
>     if (a[i] != b[i]) return a[i] - b[i];
>     if (!a[i]) break;
>   }
>   return 0;
>
> And why would we want anything other than actual string equality here?

Your patch is fine which is why I added the tag.

>
> Oh, and now that I look at lib/string.c, both the generic strcmp() and
> strncmp() are broken. They correctly distinguish equality/inequality (up
> to the given bound), but they don't compare strings correctly, for
> several reasons. Sigh. Patch coming later.

OK.

Re the one-sided strncmp(), I mean that the second string has to be at
least as long as the first, but can be longer.

Regards,
Simon