[PATCH 00/21] gpiolib: fence off legacy interfaces

[PATCH 00/21] gpiolib: fence off legacy interfaces

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Commit 678bae2eaa81 ("gpiolib: make legacy interfaces optional") was
merged for linux-6.17, so now it is possible to use the legacy interfaces
conditionally and eventually have the support left out of the kernel
whenever it is not needed.

I created six patches to force-enable CONFIG_GPIOLIB_LEGACY on the
few (mostly ancient) platforms that still require this, plus a set of
patches to either add the corresponding Kconfig dependencies that make
the device drivers conditional on that symbol, or change them to no
longer require it.

The final patch ends up turning the Kconfig symbol off by default,
which of course depends on everything else getting merged first to avoid
build errors.

I would suggest that patches 1-20 can just get merged through the
respective maintainer trees independently when they are deemed ready,
and the final patch can wait another merge window.

     Arnd

Arnd Bergmann (21):
  ARM: select legacy gpiolib interfaces where used
  m68k: coldfire: select legacy gpiolib interface for mcfqspi
  mips: select legacy gpiolib interfaces where used
  sh: select legacy gpiolib interface
  x86/platform: select legacy gpiolib interfaces where used
  x86/olpc: select GPIOLIB_LEGACY
  mfd: wm8994: remove dead legacy-gpio code
  ASoC: add GPIOLIB_LEGACY dependency where needed
  input: gpio-keys: make legacy gpiolib optional
  leds: gpio: make legacy gpiolib interface optional
  media: em28xx: add special case for legacy gpiolib interface
  mfd: arizona: make legacy gpiolib interface optional
  mfd: si476x: add GPIOLIB_LEGACY dependency
  mfd: aat2870: add GPIOLIB_LEGACY dependency
  dsa: b53: hide legacy gpiolib usage on non-mips
  ath10k: remove gpio number assignment
  nfc: marvell: convert to gpio descriptors
  nfc: s3fwrn5: convert to gpio descriptors
  usb: udc: pxa: remove unused platform_data
  ASoC: pxa: add GPIOLIB_LEGACY dependency
  gpiolib: turn off legacy interface by default

 arch/arm/mach-mv78xx0/Kconfig                 |  1 +
 arch/arm/mach-orion5x/Kconfig                 |  1 +
 arch/arm/mach-pxa/Kconfig                     |  1 +
 arch/arm/mach-pxa/devices.c                   |  7 --
 arch/arm/mach-pxa/gumstix.c                   |  1 -
 arch/arm/mach-pxa/udc.h                       |  8 --
 arch/arm/mach-s3c/Kconfig.s3c64xx             |  1 +
 arch/arm/mach-sa1100/Kconfig                  |  1 +
 arch/m68k/Kconfig.cpu                         |  1 +
 arch/mips/Kconfig                             |  5 +
 arch/mips/alchemy/Kconfig                     |  1 -
 arch/mips/txx9/Kconfig                        |  1 +
 arch/sh/Kconfig                               |  1 +
 arch/sh/boards/Kconfig                        |  8 ++
 arch/sh/boards/mach-highlander/Kconfig        |  1 +
 arch/sh/boards/mach-rsk/Kconfig               |  3 +
 arch/x86/Kconfig                              |  1 +
 drivers/gpio/Kconfig                          | 11 ++-
 drivers/input/keyboard/gpio_keys.c            |  5 +-
 drivers/input/keyboard/gpio_keys_polled.c     |  2 +
 drivers/input/misc/Kconfig                    |  3 +
 drivers/leds/leds-gpio.c                      |  8 +-
 drivers/media/usb/em28xx/Kconfig              |  1 +
 drivers/media/usb/em28xx/em28xx-dvb.c         |  4 +-
 drivers/mfd/Kconfig                           |  2 +
 drivers/mfd/arizona-irq.c                     |  5 +-
 drivers/mfd/rohm-bd71828.c                    |  2 +
 drivers/mfd/rohm-bd718x7.c                    |  2 +
 drivers/mfd/wm8994-irq.c                      | 94 +------------------
 drivers/net/dsa/b53/b53_common.c              | 17 +---
 drivers/net/dsa/b53/b53_priv.h                | 24 +++--
 drivers/net/wireless/ath/ath10k/leds.c        |  3 +-
 drivers/nfc/nfcmrvl/main.c                    | 47 +++-------
 drivers/nfc/nfcmrvl/nfcmrvl.h                 |  5 +-
 drivers/nfc/nfcmrvl/uart.c                    |  5 -
 drivers/nfc/nfcmrvl/usb.c                     |  1 -
 drivers/nfc/s3fwrn5/i2c.c                     | 42 +++------
 drivers/nfc/s3fwrn5/phy_common.c              | 12 +--
 drivers/nfc/s3fwrn5/phy_common.h              |  4 +-
 drivers/nfc/s3fwrn5/uart.c                    | 30 ++----
 drivers/platform/x86/Kconfig                  |  3 +
 .../platform/x86/x86-android-tablets/Kconfig  |  1 +
 drivers/usb/gadget/udc/pxa25x_udc.c           | 41 +++-----
 drivers/usb/gadget/udc/pxa25x_udc.h           |  2 +-
 drivers/usb/gadget/udc/pxa27x_udc.c           | 35 +------
 drivers/usb/gadget/udc/pxa27x_udc.h           |  2 -
 include/linux/gpio_keys.h                     |  2 +
 include/linux/leds.h                          |  2 +
 include/linux/mfd/arizona/pdata.h             |  6 ++
 include/linux/mfd/wm8994/pdata.h              |  5 -
 include/linux/platform_data/pxa2xx_udc.h      | 15 ---
 sound/pci/Kconfig                             |  1 +
 sound/soc/codecs/Kconfig                      |  4 +
 sound/soc/codecs/arizona-jack.c               | 17 +++-
 sound/soc/pxa/Kconfig                         |  4 +-
 55 files changed, 192 insertions(+), 320 deletions(-)
 delete mode 100644 arch/arm/mach-pxa/udc.h

-- 
2.39.5

Cc: Linus Walleij <linus.walleij@linaro.org> (maintainer:GPIO SUBSYSTEM,commit_signer:1/2=50%)
Cc: Bartosz Golaszewski <brgl@bgdev.pl> (maintainer:GPIO SUBSYSTEM,commit_signer:1/7=14%,commit_signer:1/2=50%)
Cc: linux-gpio@vger.kernel.org (open list:GPIO SUBSYSTEM)

Cc: Andrew Lunn <andrew@lunn.ch> (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC support)
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC support)
Cc: Gregory Clement <gregory.clement@bootlin.com> (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC support)
Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
Cc: Daniel Mack <daniel@zonque.org> (maintainer:PXA2xx/PXA3xx SUPPORT)
Cc: Haojian Zhuang <haojian.zhuang@gmail.com> (maintainer:PXA2xx/PXA3xx SUPPORT)
Cc: Robert Jarzmik <robert.jarzmik@free.fr> (maintainer:PXA2xx/PXA3xx SUPPORT)
Cc: Krzysztof Kozlowski <krzk@kernel.org> (maintainer:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,commit_signer:1/2=50%)
Cc: Alim Akhtar <alim.akhtar@samsung.com> (reviewer:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES)
Cc: Geert Uytterhoeven <geert@linux-m68k.org> (maintainer:M68K ARCHITECTURE,commit_signer:1/4=25%,authored:1/4=25%,added_lines:2/13=15%,removed_lines:2/6=33%)
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> (maintainer:MIPS)
Cc: Yoshinori Sato <ysato@users.sourceforge.jp> (maintainer:SUPERH)
Cc: Rich Felker <dalias@libc.org> (maintainer:SUPERH)
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> (maintainer:SUPERH,commit_signer:2/4=50%)
Cc: Thomas Gleixner <tglx@linutronix.de> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),added_lines:4/36=11%,removed_lines:6/49=12%)
Cc: Ingo Molnar <mingo@redhat.com> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Cc: Borislav Petkov <bp@alien8.de> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Cc: Dave Hansen <dave.hansen@linux.intel.com> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Cc: x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Cc: "H. Peter Anvin" <hpa@zytor.com> (reviewer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,commit_signer:5/7=71%,authored:1/7=14%,added_lines:17/36=47%,removed_lines:27/49=55%,commit_signer:1/2=50%,commit_signer:3/5=60%)
Cc: Lee Jones <lee@kernel.org> (maintainer:LED SUBSYSTEM,commit_signer:2/5=40%)
Cc: Pavel Machek <pavel@kernel.org> (maintainer:LED SUBSYSTEM)
Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer:EM28XX VIDEO4LINUX DRIVER)
Cc: Matti Vaittinen <mazziesaccount@gmail.com> (maintainer:ROHM POWER MANAGEMENT IC DEVICE DRIVERS)
Cc: Florian Fainelli <florian.fainelli@broadcom.com> (maintainer:BROADCOM B53/SF2 ETHERNET SWITCH DRIVER)
Cc: Jeff Johnson <jjohnson@kernel.org> (maintainer:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Cc: Hans de Goede <hansg@kernel.org> (maintainer:X86 PLATFORM DRIVERS,commit_signer:1/7=14%)
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> (maintainer:X86 PLATFORM DRIVERS)
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (maintainer:USB SUBSYSTEM)
Cc: Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND)
Cc: Takashi Iwai <tiwai@suse.com> (maintainer:SOUND,commit_signer:1/3=33%,authored:1/3=33%,removed_lines:2/2=100%)
Cc: Liam Girdwood <lgirdwood@gmail.com> (maintainer:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...)
Cc: Mark Brown <broonie@kernel.org> (maintainer:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,commit_signer:26/29=90%,commit_signer:1/3=33%)
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (authored:1/7=14%,added_lines:4/36=11%,removed_lines:6/49=12%,commit_signer:1/2=50%,authored:1/2=50%,added_lines:5/7=71%,removed_lines:7/7=100%,added_lines:7/7=100%,removed_lines:2/7=29%)
Cc: "Dr. David Alan Gilbert" <linux@treblig.org> (commit_signer:1/5=20%,authored:1/5=20%,removed_lines:7/10=70%)
Cc: linux-arm-kernel@lists.infradead.org (moderated list:ARM/Marvell Dove/MV78xx0/Orion SOC support)
Cc: linux-kernel@vger.kernel.org (open list)
Cc: linux-samsung-soc@vger.kernel.org (open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES)
Cc: linux-m68k@lists.linux-m68k.org (open list:M68K ARCHITECTURE)
Cc: linux-mips@vger.kernel.org (open list:MIPS)
Cc: linux-sh@vger.kernel.org (open list:SUPERH)
Cc: linux-input@vger.kernel.org (open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...)
Cc: linux-leds@vger.kernel.org (open list:LED SUBSYSTEM)
Cc: linux-media@vger.kernel.org (open list:EM28XX VIDEO4LINUX DRIVER)
Cc: patches@opensource.cirrus.com (open list:WOLFSON MICROELECTRONICS DRIVERS)
Cc: netdev@vger.kernel.org (open list:BROADCOM B53/SF2 ETHERNET SWITCH DRIVER)
Cc: linux-wireless@vger.kernel.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Cc: ath10k@lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Cc: platform-driver-x86@vger.kernel.org (open list:X86 PLATFORM DRIVERS)
Cc: linux-usb@vger.kernel.org (open list:USB SUBSYSTEM)
Cc: linux-sound@vger.kernel.org (open list:SOUND)

[PATCH 05/21] x86/platform: select legacy gpiolib interfaces where used

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

A few old machines have not been converted away from the old-style
gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
symbol so the code still works where it is needed but can be left
out otherwise.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/input/misc/Kconfig                       | 3 +++
 drivers/platform/x86/Kconfig                     | 3 +++
 drivers/platform/x86/x86-android-tablets/Kconfig | 1 +
 3 files changed, 7 insertions(+)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0fb21c99a5e3..681d4123ef2b 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -860,6 +860,9 @@ config INPUT_IDEAPAD_SLIDEBAR
 config INPUT_SOC_BUTTON_ARRAY
 	tristate "Windows-compatible SoC Button Array"
 	depends on KEYBOARD_GPIO && ACPI
+	depends on X86
+	depends on GPIOLIB
+	select GPIOLIB_LEGACY
 	help
 	  Say Y here if you have a SoC-based tablet that originally runs
 	  Windows 8 or a Microsoft Surface Book 2, Pro 5, Laptop 1 or later.
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 6d238e120dce..979a2fce8fc1 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -309,6 +309,7 @@ config MERAKI_MX100
 	depends on GPIOLIB
 	depends on GPIO_ICH
 	depends on LEDS_CLASS
+	select GPIOLIB_LEGACY
 	select LEDS_GPIO
 	help
 	  This driver provides support for the front button and LEDs on
@@ -564,6 +565,7 @@ config PCENGINES_APU2
 	depends on INPUT && INPUT_KEYBOARD && GPIOLIB
 	depends on LEDS_CLASS
 	select GPIO_AMD_FCH
+	select GPIOLIB_LEGACY
 	select KEYBOARD_GPIO_POLLED
 	select LEDS_GPIO
 	help
@@ -591,6 +593,7 @@ config PORTWELL_EC
 config BARCO_P50_GPIO
 	tristate "Barco P50 GPIO driver for identify LED/button"
 	depends on GPIOLIB
+	select GPIOLIB_LEGACY
 	help
 	  This driver provides access to the GPIOs for the identify button
 	  and led present on Barco P50 board.
diff --git a/drivers/platform/x86/x86-android-tablets/Kconfig b/drivers/platform/x86/x86-android-tablets/Kconfig
index 193da15ee01c..54fa6112c9ea 100644
--- a/drivers/platform/x86/x86-android-tablets/Kconfig
+++ b/drivers/platform/x86/x86-android-tablets/Kconfig
@@ -8,6 +8,7 @@ config X86_ANDROID_TABLETS
 	depends on I2C && SPI && SERIAL_DEV_BUS
 	depends on GPIOLIB && PMIC_OPREGION
 	depends on ACPI && EFI && PCI
+	select GPIOLIB_LEGACY
 	select NEW_LEDS
 	select LEDS_CLASS
 	select POWER_SUPPLY
-- 
2.39.5

[PATCH 09/21] input: gpio-keys: make legacy gpiolib optional

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Most users of gpio-keys and gpio-keys-polled use modern gpiolib
interfaces, but there are still number of ancient sh, arm32 and x86
machines that have never been converted.

Add an #ifdef block for the parts of the driver that are only
used on those legacy machines.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/input/keyboard/gpio_keys.c        | 5 +++--
 drivers/input/keyboard/gpio_keys_polled.c | 2 ++
 drivers/mfd/rohm-bd71828.c                | 2 ++
 drivers/mfd/rohm-bd718x7.c                | 2 ++
 include/linux/gpio_keys.h                 | 2 ++
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index f9db86da0818..984b20f773ed 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -528,6 +528,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 			 */
 			bdata->gpiod = NULL;
 		}
+#ifdef CONFIG_GPIOLIB_LEGACY
 	} else if (gpio_is_valid(button->gpio)) {
 		/*
 		 * Legacy GPIO number, so request the GPIO here and
@@ -546,6 +547,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 
 		if (button->active_low ^ gpiod_is_active_low(bdata->gpiod))
 			gpiod_toggle_active_low(bdata->gpiod);
+#endif
 	}
 
 	if (bdata->gpiod) {
@@ -583,8 +585,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 			if (irq < 0) {
 				error = irq;
 				dev_err_probe(dev, error,
-					      "Unable to get irq number for GPIO %d\n",
-					      button->gpio);
+					      "Unable to get irq number for GPIO\n");
 				return error;
 			}
 			bdata->irq = irq;
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index e6707d72210e..0ae0e53910ea 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -301,6 +301,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
 				return dev_err_probe(dev, PTR_ERR(bdata->gpiod),
 						     "failed to get gpio\n");
 			}
+#ifdef CONFIG_GPIOLIB_LEGACY
 		} else if (gpio_is_valid(button->gpio)) {
 			/*
 			 * Legacy GPIO number so request the GPIO here and
@@ -323,6 +324,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
 
 			if (button->active_low ^ gpiod_is_active_low(bdata->gpiod))
 				gpiod_toggle_active_low(bdata->gpiod);
+#endif
 		}
 
 		bdata->last_state = -1;
diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
index a14b7aa69c3c..fb68694fadca 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -21,7 +21,9 @@
 
 static struct gpio_keys_button button = {
 	.code = KEY_POWER,
+#ifdef CONFIG_GPIOLIB_LEGACY
 	.gpio = -1,
+#endif
 	.type = EV_KEY,
 };
 
diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
index 25e494a93d48..6c99ab62e31b 100644
--- a/drivers/mfd/rohm-bd718x7.c
+++ b/drivers/mfd/rohm-bd718x7.c
@@ -20,7 +20,9 @@
 
 static struct gpio_keys_button button = {
 	.code = KEY_POWER,
+#ifdef CONFIG_GPIOLIB_LEGACY
 	.gpio = -1,
+#endif
 	.type = EV_KEY,
 };
 
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index 80fa930b04c6..e8d6dc290efb 100644
--- a/include/linux/gpio_keys.h
+++ b/include/linux/gpio_keys.h
@@ -25,7 +25,9 @@ struct device;
  */
 struct gpio_keys_button {
 	unsigned int code;
+#ifdef CONFIG_GPIOLIB_LEGACY
 	int gpio;
+#endif
 	int active_low;
 	const char *desc;
 	unsigned int type;
-- 
2.39.5

Re: [PATCH 05/21] x86/platform: select legacy gpiolib interfaces where used

[Andy Shevchenko]

On Fri, Aug 08, 2025 at 05:17:49PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> A few old machines have not been converted away from the old-style
> gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
> symbol so the code still works where it is needed but can be left
> out otherwise.

...

> --- a/drivers/platform/x86/x86-android-tablets/Kconfig
> +++ b/drivers/platform/x86/x86-android-tablets/Kconfig
> @@ -8,6 +8,7 @@ config X86_ANDROID_TABLETS
>  	depends on I2C && SPI && SERIAL_DEV_BUS
>  	depends on GPIOLIB && PMIC_OPREGION
>  	depends on ACPI && EFI && PCI
> +	select GPIOLIB_LEGACY
>  	select NEW_LEDS
>  	select LEDS_CLASS
>  	select POWER_SUPPLY

Hmm... This is a surprising change. But I leave it to Hans.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 05/21] x86/platform: select legacy gpiolib interfaces where used

[Arnd Bergmann]

On Sat, Aug 9, 2025, at 12:00, Andy Shevchenko wrote:
> On Fri, Aug 08, 2025 at 05:17:49PM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>> 
>> A few old machines have not been converted away from the old-style
>> gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
>> symbol so the code still works where it is needed but can be left
>> out otherwise.
>
>> --- a/drivers/platform/x86/x86-android-tablets/Kconfig
>> +++ b/drivers/platform/x86/x86-android-tablets/Kconfig
>> @@ -8,6 +8,7 @@ config X86_ANDROID_TABLETS
>>  	depends on I2C && SPI && SERIAL_DEV_BUS
>>  	depends on GPIOLIB && PMIC_OPREGION
>>  	depends on ACPI && EFI && PCI
>> +	select GPIOLIB_LEGACY
>>  	select NEW_LEDS
>>  	select LEDS_CLASS
>>  	select POWER_SUPPLY
>
> Hmm... This is a surprising change. But I leave it to Hans.

I think the only function that still needs it is
x86_android_tablet_probe() doing

static struct gpio_keys_button *buttons;

                for (i = 0; i < dev_info->gpio_button_count; i++) {
                        ret = x86_android_tablet_get_gpiod(dev_info->gpio_button[i].chip,
                                                           dev_info->gpio_button[i].pin,
                                                           dev_info->gpio_button[i].button.desc,
                                                           false, GPIOD_IN, &gpiod);

                        buttons[i] = dev_info->gpio_button[i].button;
                        buttons[i].gpio = desc_to_gpio(gpiod);
                        /* Release GPIO descriptor so that gpio-keys can request it */
                        devm_gpiod_put(&x86_android_tablet_device->dev, gpiod);
                }

So the driver itself uses gpio descriptors, but it passes
some of them into another driver by number. There is probably
an easy workaround that I did not see.

      Arnd

Re: [PATCH 05/21] x86/platform: select legacy gpiolib interfaces where used

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 3900 bytes --]

Hi Arnd, Andy,

On 9-Aug-25 9:44 PM, Arnd Bergmann wrote:
> On Sat, Aug 9, 2025, at 12:00, Andy Shevchenko wrote:
>> On Fri, Aug 08, 2025 at 05:17:49PM +0200, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> A few old machines have not been converted away from the old-style
>>> gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
>>> symbol so the code still works where it is needed but can be left
>>> out otherwise.
>>
>>> --- a/drivers/platform/x86/x86-android-tablets/Kconfig
>>> +++ b/drivers/platform/x86/x86-android-tablets/Kconfig
>>> @@ -8,6 +8,7 @@ config X86_ANDROID_TABLETS
>>>  	depends on I2C && SPI && SERIAL_DEV_BUS
>>>  	depends on GPIOLIB && PMIC_OPREGION
>>>  	depends on ACPI && EFI && PCI
>>> +	select GPIOLIB_LEGACY
>>>  	select NEW_LEDS
>>>  	select LEDS_CLASS
>>>  	select POWER_SUPPLY
>>
>> Hmm... This is a surprising change. But I leave it to Hans.

Yes I was surprised by this myself since I explicitly removed
all legacy GPIO use from the x86-android-tablets code a while
ago (or so I thought).

> I think the only function that still needs it is
> x86_android_tablet_probe() doing
> 
> static struct gpio_keys_button *buttons;
> 
>                 for (i = 0; i < dev_info->gpio_button_count; i++) {
>                         ret = x86_android_tablet_get_gpiod(dev_info->gpio_button[i].chip,
>                                                            dev_info->gpio_button[i].pin,
>                                                            dev_info->gpio_button[i].button.desc,
>                                                            false, GPIOD_IN, &gpiod);
> 
>                         buttons[i] = dev_info->gpio_button[i].button;
>                         buttons[i].gpio = desc_to_gpio(gpiod);
>                         /* Release GPIO descriptor so that gpio-keys can request it */
>                         devm_gpiod_put(&x86_android_tablet_device->dev, gpiod);
>                 }
> 
> So the driver itself uses gpio descriptors, but it passes
> some of them into another driver by number. There is probably
> an easy workaround that I did not see.

Ah I see, so this is basically in the same boat as
drivers/input/misc/soc_button_array.c which also first
gets a gpio_desc and then calls desc_to_gpio() to store
the GPIO number in struct gpio_keys_button which is passed
as platform_data to drivers/input/keyboard/gpio_keys.c

The gpio_keys driver then converts things back
into a gpio_desc in gpio_keys_setup_key()
using devm_gpio_request_one() + gpio_to_desc()

So it looks like we need to add a gpiod member to
struct gpio_keys_button (include/linux/gpio_keys.h)
and modify gpio_keys.c to prefer that over using
button->gpio, something like the attached patch
basically.

I won't have time to work on this until September,
so if someone wants to take the attached patch and run
with it go for it.

Note the x86-android-tablets / soc_button_array code
will become responsible for requesting / releasing
the gpiod when using the new gpio_keys_button.gpiod
member.

For the x86-android-tablets code this is easy, just drop
these 2 lines:

                        /* Release GPIO descriptor so that gpio-keys can request it */
                        devm_gpiod_put(&x86_android_tablet_device->dev, gpiod);

And for soc_button_array.c it is _probably_ just a matter
of switching to devm_gpiod_get_index() and drop the
gpiod_put().

I have hardware to test both the x86-android-tablets
code as well as the soc_button_array code. I might be
able to do a quick test on August 22nd or 29th.

Regards,

Hans


p.s.

It looks like this will also help with:

drivers/platform/x86/meraki-mx100.c
drivers/platform/x86/pcengines-apuv2.c
drivers/platform/x86/barco-p50-gpio.c

I do not have hardware to test these, but if the changes
work for x86-android-tablets + soc_button_array then
hopefully they will be fine here too.

[-- Attachment #2: 0001-Input-gpio-keys-Allow-directly-passing-a-gpio_desc-i.patch --]
[-- Type: text/x-patch, Size: 2112 bytes --]

From 6fe4bd731db59bb01cc0ce3cbd2412434ea053c6 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hansg@kernel.org>
Date: Sun, 10 Aug 2025 16:58:01 +0200
Subject: [PATCH] Input: gpio-keys - Allow directly passing a gpio_desc instead
 of a GPIO number

Using GPIO numbers is deprecated. Allow code passing GPIO-keys info through
platform-data (struct gpio_keys_button) to directly pass a gpio_desc
instead of a GPIO number.

Note requesting / releasing the gpio_desc will be the responsibility
of the code passing in the platform-data.

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/input/keyboard/gpio_keys.c | 2 ++
 include/linux/gpio_keys.h          | 5 ++++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index f9db86da0818..323247f63a7e 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -528,6 +528,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 			 */
 			bdata->gpiod = NULL;
 		}
+	} else if (button->gpiod) {
+		bdata->gpiod = button->gpiod;
 	} else if (gpio_is_valid(button->gpio)) {
 		/*
 		 * Legacy GPIO number, so request the GPIO here and
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index 80fa930b04c6..7c32c3a0695f 100644
--- a/include/linux/gpio_keys.h
+++ b/include/linux/gpio_keys.h
@@ -5,11 +5,13 @@
 #include <linux/types.h>
 
 struct device;
+struct gpio_desc;
 
 /**
  * struct gpio_keys_button - configuration parameters
  * @code:		input event code (KEY_*, SW_*)
- * @gpio:		%-1 if this key does not support gpio
+ * @gpio:		%-1 if this key does not support gpio (deprecated use gpiod)
+ * @gpiod:		gpio_desc for the GPIO, NULL if this key does not support gpio
  * @active_low:		%true indicates that button is considered
  *			depressed when gpio is low
  * @desc:		label that will be attached to button's gpio
@@ -26,6 +28,7 @@ struct device;
 struct gpio_keys_button {
 	unsigned int code;
 	int gpio;
+	struct gpio_desc *gpiod;
 	int active_low;
 	const char *desc;
 	unsigned int type;
-- 
2.49.0

Re: [PATCH 05/21] x86/platform: select legacy gpiolib interfaces where used

[Dmitry Torokhov]

Hi Hans,

On Sun, Aug 10, 2025 at 05:12:46PM +0200, Hans de Goede wrote:
> Hi Arnd, Andy,
> 
> On 9-Aug-25 9:44 PM, Arnd Bergmann wrote:
> > On Sat, Aug 9, 2025, at 12:00, Andy Shevchenko wrote:
> >> On Fri, Aug 08, 2025 at 05:17:49PM +0200, Arnd Bergmann wrote:
> >>> From: Arnd Bergmann <arnd@arndb.de>
> >>>
> >>> A few old machines have not been converted away from the old-style
> >>> gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
> >>> symbol so the code still works where it is needed but can be left
> >>> out otherwise.
> >>
> >>> --- a/drivers/platform/x86/x86-android-tablets/Kconfig
> >>> +++ b/drivers/platform/x86/x86-android-tablets/Kconfig
> >>> @@ -8,6 +8,7 @@ config X86_ANDROID_TABLETS
> >>>  	depends on I2C && SPI && SERIAL_DEV_BUS
> >>>  	depends on GPIOLIB && PMIC_OPREGION
> >>>  	depends on ACPI && EFI && PCI
> >>> +	select GPIOLIB_LEGACY
> >>>  	select NEW_LEDS
> >>>  	select LEDS_CLASS
> >>>  	select POWER_SUPPLY
> >>
> >> Hmm... This is a surprising change. But I leave it to Hans.
> 
> Yes I was surprised by this myself since I explicitly removed
> all legacy GPIO use from the x86-android-tablets code a while
> ago (or so I thought).
> 
> > I think the only function that still needs it is
> > x86_android_tablet_probe() doing
> > 
> > static struct gpio_keys_button *buttons;
> > 
> >                 for (i = 0; i < dev_info->gpio_button_count; i++) {
> >                         ret = x86_android_tablet_get_gpiod(dev_info->gpio_button[i].chip,
> >                                                            dev_info->gpio_button[i].pin,
> >                                                            dev_info->gpio_button[i].button.desc,
> >                                                            false, GPIOD_IN, &gpiod);
> > 
> >                         buttons[i] = dev_info->gpio_button[i].button;
> >                         buttons[i].gpio = desc_to_gpio(gpiod);
> >                         /* Release GPIO descriptor so that gpio-keys can request it */
> >                         devm_gpiod_put(&x86_android_tablet_device->dev, gpiod);
> >                 }
> > 
> > So the driver itself uses gpio descriptors, but it passes
> > some of them into another driver by number. There is probably
> > an easy workaround that I did not see.
> 
> Ah I see, so this is basically in the same boat as
> drivers/input/misc/soc_button_array.c which also first
> gets a gpio_desc and then calls desc_to_gpio() to store
> the GPIO number in struct gpio_keys_button which is passed
> as platform_data to drivers/input/keyboard/gpio_keys.c
> 
> The gpio_keys driver then converts things back
> into a gpio_desc in gpio_keys_setup_key()
> using devm_gpio_request_one() + gpio_to_desc()
> 
> So it looks like we need to add a gpiod member to
> struct gpio_keys_button (include/linux/gpio_keys.h)
> and modify gpio_keys.c to prefer that over using
> button->gpio, something like the attached patch
> basically.
> 
> I won't have time to work on this until September,
> so if someone wants to take the attached patch and run
> with it go for it.
> 
> Note the x86-android-tablets / soc_button_array code
> will become responsible for requesting / releasing
> the gpiod when using the new gpio_keys_button.gpiod
> member.
> 
> For the x86-android-tablets code this is easy, just drop
> these 2 lines:
> 
>                         /* Release GPIO descriptor so that gpio-keys can request it */
>                         devm_gpiod_put(&x86_android_tablet_device->dev, gpiod);
> 
> And for soc_button_array.c it is _probably_ just a matter
> of switching to devm_gpiod_get_index() and drop the
> gpiod_put().
> 
> I have hardware to test both the x86-android-tablets
> code as well as the soc_button_array code. I might be
> able to do a quick test on August 22nd or 29th.

I just sent out a v2 of my series from '23 converting
x86-android-tablets to use PROPERTY_ENTRY_GPIO(), including converting
buttons and switches:


https://lore.kernel.org/all/20250810-x86-andoroid-tablet-v2-0-9c7a1b3c32b2@gmail.com/

I do not have hardware so it probably is busted but if you could make it
work that would be great.

Thanks.

-- 
Dmitry

Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional

[Matti Vaittinen]

Hi dee Ho peeps,

On 08/08/2025 18:17, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Most users of gpio-keys and gpio-keys-polled use modern gpiolib
> interfaces, but there are still number of ancient sh, arm32 and x86
> machines that have never been converted.
> 
> Add an #ifdef block for the parts of the driver that are only
> used on those legacy machines.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>   drivers/input/keyboard/gpio_keys.c        | 5 +++--
>   drivers/input/keyboard/gpio_keys_polled.c | 2 ++
>   drivers/mfd/rohm-bd71828.c                | 2 ++
>   drivers/mfd/rohm-bd718x7.c                | 2 ++
>   include/linux/gpio_keys.h                 | 2 ++
>   5 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index f9db86da0818..984b20f773ed 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -528,6 +528,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
>   			 */
>   			bdata->gpiod = NULL;
>   		}
> +#ifdef CONFIG_GPIOLIB_LEGACY
>   	} else if (gpio_is_valid(button->gpio)) {
>   		/*
>   		 * Legacy GPIO number, so request the GPIO here and
> @@ -546,6 +547,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
>   
>   		if (button->active_low ^ gpiod_is_active_low(bdata->gpiod))
>   			gpiod_toggle_active_low(bdata->gpiod);
> +#endif
>   	}
>   
>   	if (bdata->gpiod) {
> @@ -583,8 +585,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
>   			if (irq < 0) {
>   				error = irq;
>   				dev_err_probe(dev, error,
> -					      "Unable to get irq number for GPIO %d\n",
> -					      button->gpio);
> +					      "Unable to get irq number for GPIO\n");
>   				return error;
>   			}
>   			bdata->irq = irq;
> diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
> index e6707d72210e..0ae0e53910ea 100644
> --- a/drivers/input/keyboard/gpio_keys_polled.c
> +++ b/drivers/input/keyboard/gpio_keys_polled.c
> @@ -301,6 +301,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
>   				return dev_err_probe(dev, PTR_ERR(bdata->gpiod),
>   						     "failed to get gpio\n");
>   			}
> +#ifdef CONFIG_GPIOLIB_LEGACY
>   		} else if (gpio_is_valid(button->gpio)) {
>   			/*
>   			 * Legacy GPIO number so request the GPIO here and
> @@ -323,6 +324,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
>   
>   			if (button->active_low ^ gpiod_is_active_low(bdata->gpiod))
>   				gpiod_toggle_active_low(bdata->gpiod);
> +#endif
>   		}
>   
>   		bdata->last_state = -1;
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index a14b7aa69c3c..fb68694fadca 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -21,7 +21,9 @@
>   
>   static struct gpio_keys_button button = {
>   	.code = KEY_POWER,
> +#ifdef CONFIG_GPIOLIB_LEGACY
>   	.gpio = -1,
> +#endif
>   	.type = EV_KEY,
>   };
>   
> diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
> index 25e494a93d48..6c99ab62e31b 100644
> --- a/drivers/mfd/rohm-bd718x7.c
> +++ b/drivers/mfd/rohm-bd718x7.c
> @@ -20,7 +20,9 @@
>   
>   static struct gpio_keys_button button = {
>   	.code = KEY_POWER,
> +#ifdef CONFIG_GPIOLIB_LEGACY
>   	.gpio = -1,
> +#endif
>   	.type = EV_KEY,
>   };
>   
> diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
> index 80fa930b04c6..e8d6dc290efb 100644
> --- a/include/linux/gpio_keys.h
> +++ b/include/linux/gpio_keys.h
> @@ -25,7 +25,9 @@ struct device;
>    */
>   struct gpio_keys_button {
>   	unsigned int code;
> +#ifdef CONFIG_GPIOLIB_LEGACY
>   	int gpio;
> +#endif
>   	int active_low;
>   	const char *desc;
>   	unsigned int type;

AFAIR, these ROHM PMICs (bd718[15, 27, 28, 37, 47, 50, 78, 85]) all 
provide a 'button IRQ', from a power button. (Or, couple of IRQs but 
let's skip the details) The gpio-keys is used to send the KEY_POWER 
event when IRQ is detected.

The IRQ comes from the PMIC, and the regmap_irq chip provided by the MFD 
provides it. This IRQ information is delivered to the gpio-keys from the 
MFD driver via platform data. That's basically what these "button" 
structs are here for. No GPIO line information (only the IRQ number) is 
needed to be delivered to the gpio-keys. This problematic assignment:

 > +#ifdef CONFIG_GPIOLIB_LEGACY
 >   	.gpio = -1,
 > +#endif

is only needed to invalidate the gpio information so that the gpio-keys 
wont use it, only the IRQ.

As such, this patch seems Ok to me, you can treat this as an ack :) 
This, however made me ponder following - is this the tight way to handle 
the power-button IRQ? I don't see any other MFD devices doing this in 
same way, although I am pretty sure there are other PMICs with similar 
power-button IRQ...

I see for example the "drivers/mfd/rt5120.c" to invoke 
"drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. 
This, however, feels like code duplication to me. I'd rather kept using 
the gpio-keys, but seeing:

git grep KEY_POWER drivers/mfd/
drivers/mfd/rohm-bd71828.c:     .code = KEY_POWER,
drivers/mfd/rohm-bd718x7.c:     .code = KEY_POWER,

makes me wonder if there is more widely used (better) way?

Yours,
	-- Matti

Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional

[Andy Shevchenko]

On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
> On 08/08/2025 18:17, Arnd Bergmann wrote:

...

> As such, this patch seems Ok to me, you can treat this as an ack :) This,
> however made me ponder following - is this the tight way to handle the
> power-button IRQ? I don't see any other MFD devices doing this in same way,
> although I am pretty sure there are other PMICs with similar power-button
> IRQ...
> 
> I see for example the "drivers/mfd/rt5120.c" to invoke
> "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
> however, feels like code duplication to me. I'd rather kept using the
> gpio-keys, but seeing:
> 
> git grep KEY_POWER drivers/mfd/
> drivers/mfd/rohm-bd71828.c:     .code = KEY_POWER,
> drivers/mfd/rohm-bd718x7.c:     .code = KEY_POWER,
> 
> makes me wonder if there is more widely used (better) way?

FWIW, on Intel platforms that use power button by PMIC we add a special driver
for each of such cases.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 00/21] gpiolib: fence off legacy interfaces

[Bartosz Golaszewski]

On Fri, 8 Aug 2025 17:17:44 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Commit 678bae2eaa81 ("gpiolib: make legacy interfaces optional") was
> merged for linux-6.17, so now it is possible to use the legacy interfaces
> conditionally and eventually have the support left out of the kernel
> whenever it is not needed.
>
> I created six patches to force-enable CONFIG_GPIOLIB_LEGACY on the
> few (mostly ancient) platforms that still require this, plus a set of
> patches to either add the corresponding Kconfig dependencies that make
> the device drivers conditional on that symbol, or change them to no
> longer require it.
>
> The final patch ends up turning the Kconfig symbol off by default,
> which of course depends on everything else getting merged first to avoid
> build errors.
>
> I would suggest that patches 1-20 can just get merged through the
> respective maintainer trees independently when they are deemed ready,
> and the final patch can wait another merge window.
>

Oh, not at all, I'm fine sending a second PR late into the merge window to
get that done in a single cycle.

Thanks for doing this, awesome work!

Bartosz

Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional

[Dmitry Torokhov]

On Mon, Aug 11, 2025 at 03:52:19PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
> > On 08/08/2025 18:17, Arnd Bergmann wrote:
> 
> ...
> 
> > As such, this patch seems Ok to me, you can treat this as an ack :) This,
> > however made me ponder following - is this the tight way to handle the
> > power-button IRQ? I don't see any other MFD devices doing this in same way,
> > although I am pretty sure there are other PMICs with similar power-button
> > IRQ...
> > 
> > I see for example the "drivers/mfd/rt5120.c" to invoke
> > "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
> > however, feels like code duplication to me. I'd rather kept using the
> > gpio-keys, but seeing:
> > 
> > git grep KEY_POWER drivers/mfd/
> > drivers/mfd/rohm-bd71828.c:     .code = KEY_POWER,
> > drivers/mfd/rohm-bd718x7.c:     .code = KEY_POWER,
> > 
> > makes me wonder if there is more widely used (better) way?
> 
> FWIW, on Intel platforms that use power button by PMIC we add a special driver
> for each of such cases.

If we can make gpio-keys work for various power buttons that would be
great IMO. The MFD drivers in question already are using device tree,
but they do not define/expect nodes for the power buttons. If the nodes
were there then I think gpio-keys would work out of the box?

Thanks.

-- 
Dmitry

Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional

[Andy Shevchenko]

On Mon, Aug 11, 2025 at 12:21:51PM -0700, Dmitry Torokhov wrote:
> On Mon, Aug 11, 2025 at 03:52:19PM +0300, Andy Shevchenko wrote:
> > On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
> > > On 08/08/2025 18:17, Arnd Bergmann wrote:

...

> > > As such, this patch seems Ok to me, you can treat this as an ack :) This,
> > > however made me ponder following - is this the tight way to handle the
> > > power-button IRQ? I don't see any other MFD devices doing this in same way,
> > > although I am pretty sure there are other PMICs with similar power-button
> > > IRQ...
> > > 
> > > I see for example the "drivers/mfd/rt5120.c" to invoke
> > > "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
> > > however, feels like code duplication to me. I'd rather kept using the
> > > gpio-keys, but seeing:
> > > 
> > > git grep KEY_POWER drivers/mfd/
> > > drivers/mfd/rohm-bd71828.c:     .code = KEY_POWER,
> > > drivers/mfd/rohm-bd718x7.c:     .code = KEY_POWER,
> > > 
> > > makes me wonder if there is more widely used (better) way?
> > 
> > FWIW, on Intel platforms that use power button by PMIC we add a special driver
> > for each of such cases.
> 
> If we can make gpio-keys work for various power buttons that would be
> great IMO. The MFD drivers in question already are using device tree,
> but they do not define/expect nodes for the power buttons. If the nodes
> were there then I think gpio-keys would work out of the box?

Looking at the, e.g., https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/x86/intel/mrfld_pwrbtn.c,
I am not sure it's as simply as it sounds. Basically it's an IRQ, which
requires IRQ handling and proper acking/masking/etc.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional

[Matti Vaittinen]

On 11/08/2025 23:09, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 12:21:51PM -0700, Dmitry Torokhov wrote:
>> On Mon, Aug 11, 2025 at 03:52:19PM +0300, Andy Shevchenko wrote:
>>> On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
>>>> On 08/08/2025 18:17, Arnd Bergmann wrote:
> 
> ...
> 
>>>> As such, this patch seems Ok to me, you can treat this as an ack :) This,
>>>> however made me ponder following - is this the tight way to handle the
>>>> power-button IRQ? I don't see any other MFD devices doing this in same way,
>>>> although I am pretty sure there are other PMICs with similar power-button
>>>> IRQ...
>>>>
>>>> I see for example the "drivers/mfd/rt5120.c" to invoke
>>>> "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
>>>> however, feels like code duplication to me. I'd rather kept using the
>>>> gpio-keys, but seeing:
>>>>
>>>> git grep KEY_POWER drivers/mfd/
>>>> drivers/mfd/rohm-bd71828.c:     .code = KEY_POWER,
>>>> drivers/mfd/rohm-bd718x7.c:     .code = KEY_POWER,
>>>>
>>>> makes me wonder if there is more widely used (better) way?
>>>
>>> FWIW, on Intel platforms that use power button by PMIC we add a special driver
>>> for each of such cases.
>>
>> If we can make gpio-keys work for various power buttons that would be
>> great IMO. The MFD drivers in question already are using device tree,
>> but they do not define/expect nodes for the power buttons. If the nodes
>> were there then I think gpio-keys would work out of the box?
> 
> Looking at the, e.g., https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/x86/intel/mrfld_pwrbtn.c,
> I am not sure it's as simply as it sounds. Basically it's an IRQ, which
> requires IRQ handling and proper acking/masking/etc.

In some (many?) cases the interrupts (acking/masking) are handled by an 
irqchip code. When this is the case, the gpio-keys (or any other 
power-button code) does not need to care about IRQ-specifics. (I don't 
know about the Intel driver though.)

Problem with many of the bd718* (and probably some other MFD drivers) 
is, that the interrupts are really relevant only for the drivers 
specific to this one device (like PMIC in ROHM case). When this is the 
case, the device is not really (from the HW perspective) an 
interrupt-controller, which means it shouldn't probably be marked as one 
in the device-tree either. It will then also mean that there can't be 
meaningful interrupt specification for the button IRQ in the 
device-tree, right?

Additionally, we have devices where most of the interrupts are internal 
to the PMIC, but then the PMIC also has some pins usable as GPIO, which 
can be used as interrupt sources. Eg, someone can connect another device 
to these pins - which makes the PMIC an interrupt-controller. For these 
PMICs the power-button IRQ can be provided via device-tree node (but the 
IRQ spec may become a bit hairy, since most of the IRQs are meant to be 
internal).

Hence, for me, providing the IRQ number in platform data seems still to 
be the right thing to do :)

TLDR; I agree with Dmitry. It's nice to have an easily re-usable 
power-button handler, which requires no IC-specific code. Gpio-keys 
works for simple IRQ based power-buttons where IRQ controller takes care 
of the acks/masks. I just wanted to know if it is for some reason 
discouraged, or if I've used it in a wrong way (because the grep 
resulted so few results).

Yours,
	-- Matti

Re: (subset) [PATCH 00/21] gpiolib: fence off legacy interfaces

[Mark Brown]

On Fri, 08 Aug 2025 17:17:44 +0200, Arnd Bergmann wrote:
> Commit 678bae2eaa81 ("gpiolib: make legacy interfaces optional") was
> merged for linux-6.17, so now it is possible to use the legacy interfaces
> conditionally and eventually have the support left out of the kernel
> whenever it is not needed.
> 
> I created six patches to force-enable CONFIG_GPIOLIB_LEGACY on the
> few (mostly ancient) platforms that still require this, plus a set of
> patches to either add the corresponding Kconfig dependencies that make
> the device drivers conditional on that symbol, or change them to no
> longer require it.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[08/21] ASoC: add GPIOLIB_LEGACY dependency where needed
        commit: 5383d67e2430822fa7bd20dcbbebbd8ae808e386
[20/21] ASoC: pxa: add GPIOLIB_LEGACY dependency
        commit: 2d86d2585ab929a143d1e6f8963da1499e33bf13

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: (subset) [PATCH 00/21] gpiolib: fence off legacy interfaces

[Lee Jones]

On Fri, 08 Aug 2025 17:17:44 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Commit 678bae2eaa81 ("gpiolib: make legacy interfaces optional") was
> merged for linux-6.17, so now it is possible to use the legacy interfaces
> conditionally and eventually have the support left out of the kernel
> whenever it is not needed.
> 
> [...]

Applied, thanks!

[12/21] mfd: arizona: make legacy gpiolib interface optional
        commit: 12f6c0afc8987d72017a3ecf7c1183cb951b0d24
[13/21] mfd: si476x: add GPIOLIB_LEGACY dependency
        commit: 1ae250257e43b3fba225e4f8ea7d87125dc861ae
[14/21] mfd: aat2870: add GPIOLIB_LEGACY dependency
        commit: 3144986f37911f131f373743f294b2941a8ef37c

--
Lee Jones [李琼斯]