Messages in this thread | | | From | Linus Walleij <> | Date | Thu, 18 Aug 2022 13:13:30 +0200 | Subject | Re: [PATCH] gpio: Allow user to customise maximum number of GPIOs |
| |
On Thu, Aug 18, 2022 at 11:48 AM Arnd Bergmann <arnd@arndb.de> wrote:
> As I understood, the problem that Christophe ran into is that the > dynamic registration of additional gpio chips is broken because > it unregisters the chip if the number space is exhausted: > > base = gpiochip_find_base(gc->ngpio); > if (base < 0) { > ret = base; > spin_unlock_irqrestore(&gpio_lock, flags); > goto err_free_label; > } > > From the git history, it looks like this error was never handled gracefully > even if the intention was to keep going without a number assignment, > so there are probably other bugs one runs into after changing this.
Hm that should be possible to get rid of altogether? I suppose it is only there to satisfy
static inline bool gpio_is_valid(int number) { return number >= 0 && number < ARCH_NR_GPIOS; }
?
If using GPIO descriptors, any descriptor != NULL is valid, this one is just used with legacy GPIOs. Maybe we should just delete gpio_is_valid() everywhere and then drop the cap?
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.
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.
Yours, Linus Walleij
| |