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: 18+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox