lkml.org 
[lkml]   [2022]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] gpio: Allow user to customise maximum number of GPIOs
    Date


    Le 18/08/2022 à 14:46, Arnd Bergmann a écrit :
    > On Thu, Aug 18, 2022 at 2:25 PM Linus Walleij <linus.walleij@linaro.org> wrote:
    >> On Thu, Aug 18, 2022 at 1:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
    >>> On Thu, Aug 18, 2022 at 1:13 PM Linus Walleij <linus.walleij@linaro.org> wrote:
    >>>> I think there may be systems and users that still depend on GPIO base
    >>>> numbers being assigned from ARCH_NR_GPIOS and
    >>>> downwards (userspace GPIO numbers in sysfs will also change...)
    >>>> otherwise we could assign from 0 and up.
    >>>
    >>> Is it possible to find in-kernel users that depend on well-known
    >>> numbers for dynamically assigned gpios? I would argue
    >>> that those are always broken.
    >>
    >> Most in-kernel users hard-code the base to something like
    >> 0 etc it's only the ones that code -1 into .base that are in
    >> trouble because that will activate dynamic assignment for the
    >> base.
    >>
    >> git grep 'base = -1' yields these suspects:
    >>
    >> arch/arm/common/sa1111.c: sachip->gc.base = -1;
    >> arch/arm/common/scoop.c: devptr->gpio.base = -1;
    >> arch/powerpc/platforms/52xx/mpc52xx_gpt.c: gpt->gc.base = -1;
    >> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c: gc->base = -1;
    >>
    >> That's all! We could just calculate these to 512-ngpios and
    >> hardcode that instead.
    >
    > How do the consumers find the numbers for these four?
    >
    >>>> Right now the safest would be:
    >>>> Assign from 512 and downwards until we hit 0 then assign
    >>>> from something high, like U32_MAX and downward.
    >>>>
    >>>> That requires dropping gpio_is_valid() everywhere.
    >>>>
    >>>> If we wanna be bold, just delete gpio_is_valid() and assign
    >>>> bases from 0 and see what happens. But I think that will
    >>>> lead to regressions.
    >>>
    >>> I'm still unsure how removing gpio_is_valid() would help.
    >>
    >> If we allow GPIO base all the way to U32_MAX
    >> this function becomes:
    >>
    >> static inline bool gpio_is_valid(int number)
    >> {
    >> return number >= 0 && number < U32_MAX;
    >> }
    >>
    >> and we can then just
    >>
    >> #define gpio_is_valid true
    >>
    >> and in that case it is better to delete the use of this function
    >> altogether since it can not fail.
    >
    > S32_MAX might be a better upper bound. That allows to
    > just have no number assigned to a gpio chip. Any driver
    > code calling desc_to_gpio() could then get back -1
    > or a negative error code.
    >
    > Making the ones that are invalid today valid sounds like
    > a step backwards to me if the goal is to stop using
    > gpio numbers and most consumers no longer need them.
    >

    What about GPIO AGGREGATOR, drivers/gpio/gpio-aggregator.c

    bitmap = bitmap_alloc(ARCH_NR_GPIOS, GFP_KERNEL);


    Christophe
    \
     
     \ /
      Last update: 2022-08-18 15:13    [W:2.641 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site