* [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
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.
Allow turning it on manually for compile testing, in order to keep
the build coverage of the legacy drivers in allmodconfig and
randconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v5: added patch, now that we are getting closer to completing
the series
---
drivers/gpio/Kconfig | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 28cf6d2e83c2..f063bdfd111b 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
+ 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.
config HAVE_SHARED_GPIOS
bool
--
2.39.5
^ permalink raw reply related
* [PATCH 5/6] [v5] leds: gpio: make legacy gpiolib interface optional
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds,
Bartosz Golaszewski, Andy Shevchenko
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
There are still a handful of ancient mips/armv5/sh boards that use the
gpio_led:gpio member to pass an old-style gpio number, but all modern
users have been converted to gpio descriptors.
While the CONFIG_GPIOLIB_LEGACY option that guards devm_gpio_request_one()
and related helpers is currently turned on in all kernel builds,
the plan is to only enable it on the few platforms that actually
pass gpio numbers in any platform_data.
Split out the legacy portion of the platform_data handling into a custom
helper function that is guarded with in #ifdef block, to allow the
the leds-gpio driver to compile cleanly when CONFIG_GPIOLIB_LEGACY
gets turned off. Once the last user is converted, this function can
be removed.
Link: https://lore.kernel.org/all/e9252384-a55c-4a91-9c61-06e05a0b2ce4@app.fastmail.com/
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v5: no changes
v4: whitespace changes only
v3: simplify gpio_led_get_gpiod
v2: rework a little bit to keep the legacy code path more separate,
extend changelog description
---
drivers/leds/leds-gpio.c | 53 ++++++++++++++++++++++++++--------------
include/linux/leds.h | 2 ++
2 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index a3428b22de3a..740772c2504a 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -9,8 +9,8 @@
#include <linux/container_of.h>
#include <linux/device.h>
#include <linux/err.h>
-#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
+#include <linux/gpio/legacy.h>
#include <linux/leds.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
@@ -212,7 +212,6 @@ static struct gpio_desc *gpio_led_get_gpiod(struct device *dev, int idx,
const struct gpio_led *template)
{
struct gpio_desc *gpiod;
- int ret;
/*
* This means the LED does not come from the device tree
@@ -221,18 +220,30 @@ static struct gpio_desc *gpio_led_get_gpiod(struct device *dev, int idx,
* the GPIO from there.
*/
gpiod = devm_gpiod_get_index_optional(dev, NULL, idx, GPIOD_OUT_LOW);
- if (IS_ERR(gpiod))
- return gpiod;
- if (gpiod) {
+ if (!IS_ERR(gpiod))
gpiod_set_consumer_name(gpiod, template->name);
- return gpiod;
- }
- /*
- * This is the legacy code path for platform code that
- * still uses GPIO numbers. Ultimately we would like to get
- * rid of this block completely.
- */
+ return gpiod;
+}
+
+#ifdef CONFIG_GPIOLIB_LEGACY
+/*
+ * This is the legacy code path for platform code that still uses
+ * GPIO numbers, mainly MIPS and SuperH board files.
+ * Ultimately we would like to get rid of this block completely.
+ *
+ * ppc44x-warp sets the template->gpiod directly instead of
+ * adding a lookup table or device properties. This is not
+ * much better.
+ */
+static struct gpio_desc *gpio_led_get_legacy_gpiod(struct device *dev, int idx,
+ const struct gpio_led *template)
+{
+ struct gpio_desc *gpiod;
+ int ret;
+
+ if (template->gpiod)
+ return template->gpiod;
/* skip leds that aren't available */
if (!gpio_is_valid(template->gpio))
@@ -252,6 +263,13 @@ static struct gpio_desc *gpio_led_get_gpiod(struct device *dev, int idx,
return gpiod;
}
+#else
+static struct gpio_desc *gpio_led_get_legacy_gpiod(struct device *dev, int idx,
+ const struct gpio_led *template)
+{
+ return template->gpiod ?: ERR_PTR(-ENOENT);
+}
+#endif
static int gpio_led_probe(struct platform_device *pdev)
{
@@ -270,14 +288,13 @@ static int gpio_led_probe(struct platform_device *pdev)
const struct gpio_led *template = &pdata->leds[i];
struct gpio_led_data *led_dat = &priv->leds[i];
- if (template->gpiod)
- led_dat->gpiod = template->gpiod;
- else
+ led_dat->gpiod = gpio_led_get_gpiod(dev, i, template);
+ if (!led_dat->gpiod)
led_dat->gpiod =
- gpio_led_get_gpiod(dev, i, template);
+ gpio_led_get_legacy_gpiod(dev, i, template);
if (IS_ERR(led_dat->gpiod)) {
- dev_info(dev, "Skipping unavailable LED gpio %d (%s)\n",
- template->gpio, template->name);
+ dev_info(dev, "Skipping unavailable LED gpio %s\n",
+ template->name);
continue;
}
diff --git a/include/linux/leds.h b/include/linux/leds.h
index b16b803cc1ac..e646bffcd8e7 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -676,8 +676,10 @@ typedef int (*gpio_blink_set_t)(struct gpio_desc *desc, int state,
struct gpio_led {
const char *name;
const char *default_trigger;
+#ifdef CONFIG_GPIOLIB_LEGACY
unsigned gpio;
unsigned active_low : 1;
+#endif
unsigned retain_state_suspended : 1;
unsigned panic_indicator : 1;
unsigned default_state : 2;
--
2.39.5
^ permalink raw reply related
* [PATCH 4/6] [v5] Input: gpio-keys: make legacy gpiolib optional
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
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.
The two Rohm PMIC drivers use a gpio-keys device without an actual GPIO,
passing an IRQ number instead. In order to keep this working both with
and with CONFIG_GPIOLIB_LEGACY, change the gpio-keys driver to ignore
the gpio number if an IRQ is passed.
Link: https://lore.kernel.org/all/b3c94552-c104-42e3-be15-7e8362e8039e@gmail.com/
Link: https://lore.kernel.org/all/afJXG4_rtaj3l2Dk@google.com/
Link: https://lore.kernel.org/all/ajQ-CtU131FAJ9ES@google.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v3..v5: resend
v2: skip the fake GPIO number passing from mfd
This patch now has a small conflict with the rework of the rohm drivers
to use software nodes. That patch is the one we want, and then
the drivers/mfd changes here can get dropped, but the two need to
get merged in the correct order.
---
drivers/input/keyboard/gpio_keys.c | 9 +++++----
drivers/input/keyboard/gpio_keys_polled.c | 4 +++-
drivers/mfd/rohm-bd71828.c | 1 -
drivers/mfd/rohm-bd718x7.c | 1 -
include/linux/gpio_keys.h | 2 ++
5 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index e19617485679..e988657f97cb 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -23,8 +23,8 @@
#include <linux/input.h>
#include <linux/gpio_keys.h>
#include <linux/workqueue.h>
-#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
+#include <linux/gpio/legacy.h>
#include <linux/of.h>
#include <linux/of_irq.h>
#include <linux/spinlock.h>
@@ -528,7 +528,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
*/
bdata->gpiod = NULL;
}
- } else if (gpio_is_valid(button->gpio)) {
+#ifdef CONFIG_GPIOLIB_LEGACY
+ } else if (!button->irq && gpio_is_valid(button->gpio)) {
/*
* Legacy GPIO number, so request the GPIO here and
* convert it to descriptor.
@@ -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..4e7a366ff05b 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -18,8 +18,8 @@
#include <linux/input.h>
#include <linux/ioport.h>
#include <linux/platform_device.h>
-#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
+#include <linux/gpio/legacy.h>
#include <linux/gpio_keys.h>
#include <linux/property.h>
@@ -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 a79f354bf5cb..df6dad762ec9 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -39,7 +39,6 @@
static struct gpio_keys_button button = {
.code = KEY_POWER,
- .gpio = -1,
.type = EV_KEY,
.wakeup = 1,
};
diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
index ff714fd4f54d..dd774aa8828b 100644
--- a/drivers/mfd/rohm-bd718x7.c
+++ b/drivers/mfd/rohm-bd718x7.c
@@ -20,7 +20,6 @@
static struct gpio_keys_button button = {
.code = KEY_POWER,
- .gpio = -1,
.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
^ permalink raw reply related
* [PATCH 3/6] [v5] Input: soc_button_array - select CONFIG_GPIOLIB_LEGACY
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
This driver converts information from ACPI in x86 based tablets and
laptops into platform_data for the gpio_keys driver, using the obsolete
gpio number based interfaces.
This should really be converted to some other method, but since the
conversion is nontrivial, have this one select GPIOLIB_LEGACY for the
time being.
This enables turning GPIOLIB_LEGACY off by default on most kernel
builds. Since the driver is only used on x86 portables, add a CONFIG_X86
dependency, which means non-x86 allmodconfig builds usuallly build
without the legacy gpio support.
Link: https://lore.kernel.org/all/ah-1z9LhVG0wtfBw@google.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v5: This was part of an earlier "x86/platform: select legacy
gpiolib interfaces where used" patch that covered several
drivers. This is the only one left as of linux-7.2-rc1
---
drivers/input/misc/Kconfig | 3 +++
drivers/input/misc/soc_button_array.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 1f6c57dba030..9c66e3a67127 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -892,6 +892,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/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index b8cad415c62c..eb11bf2e9436 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -15,7 +15,7 @@
#include <linux/dmi.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio_keys.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
static bool use_low_level_irq;
--
2.39.5
^ permalink raw reply related
* [PATCH 2/6] [v5] x86/olpc: select GPIOLIB_LEGACY
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds,
Takashi Iwai, Bartosz Golaszewski
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The OLPC GPIO controller sets up a fixed number space that is used
by at least two drivers:
arch/x86/platform/olpc/olpc-xo1-sci.c: In function 'setup_ec_sci':
arch/x86/platform/olpc/olpc-xo1-sci.c:358:13: error: implicit declaration of function 'gpio_request' [-Wimplicit-function-declaration]
358 | r = gpio_request(OLPC_GPIO_ECSCI, "OLPC-ECSCI");
| ^~~~~~~~~~~~
sound/pci/cs5535audio/cs5535audio_olpc.c: In function 'olpc_analog_input':
sound/pci/cs5535audio/cs5535audio_olpc.c:41:9: error: implicit declaration of function 'gpio_set_value'; did you mean 'gpiod_set_value'? [-Wimplicit-function-declaration]
41 | gpio_set_value(OLPC_GPIO_MIC_AC, on);
The AMD Geode platform that this is based on is now marked as
'Orphaned' in Kconfig, and it is likely that there are no XO1
users on modern kernels, but so far there is no consensus on
removing it entirely.
Select CONFIG_GPIOLIB_LEGACY for this platform and make sure the
sound driver portion cannot be compiled without this.
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v3..v5: no changes
v2: update changelog text
---
arch/x86/Kconfig | 1 +
arch/x86/platform/olpc/olpc-xo1-sci.c | 2 +-
sound/pci/Kconfig | 1 +
sound/pci/cs5535audio/cs5535audio_olpc.c | 2 +-
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bdad90f210e4..4ad8a7bbd93d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2976,6 +2976,7 @@ config OLPC
bool "One Laptop Per Child support"
depends on !X86_PAE
select GPIOLIB
+ select GPIOLIB_LEGACY
select OF
select OF_PROMTREE
select IRQ_DOMAIN
diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c b/arch/x86/platform/olpc/olpc-xo1-sci.c
index 30751b42d54e..a5b47960ba32 100644
--- a/arch/x86/platform/olpc/olpc-xo1-sci.c
+++ b/arch/x86/platform/olpc/olpc-xo1-sci.c
@@ -9,7 +9,7 @@
#include <linux/cs5535.h>
#include <linux/device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
#include <linux/input.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index e0996a9d90b0..6366f72b3667 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -300,6 +300,7 @@ config SND_CS5535AUDIO
tristate "CS5535/CS5536 Audio"
depends on X86_32 || MIPS || COMPILE_TEST
depends on HAS_IOPORT
+ depends on GPIOLIB_LEGACY || !OLPC
select SND_PCM
select SND_AC97_CODEC
help
diff --git a/sound/pci/cs5535audio/cs5535audio_olpc.c b/sound/pci/cs5535audio/cs5535audio_olpc.c
index 122170a410d9..cfdcc5bf4341 100644
--- a/sound/pci/cs5535audio/cs5535audio_olpc.c
+++ b/sound/pci/cs5535audio/cs5535audio_olpc.c
@@ -9,7 +9,7 @@
#include <sound/info.h>
#include <sound/control.h>
#include <sound/ac97_codec.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
#include <asm/olpc.h>
#include "cs5535audio.h"
--
2.39.5
^ permalink raw reply related
* [PATCH 1/6] [v5] sh: select legacy gpiolib interface
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds
In-Reply-To: <20260629130329.1291953-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Many board files on sh reference the legacy gpiolib interfaces that
are becoming optional. To ensure the boards can keep building, select
CONFIG_GPIOLIB_LEGACY on each of the boards that have one of the
hardcoded calls.
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2..v5: no changes. The patch did not make it into v7.2-rc1, so
I'm keeping it with the rest of the series
---
arch/sh/Kconfig | 1 +
arch/sh/boards/Kconfig | 8 ++++++++
arch/sh/boards/mach-highlander/Kconfig | 1 +
arch/sh/boards/mach-rsk/Kconfig | 3 +++
4 files changed, 13 insertions(+)
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index d5795067befa..d60f1d5a94c0 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -462,6 +462,7 @@ config CPU_SUBTYPE_SHX3
select CPU_SHX3
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GPIOLIB
+ select GPIOLIB_LEGACY
select PINCTRL
# SH4AL-DSP Processor Support
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index 1af93be61b1f..d89b74177233 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -80,6 +80,7 @@ config SH_7724_SOLUTION_ENGINE
select SOLUTION_ENGINE
depends on CPU_SUBTYPE_SH7724
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
imply SND_SOC_AK4642 if SND_SIMPLE_CARD
help
@@ -199,6 +200,7 @@ config SH_SH7757LCR
bool "SH7757LCR"
depends on CPU_SUBTYPE_SH7757
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
config SH_SH7785LCR
@@ -226,6 +228,7 @@ config SH_URQUELL
bool "Urquell"
depends on CPU_SUBTYPE_SH7786
select GPIOLIB
+ select GPIOLIB_LEGACY
select HAVE_PCI
select NO_IOPORT_MAP if !PCI
@@ -233,6 +236,7 @@ config SH_MIGOR
bool "Migo-R"
depends on CPU_SUBTYPE_SH7722
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
help
Select Migo-R if configuring for the SH7722 Migo-R platform
@@ -242,6 +246,7 @@ config SH_AP325RXA
bool "AP-325RXA"
depends on CPU_SUBTYPE_SH7723
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
help
Renesas "AP-325RXA" support.
@@ -251,6 +256,7 @@ config SH_KFR2R09
bool "KFR2R09"
depends on CPU_SUBTYPE_SH7724
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
help
"Kit For R2R for 2009" support.
@@ -259,6 +265,7 @@ config SH_ECOVEC
bool "EcoVec"
depends on CPU_SUBTYPE_SH7724
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
imply SND_SOC_DA7210 if SND_SIMPLE_CARD
help
@@ -329,6 +336,7 @@ config SH_MAGIC_PANEL_R2
bool "Magic Panel R2"
depends on CPU_SUBTYPE_SH7720
select GPIOLIB
+ select GPIOLIB_LEGACY
select REGULATOR_FIXED_VOLTAGE if REGULATOR
help
Select Magic Panel R2 if configuring for Magic Panel R2.
diff --git a/arch/sh/boards/mach-highlander/Kconfig b/arch/sh/boards/mach-highlander/Kconfig
index b0abd03cac4e..cd3a553ce30c 100644
--- a/arch/sh/boards/mach-highlander/Kconfig
+++ b/arch/sh/boards/mach-highlander/Kconfig
@@ -20,6 +20,7 @@ config SH_R7785RP
bool "R7785RP board support"
depends on CPU_SUBTYPE_SH7785
select GPIOLIB
+ select GPIOLIB_LEGACY
endchoice
diff --git a/arch/sh/boards/mach-rsk/Kconfig b/arch/sh/boards/mach-rsk/Kconfig
index f0299bc4416f..3810937aa5d4 100644
--- a/arch/sh/boards/mach-rsk/Kconfig
+++ b/arch/sh/boards/mach-rsk/Kconfig
@@ -12,16 +12,19 @@ config SH_RSK7201
config SH_RSK7203
bool "RSK7203"
select GPIOLIB
+ select GPIOLIB_LEGACY
depends on CPU_SUBTYPE_SH7203
config SH_RSK7264
bool "RSK2+SH7264"
select GPIOLIB
+ select GPIOLIB_LEGACY
depends on CPU_SUBTYPE_SH7264
config SH_RSK7269
bool "RSK2+SH7269"
select GPIOLIB
+ select GPIOLIB_LEGACY
depends on CPU_SUBTYPE_SH7269
endchoice
--
2.39.5
^ permalink raw reply related
* [PATCH v5 0/6] gpiolib: fence off legacy interfaces
From: Arnd Bergmann @ 2026-06-29 13:03 UTC (permalink / raw)
To: linux-gpio
Cc: Arnd Bergmann, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, linux-sh, linux-kernel, linux-input, linux-leds
From: Arnd Bergmann <arnd@arndb.de>
This is the remainder of the series previously posted as v2
in [1]. I've changed the version to v5 for all patches to
not confuse b4 too much, but the patches are mostly unchanged.
The patch "Input: soc_button_array - select CONFIG_GPIOLIB_LEGACY"
was not part of the series last time, but the build bots reported
this as a regression since I had dropped that since v1.
I hope that all that remains now can just get merged through the
gpio tree. The gpio-keys patch needs a bit coordination with
another patch addressing the same issue that is already in
flight, so I expect that I'll rebase my series once more when
that is in a stable branch, but the state I have here should
just work as-is on top of v7.2-rc1.
Arnd
[1] https://lore.kernel.org/all/20260520183815.2510387-1-arnd@kernel.org/
Arnd Bergmann (6):
[v5] sh: select legacy gpiolib interface
[v5] x86/olpc: select GPIOLIB_LEGACY
[v5] Input: soc_button_array - select CONFIG_GPIOLIB_LEGACY
[v5] Input: gpio-keys: make legacy gpiolib optional
[v5] leds: gpio: make legacy gpiolib interface optional
[v5] gpiolib: turn off legacy interface by default
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 +
arch/x86/platform/olpc/olpc-xo1-sci.c | 2 +-
drivers/gpio/Kconfig | 9 +++-
drivers/input/keyboard/gpio_keys.c | 9 ++--
drivers/input/keyboard/gpio_keys_polled.c | 4 +-
drivers/input/misc/Kconfig | 3 ++
drivers/input/misc/soc_button_array.c | 2 +-
drivers/leds/leds-gpio.c | 53 +++++++++++++++--------
drivers/mfd/rohm-bd71828.c | 1 -
drivers/mfd/rohm-bd718x7.c | 1 -
include/linux/gpio_keys.h | 2 +
include/linux/leds.h | 2 +
sound/pci/Kconfig | 1 +
sound/pci/cs5535audio/cs5535audio_olpc.c | 2 +-
18 files changed, 76 insertions(+), 29 deletions(-)
--
2.39.5
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Walleij <linusw@kernel.org>
Cc: Bartosz Golaszewski <brgl@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Lee Jones <lee@kernel.org>
Cc: Pavel Machek <pavel@kernel.org>
Cc: linux-sh@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-leds@vger.kernel.org
^ permalink raw reply
* Re: [PATCH v4 00/10] HID: steelseries: Refactor Arctis driver and add Arctis Nova 7 Gen2 support
From: Jiri Kosina @ 2026-06-29 9:47 UTC (permalink / raw)
To: Sriman Achanta
Cc: Benjamin Tissoires, linux-input, linux-kernel, Simon Wood,
Christian Mayer, Bastien Nocera
In-Reply-To: <20260623172310.272708-1-srimanachanta@gmail.com>
Sriman,
thanks a lot for the effort. The patchset looks good to me, but Sashiko
found a couple issues.
I specifically believe the ones for 4/10 are valid. Have you looked into
those?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-custom: Fix sysfs group leak on failure
From: Jiri Kosina @ 2026-06-29 9:28 UTC (permalink / raw)
To: Haoxiang Li
Cc: jic23, srinivas.pandruvada, bentiss, linux-input, linux-iio,
linux-kernel, stable
In-Reply-To: <20260623021950.1736413-1-haoxiang_li2024@163.com>
On Tue, 23 Jun 2026, Haoxiang Li wrote:
> hid_sensor_custom_add_attributes() creates one sysfs group for each
> custom sensor field. If sysfs_create_group() fails after some groups
> have already been created, the function currently breaks out of the
> loop and returns the error directly.
>
> Fix this by adding a local unwind path when sysfs_create_group() fails.
> The unwind path removes all sysfs groups that were successfully created
> before the failure and frees sensor_inst->fields.
>
> Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> drivers/hid/hid-sensor-custom.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> index afffea894021..cd676516e6b0 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -609,7 +609,7 @@ static int hid_sensor_custom_add_attributes(struct hid_sensor_custom
> &sensor_inst->fields[i].
> hid_custom_attribute_group);
> if (ret)
> - break;
> + goto err_remove_groups;
>
> /* For power or report field store indexes */
> if (sensor_inst->fields[i].attribute.attrib_id ==
> @@ -621,6 +621,13 @@ static int hid_sensor_custom_add_attributes(struct hid_sensor_custom
> }
>
> return ret;
> +
> +err_remove_groups:
> + while (--i >= 0)
> + sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> + &sensor_inst->fields[i].hid_custom_attribute_group);
> + kfree(sensor_inst->fields);
I believe Sashiko is right here abou the UAF. Could you please fix that
and resubmit?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v5 0/5] HID: asus: security fixes and more hardware support
From: Jiri Kosina @ 2026-06-29 9:21 UTC (permalink / raw)
To: Denis Benato
Cc: linux-kernel, linux-input, Benjamin Tissoires, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Antheas Kapenekakis, Connor Belli
In-Reply-To: <20260619001103.1189200-1-denis.benato@linux.dev>
On Fri, 19 Jun 2026, Denis Benato wrote:
> Hi all,
>
> I have added support for controlling the (way too bright) XG mobile
> LEDs in hid-asus and added the i2c version of already supported
> hardware that was probed only when it's a USB: these are two separate
> features changes and are the only two that are not fixes for
> pre-existing issue (see below).
>
> Auto-review bot has spotted a bunch of pre-existing problems alongside
> problems in my own code therefore at this point I am going to fix the
> more problems I can and including those fixes and improvements in this
> patchset.
>
> For v4 I decided to follow Antheas' suggestion of reusing the existing
> workqueue and by making it more generic I solved a good bunch of issues.
>
> The v5 iteration is simply me fixing a bunch of bugs in new code spotted
> by the bot. Thanks for providing such a useful tool!
>
> On a side node this patchset has a few more warnings: specifically
> "WARNING: Prefer kzalloc_obj over kzalloc with sizeof" but it's a false
> positive as that would introduce sleeping calls in atomic contexts.
Denis,
thanks. Could you please flag which patches you'd prefer to go in still
for 7.1 and which ones are not critical and could wait for 7.2? The whole
lot is quite big.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: lg-g15: cancel pending work on remove to fix a use-after-free
From: Jiri Kosina @ 2026-06-29 9:18 UTC (permalink / raw)
To: Maoyi Xie; +Cc: Hans de Goede, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <178176639579.3377656.12792307991044339915@maoyixie.com>
On Thu, 18 Jun 2026, Maoyi Xie wrote:
> lg_g15_data is allocated with devm and holds a work item. The report
> handlers schedule that work straight from device input.
> lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key,
> and lg_g510_leds_event() does it too. The worker dereferences the
> lg_g15_data back through container_of.
>
> The driver had no remove callback and never cancelled the work. So if a
> report scheduled the work and the keyboard was then unplugged, devres
> freed lg_g15_data while the work was still pending or running, and the
> worker touched freed memory. This is a use-after-free. It is reachable
> as a race on device unplug.
>
> Add a remove callback that cancels the work before devres frees the
> state. g15->work is only initialized for the models that schedule it
> (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the
> cancel on g15->work.func to avoid cancelling a work that was never set
> up. The g15 NULL test mirrors the one already in lg_g15_raw_event().
>
> Fixes: 97b741aba918 ("HID: lg-g15: Add keyboard and LCD backlight control")
> Cc: stable@vger.kernel.org
> Suggested-by: Hans de Goede <hansg@kernel.org>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Thanks, applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix maxfield check in DJ short report validation
From: Jiri Kosina @ 2026-06-29 9:18 UTC (permalink / raw)
To: HyeongJun An
Cc: Benjamin Tissoires, Filipe Laíns, Lee Jones, linux-input,
linux-kernel, stable
In-Reply-To: <20260618063737.211468-1-sammiee5311@gmail.com>
On Thu, 18 Jun 2026, HyeongJun An wrote:
> Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT
> related user initiated OOB write") added validation for the DJ short
> output report, but the error path dereferences rep->field[0] even when
> rep->maxfield is zero.
>
> Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad
> DJ_SHORT output report") made the check conditional on rep being present,
> but a crafted descriptor can still create report ID 0x20 with only padding
> output items. hid-core registers the report, ignores the padding field,
> and leaves rep->maxfield as zero.
>
> In that case the validation enters the rep->maxfield < 1 branch and then
> dereferences rep->field[0]->report_count while printing the error message,
> causing a NULL pointer dereference during probe. This is reproducible with
> uhid by emulating a Logitech receiver with a padding-only DJ short output
> report:
>
> BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
> Read of size 4 at addr 0000000000000028 by task kworker/4:1/129
> ...
> Call Trace:
> logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
> hid_device_probe+0x329/0x3f0 [hid]
> really_probe+0x162/0x570
> __device_attach+0x137/0x2c0
> bus_probe_device+0x38/0xc0
> device_add+0xa56/0xce0
> hid_add_device+0x19c/0x280 [hid]
> uhid_device_add_worker+0x2c/0xb0 [uhid]
>
> Reject the zero-field report before printing the field report_count.
>
> Fixes: b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] HID: roccat: bound device-supplied profile index
From: Jiri Kosina @ 2026-06-29 9:16 UTC (permalink / raw)
To: Michael Bommarito
Cc: Stefan Achatz, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260618030036.1880139-1-michael.bommarito@gmail.com>
On Wed, 17 Jun 2026, Michael Bommarito wrote:
> The Roccat Kone driver uses an 8-bit value taken straight from a USB HID
> interrupt report as an index into a fixed 5-element profiles[] array,
> without any range check. A malicious or counterfeit device that claims
> the Roccat Kone VID/PID can send a "switch profile" report with an
> out-of-range value and make the driver read out of bounds; the same
> unbounded index is also reachable at probe time from a device-supplied
> startup_profile field. The read result is stored in actual_dpi and
> exposed to user space through the actual_dpi sysfs attribute.
>
> Michael Bommarito (2):
> HID: roccat: bound device-supplied profile index
> HID: roccat: add KUnit test for kone profile-index bounds
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 0/4] HID: sony: more cleanup
From: Jiri Kosina @ 2026-06-29 9:11 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <5o965110-3959-0061-1s41-q7224452q746@xreary.bet>
On Tue, 16 Jun 2026, Jiri Kosina wrote:
> now that this is sent as a series, I can easily apply it on top
> altogether when the merge window is over.
Applied to hid.git#for-7.2/sony, thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/1] HID: core: Fix OOB read in hid_get_report for numbered reports
From: Jiri Kosina @ 2026-06-29 9:10 UTC (permalink / raw)
To: Lee Jones
Cc: Benjamin Tissoires, Johan Hovold, Greg Kroah-Hartman, linux-input,
linux-kernel
In-Reply-To: <20260616112700.1990813-1-lee@kernel.org>
On Tue, 16 Jun 2026, Lee Jones wrote:
> When a caller passes a size of 0 to hid_report_raw_event() for a
> numbered report, the function originally called hid_get_report() before
> performing any size validation.
>
> Inside hid_get_report(), if the report is numbered (report_enum->numbered
> is true), it unconditionally dereferences data[0] to extract the report ID.
> With a size of 0, this results in an out-of-bounds read or kernel panic.
>
> Fix this by moving the numbered report size validation check before the
> call to hid_get_report(), ensuring that size is at least 1 before
> dereferencing the data pointer.
>
> Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
> Signed-off-by: Lee Jones <lee@kernel.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 1/3] HID: wacom: Fix Use-After-Free in wacom_intuos_pad
From: Jiri Kosina @ 2026-06-29 9:05 UTC (permalink / raw)
To: Lee Jones
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, Peter Hutterer,
Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <20260616092658.1714548-1-lee@kernel.org>
Lee,
thanks, it looks good to me now.
I'd still like to get an Ack from either Jason or Ping on this before
applying, especially due to nature of patch #3.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6] HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver
From: Jiri Kosina @ 2026-06-29 9:04 UTC (permalink / raw)
To: 谢致邦 (XIE Zhibang)
Cc: linux-input, hansg, dmitry.torokhov, bentiss, dianders,
linux-kernel, sashiko-bot, sashiko-reviews, superm1
In-Reply-To: <tencent_FD772005ED5B8FB435F3DFDF73437BC58F06@qq.com>
On Wed, 24 Jun 2026, 谢致邦 (XIE Zhibang) wrote:
> Move the _DSM call that gets the HID descriptor address from
> i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI
> and the new PRP0001 driver can use it. While refactoring, move the
> blacklist check and the _DSM call to the top of probe() to avoid a
> pointless alloc when the device is blacklisted or does not implement the
> _DSM.
>
> Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3,
> are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but
> lack "hid-descr-addr" from the _DSD and provide the HID descriptor
> address only through an ACPI _DSM. The OF driver fails to probe them
> because it requires hid-descr-addr. Add a new driver that handles these
> devices by calling the shared _DSM helper.
>
> Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> ---
> v2: Name the unused parameter and document why
> acpi_device_fix_up_power() is skipped.
> v3: Add a dev_warn() asking users to contact vendors for firmware
> updates, and use existing locals in devm_kzalloc() and
> acpi_device_fix_up_power().
> v4: Double the power-up delay from 250ms to 500ms.
> v5: Document why of_match_ptr() on the of_match_table is safe when
> CONFIG_OF=n.
> v6: Increase power-up delay from 500ms to 750ms. During cold boot on low
> battery, 500ms causes non-fatal I2C transfer errors (-ENXIO). 750ms
> fixes them.
Thanks for all the effort you've put into this.
[ ... snip ... ]
> --- a/drivers/hid/i2c-hid/Kconfig
> +++ b/drivers/hid/i2c-hid/Kconfig
> @@ -22,6 +22,24 @@ config I2C_HID_ACPI
> will be called i2c-hid-acpi. It will also build/depend on the
> module i2c-hid.
>
> +config I2C_HID_ACPI_PRP0001
> + tristate "Driver for PRP0001 devices missing hid-descr-addr"
> + depends on ACPI
> + depends on DRM || !DRM
> + select I2C_HID_CORE
> + help
> + Say Y here if you want support for I2C HID touchpads that
> + are declared with _HID "PRP0001" and _DSD compatible
> + "hid-over-i2c" but lack the "hid-descr-addr" property from
> + the _DSD. The HID descriptor address is instead provided
> + through an ACPI _DSM. Known affected devices include the
> + Lenovo KaiTian N60d and Inspur CP300L3.
> +
> + If unsure, say N.
> +
> + This support is also available as a module. If so, the
> + module will be called i2c-hid-acpi-prp0001.
The only question I have -- do we really want to have this build-time
selectable by the endusers? It's unlikely that the description will make
sense to most of the people, being very low-level technical, and they'd be
unsure what to chose.
Is there a reason not to include it alwyas under the I2C_HID_CORE
umbrella?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: nintendo: Fix imu_timestamp_us double increment per report
From: Jiri Kosina @ 2026-06-29 8:57 UTC (permalink / raw)
To: Christos Maragkos; +Cc: linux-input, djogorchock, bentiss
In-Reply-To: <20260603152134.94439-1-whitetowersoftware@gmail.com>
On Wed, 3 Jun 2026, Christos Maragkos wrote:
> Previously, the imu_timestamp_us variable was incremented twice per
> report, causing it to advance by two times the desired amount.
>
> This resulted in incorrect jumps in IMU timestamps reported using
> MSC_TIMESTAMP, so userspace applications saw corrupted timing on
> functions such as gyroscope-based aim and motion controls.
>
> This is fixed by removing the redundant increment at the start of the
> report handling so the remaining can account for the full report
> interval.
>
> Fixes: 4ff5b10840a88 ("HID: nintendo: add IMU support")
> Signed-off-by: Christos Maragkos <whitetowersoftware@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: wacom: avoid copying Bluetooth input reports
From: Jiri Kosina @ 2026-06-29 8:54 UTC (permalink / raw)
To: Ruoyu Wang
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260617072035.3373487-1-ruoyuw560@gmail.com>
On Wed, 17 Jun 2026, Ruoyu Wang wrote:
> wacom_intuos_bt_irq() duplicates the received Bluetooth report with
> kmemdup() so that it can pass 10-byte input report payloads to the
> common Intuos parser. The helper then copies each payload back into
> wacom->data before calling wacom_intuos_irq().
>
> Avoid the allocation and copy by temporarily pointing wacom->data at the
> current 10-byte payload while the common parser runs, then restoring the
> original report pointer. The Bluetooth report parser keeps using the
> original report buffer for dispatch and battery parsing, while the common
> parser sees the same payload bytes as before.
>
> This also removes the unchecked kmemdup() result from the Bluetooth IRQ
> path.
>
> Suggested-by: Jason Gerecke <jason.gerecke@wacom.com>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v10] HID: steelseries: Add MSI Raider A18 HX A9WJG RGB support
From: Jiri Kosina @ 2026-06-29 8:52 UTC (permalink / raw)
To: David Glushkov
Cc: Benjamin Tissoires, linux-input, linux-kernel, kernel test robot
In-Reply-To: <20260605175035.12257-1-david.glushkov@sntiq.com>
On Fri, 5 Jun 2026, David Glushkov wrote:
> The MSI Raider A18 HX A9WJG exposes two internal SteelSeries USB HID
> devices for RGB lighting: KLC (1038:1122) for the keyboard and ALC
> (1038:1161) for the lightbar/logo zones.
>
> Add DMI-gated support for these devices and expose them as multicolor
> LED class devices. The driver sends the same HID class SET_REPORT
> control transfer as the tested userspace implementation for this
> machine and writes a uniform RGB value to all known keyboard keys or
> ALC zones.
>
> The ALC payload uses sparse LED IDs on this chassis: 0x00, 0x01,
> 0x02 and 0x03 are physical zones, while 0x04 and 0x05 do not appear
> to map to physical LEDs. Unused payload LED ID slots are initialized
> to 0xff so they are ignored by the controller instead of defaulting
> to LED ID 0x00.
>
> Limit RGB support to USB interface 0 and the tested DMI system because
> the KLC product ID is shared across MSI laptop designs and the key
> layout mapping is model-specific. If the DMI or interface check does
> not match, keep the device bound as a regular HID device instead of
> failing probe.
>
> Also make the existing Arctis 9 vendor usage-page check defensive by
> returning false for report descriptors shorter than three bytes before
> inspecting hdev->rdesc[0..2].
>
> Tested on MSI Raider A18 HX A9WJG. Both internal SteelSeries ALC
> (1038:1161) and KLC (1038:1122) HID devices bind on interface 0 and
> create steelseries::lightbar and steelseries::kbd_backlight. Setting
> multi_intensity and brightness changes the keyboard and lightbar
> colors.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606010709.X0QYNjFZ-lkp@intel.com/
> Signed-off-by: David Glushkov <david.glushkov@sntiq.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v11 0/4] Add MSI Claw HID Configuration Driver
From: Jiri Kosina @ 2026-06-29 8:51 UTC (permalink / raw)
To: Derek J. Clark
Cc: Benjamin Tissoires, Pierre-Loup A . Griffais, Denis Benato,
Zhouwang Huang, linux-input, linux-doc, linux-kernel
In-Reply-To: <20260529072111.7565-1-derekjohn.clark@gmail.com>
On Fri, 29 May 2026, Derek J. Clark wrote:
> This series adds an HID Configuration driver for the MSI Claw line of
> Handheld Gaming PC's. The MSI Claw HID interface provides multiple
> features, such as the ability to switch between xinput, dinput, and a
> desktop mode, RGB control, rumble intensity, and mapping of the rear "M"
> keys. There are additional gamepad modes that are not included in this
> driver as they appear to be used in assembly line testing or are
> incomplete in the firmware. During my testing I found them to be unstable.
>
> The initial version of this driver was written by Denis Benato, which
> contained the initial reverse-engineering and implementation for the
> gamepad mode switching. This work was later expanded by Zhouwang Huang
> to include more gamepad modes and additional features. Finally, I
> refactored the entire driver, fixed multiple bugs, and refined the overall
> format to conform to kernel driver best practices and style guide.
>
> Claude was used initially by Zhouwang Huang to quickly parse HID captures
> during the reverse-engineering of some of the features. Since Claude had
> already been used, as a test of its capabilities I had it implement the
> rumble intensity attribute after I had already rewritten most of the
> driver, which I then manually edited to fix some mistakes. I also used
> Claude to review the driver and these patches for any mistakes and bugs.
>
> Assisted-by: Claude:claude-sonnet-4-6
> Co-developed-by: Denis Benato <denis.benato@linux.dev>
> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> Co-developed-by: Zhouwang Huang <honjow311@gmail.com>
> Signed-off-by: Zhouwang Huang <honjow311@gmail.com>
> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
> ---
> v11:
> - Restore dropped changes from v10.
Thanks Derek.
Sashiko had quite a few insightful comments, I find especially the one
with IRQ-vs-kernel context deadlock on drvdata->profile_lock valid.
Could you please go through those, and address it?
Thanks again for all the effort,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH] HID: core: quiesce input in hid_hw_stop() to prevent use-after-free
From: Jiri Kosina @ 2026-06-29 8:48 UTC (permalink / raw)
To: Philipp Weber
Cc: bentiss, eadavis, linux-input, linux-kernel, syzkaller-bugs,
syzbot+9eebf5f6544c5e873858
In-Reply-To: <20260519130014.34521-1-kernel@phwe.de>
On Tue, 19 May 2026, Philipp Weber wrote:
> A driver's probe calls hid_device_io_start() to enable input delivery,
> then fails at a later initialization step and unwinds via hid_hw_stop().
> The unwind frees struct hidraw via hidraw_disconnect() while in-flight
> HID reports may still be running on another CPU, dereferencing the
> freed object through hidraw_report_event(). syzbot reports the
> resulting use-after-free for the corsair-psu HID driver.
>
> Edward Adam Davis posted a per-driver fix for corsair-psu that adds
> an explicit hid_device_io_stop() before hid_hw_stop() in the probe
> error path ("hwmon: prevent packets from going to driver for probe",
> 2026-04-28). Auditing the tree shows 15 drivers call
> hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:
>
> drivers calling hid_device_io_start() without a matching
> hid_device_io_stop() before hid_hw_stop():
> drivers/hwmon/corsair-psu.c (fix posted by Edward)
> drivers/hwmon/corsair-cpro.c
> drivers/hwmon/nzxt-kraken3.c
> drivers/hwmon/nzxt-smart2.c
> drivers/hwmon/gigabyte_waterforce.c
> drivers/hid/hid-logitech-dj.c
> drivers/hid/hid-nintendo.c
> drivers/hid/hid-mcp2221.c
>
> Roughly half of all callers of the API are exposed. Centralize the
> quiesce in hid_hw_stop() so callers do not have to remember the
> matching stop: if a driver has left hdev->io_started true on entry,
> call hid_device_io_stop() before hid_disconnect().
>
> For the 7 drivers that already call hid_device_io_stop() correctly,
> hdev->io_started is false on entry, the guard short-circuits, and
> behavior is unchanged.
>
> No Fixes: tag because the affected drivers gained their
> hid_device_io_start() calls independently over years; the bug is a
> class-wide API misuse rather than a regression from one commit.
>
> Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858
> Signed-off-by: Philipp Weber <kernel@phwe.de>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait()
From: Jiri Kosina @ 2026-06-29 8:46 UTC (permalink / raw)
To: Georgiy Osokin
Cc: bonbons, bentiss, linux-input, linux-kernel, lvc-project,
s.shtylyov
In-Reply-To: <20260517120639.38003-1-g.osokin@auroraos.dev>
On Sun, 17 May 2026, Georgiy Osokin wrote:
> In picolcd_send_and_wait(), an integer overflow of the signed loop counter
> 'k' can theoretically lead to a NULL pointer dereference of 'raw_data'.
> If the loop executes more than INT_MAX times, 'k' becomes negative,
> making the condition 'k < size' true even when 'size' is 0.
>
> Change the type of 'k' to 'unsigned int' to prevent the overflow and
> eliminate the out-of-bounds access.
>
> Found by Linux Verification Center (linuxtesting.org) with the Svace static
> analysis tool.
>
> Fixes: fabdbf2 ("HID: picoLCD: split driver code")
Next time, please make the shas of commits a little bit longer to avoid
uncertainity.
> Signed-off-by: Georgiy Osokin <g.osokin@auroraos.dev>
Applied, thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: appleir: fix UAF on pending key_up_timer in remove()
From: Jiri Kosina @ 2026-06-29 8:44 UTC (permalink / raw)
To: Manish Khadka; +Cc: linux-input, Benjamin Tissoires, linux-kernel
In-Reply-To: <20260515173252.77757-1-maskmemanish@gmail.com>
On Fri, 15 May 2026, Manish Khadka wrote:
> appleir_remove() runs hid_hw_stop() before timer_delete_sync().
> hid_hw_stop() synchronously unregisters the HID input device via
> hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(),
> which drops the last reference and frees the underlying input_dev when
> no userspace handle holds it open.
>
> key_up_tick() reads appleir->input_dev and calls input_report_key() /
> input_sync() on it. The timer is armed from appleir_raw_event() with
> a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a
> key was pressed shortly before the device is disconnected, the timer
> can fire after hid_hw_stop() has freed input_dev but before the
> teardown drains it.
>
> A simple reorder is not sufficient. Putting the timer drain first
> still leaves a window where a USB URB completion (raw_event) running
> during hid_hw_stop() can call mod_timer() and re-arm the timer, which
> then fires after hidinput_disconnect() has freed input_dev. The same
> URB-completion window also lets raw_event() reach key_up(), key_down()
> and battery_flat() directly, all of which dereference
> appleir->input_dev.
>
> Introduce a 'removing' flag on struct appleir, gated by the existing
> spinlock. appleir_remove() sets the flag under the lock and then
> shuts down the timer with timer_shutdown_sync(), which both drains any
> in-flight callback and permanently disables further mod_timer() calls.
> appleir_raw_event() and key_up_tick() bail out early if the flag is
> set, so no path can arm or run the timer, or dereference
> appleir->input_dev, after remove() has started tearing down.
>
> The keyrepeat and flatbattery branches of appleir_raw_event()
> previously called into the input layer without holding the spinlock;
> take it now so the flag check is well-defined. This incidentally
> closes a pre-existing read-side race on appleir->current_key in the
> keyrepeat branch.
>
> This bug is structurally a sibling of commit 4db2af929279 ("HID:
> appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been
> present since the driver was introduced.
>
> Fixes: 9a4a5574ce42 ("HID: appleir: add support for Apple ir devices")
> Cc: stable@vger.kernel.org
> Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: letsketch: fix UAF on inrange_timer at driver unbind
From: Jiri Kosina @ 2026-06-29 8:43 UTC (permalink / raw)
To: Manish Khadka
Cc: linux-input, Hans de Goede, Benjamin Tissoires, linux-kernel
In-Reply-To: <20260515164200.77039-1-maskmemanish@gmail.com>
On Fri, 15 May 2026, Manish Khadka wrote:
> letsketch_driver does not provide a .remove callback, but
> letsketch_probe() arms a per-device timer:
>
> timer_setup(&data->inrange_timer, letsketch_inrange_timeout, 0);
>
> The timer is re-armed from letsketch_raw_event() with a 100 ms
> timeout on every pen-in-range report, and its callback dereferences
> data->input_tablet to deliver a synthetic BTN_TOOL_PEN release.
>
> letsketch_data is allocated with devm_kzalloc(), and its input_dev
> fields are devm-allocated via letsketch_setup_input_tablet(). On
> device unbind (USB unplug or rmmod), the HID core runs its default
> teardown and devm cleanup frees both letsketch_data and the input
> devices. Because no .remove callback exists, nothing drains the
> timer first: if raw_event armed it within ~100 ms of the unbind,
> the pending timer fires on freed memory. This is a UAF read of
> data and of data->input_tablet, followed by input_report_key() /
> input_sync() into the freed input_dev.
>
> The same problem can occur on the probe error path: if
> hid_hw_start() enabled I/O on an always-poll-quirk device and then
> failed, raw_event may have armed the timer before devm releases
> data.
>
> Fix by adding a .remove callback that calls hid_hw_stop() first.
> hid_hw_stop() synchronously kills the URBs that deliver raw_event(),
> so once it returns no path can re-arm the timer. timer_shutdown_sync()
> then drains any in-flight callback and permanently disables further
> mod_timer() calls. Apply the same timer_shutdown_sync() in the probe
> error path so the timer is guaranteed not to outlive data.
>
> Fixes: 33a5c2793451 ("HID: Add new Letsketch tablet driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox