Linux LED subsystem development
 help / color / mirror / Atom feed
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

  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