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

[Rasmus Villemoes]

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?

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.

Rasmus