From: sashiko-bot@kernel.org
To: "Arnd Bergmann" <arnd@kernel.org>
Cc: linux-input@vger.kernel.org, linux-leds@vger.kernel.org,
dmitry.torokhov@gmail.com, lee@kernel.org
Subject: Re: [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
Date: Mon, 29 Jun 2026 13:46:12 +0000 [thread overview]
Message-ID: <20260629134613.F154B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629130329.1291953-7-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Drivers depending on `GPIOLIB_LEGACY` rather than selecting it are rendered unselectable and silently disabled on normal builds.
- [Low] Disabling CONFIG_GPIOLIB_LEGACY by default causes widespread build failures for platforms and drivers still relying on legacy GPIO functions.
--
commit bad1a2df68babe59200c7570528e8b8606464b68
Author: Arnd Bergmann <arnd@arndb.de>
gpiolib: turn off legacy interface by default
This commit changes the GPIOLIB_LEGACY configuration to default to 'n' instead
of 'y'. It restricts manual selection to builds where COMPILE_TEST is enabled,
intending to only build the legacy interface on platforms that require it.
> All users of the legacy interface now select CONFIG_GPIOLIB_LEGACY,
> so it can be turned off by default and only get built on platforms
> that still have one unconverted driver.
[Severity: High]
Is this description entirely accurate?
There appear to be drivers that use 'depends on GPIOLIB_LEGACY' rather than
selecting it, such as MFD_AAT2870_CORE, MFD_SI476X_CORE, and
SND_SOC_TLV320DAC33.
If GPIOLIB_LEGACY defaults to 'n' without COMPILE_TEST enabled, will these
drivers be rendered unselectable and silently disabled on normal builds?
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 020e51e30317a..543de15a12f63 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -4,7 +4,14 @@
> #
>
> config GPIOLIB_LEGACY
> - def_bool y
> + bool "Legacy GPIO interfaces" if COMPILE_TEST
[Severity: Low]
Could disabling this by default cause build failures on legacy platforms that
still call GPIO functions but do not explicitly select GPIOLIB_LEGACY?
For instance, arch/arm/mach-pxa/am200epd.c still uses gpio_request():
arch/arm/mach-pxa/am200epd.c:am200_init_gpio_regs() {
...
err = gpio_request(gpios[i], gpio_names[i]);
...
}
Because include/linux/gpio.h excludes the legacy prototypes when
CONFIG_GPIOLIB_LEGACY is disabled, will this cause implicit declaration
compiler errors during standard builds for architectures like PXA?
> + help
> + There are a few legacy platforms that use the traditional GPIO
> + number based interfaces instead of GPIO descriptors.
> + Say Y here to enable build testing drivers that are specific
> + to those platforms.
> +
> + If unsure, say N.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629130329.1291953-1-arnd@kernel.org?part=6
next prev parent reply other threads:[~2026-06-29 13:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 13:03 [PATCH v5 0/6] gpiolib: fence off legacy interfaces Arnd Bergmann
2026-06-29 13:03 ` [PATCH 1/6] [v5] sh: select legacy gpiolib interface Arnd Bergmann
2026-06-29 13:12 ` sashiko-bot
2026-06-29 13:03 ` [PATCH 2/6] [v5] x86/olpc: select GPIOLIB_LEGACY Arnd Bergmann
2026-06-29 13:25 ` sashiko-bot
2026-06-29 13:40 ` Arnd Bergmann
2026-06-29 13:03 ` [PATCH 3/6] [v5] Input: soc_button_array - select CONFIG_GPIOLIB_LEGACY Arnd Bergmann
2026-06-29 13:18 ` sashiko-bot
2026-06-29 13:03 ` [PATCH 4/6] [v5] Input: gpio-keys: make legacy gpiolib optional Arnd Bergmann
2026-06-29 13:32 ` sashiko-bot
2026-06-29 13:03 ` [PATCH 5/6] [v5] leds: gpio: make legacy gpiolib interface optional Arnd Bergmann
2026-06-29 13:38 ` sashiko-bot
2026-06-29 15:09 ` Andy Shevchenko
2026-06-29 15:58 ` Arnd Bergmann
2026-06-29 13:03 ` [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default Arnd Bergmann
2026-06-29 13:46 ` sashiko-bot [this message]
2026-06-29 14:13 ` Arnd Bergmann
2026-06-29 16:04 ` Geert Uytterhoeven
2026-06-30 14:17 ` [PATCH v5 0/6] gpiolib: fence off legacy interfaces Bartosz Golaszewski
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=20260629134613.F154B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=arnd@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=lee@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.