* Re: [PATCH 07/10] Input: synaptics-rmi4 - check V4L2 buffer size in F54 queue
From: Hans Verkuil @ 2026-06-29 13:42 UTC (permalink / raw)
To: Dmitry Torokhov, Bryam Vargas, Hans Verkuil
Cc: linux-input, linux-kernel, stable
In-Reply-To: <20260626051802.4033172-7-dmitry.torokhov@gmail.com>
On 26/06/2026 07:17, Dmitry Torokhov wrote:
> Add a safety check in rmi_f54_buffer_queue() to ensure that the
> requested report size (f54->report_size) does not exceed the actual
> allocated size of the V4L2 buffer (vb2_plane_size()).
>
> This provides a defense-in-depth measure against any potential size
> mismatches between the V4L2 queue and the driver's internal state.
>
> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
> Cc: stable@vger.kernel.org
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/rmi4/rmi_f54.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index c86bc81845bb..93526feea563 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -354,6 +354,13 @@ static void rmi_f54_buffer_queue(struct vb2_buffer *vb)
> goto data_done;
> }
>
> + if (f54->report_size > vb2_plane_size(vb, 0)) {
> + dev_err(&f54->fn->dev, "Buffer too small (%lu < %d)\n",
> + vb2_plane_size(vb, 0), f54->report_size);
> + state = VB2_BUF_STATE_ERROR;
> + goto data_done;
> + }
> +
That's the wrong place, it's too late for that check.
This should be checked in the buf_prepare callback. See e.g.
drivers/media/test-drivers/vivid/vivid-touch-cap.c.
Regards,
Hans
> memcpy(ptr, f54->report_data, f54->report_size);
> vb2_set_plane_payload(vb, 0, rmi_f54_get_report_size(f54));
> state = VB2_BUF_STATE_DONE;
^ permalink raw reply
* Re: [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
From: sashiko-bot @ 2026-06-29 13:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-input, linux-leds, dmitry.torokhov, lee
In-Reply-To: <20260629130329.1291953-7-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Drivers depending on `GPIOLIB_LEGACY` rather than selecting it are rendered unselectable and silently disabled on normal builds.
- [Low] Disabling CONFIG_GPIOLIB_LEGACY by default causes widespread build failures for platforms and drivers still relying on legacy GPIO functions.
--
commit bad1a2df68babe59200c7570528e8b8606464b68
Author: Arnd Bergmann <arnd@arndb.de>
gpiolib: turn off legacy interface by default
This commit changes the GPIOLIB_LEGACY configuration to default to 'n' instead
of 'y'. It restricts manual selection to builds where COMPILE_TEST is enabled,
intending to only build the legacy interface on platforms that require it.
> All users of the legacy interface now select CONFIG_GPIOLIB_LEGACY,
> so it can be turned off by default and only get built on platforms
> that still have one unconverted driver.
[Severity: High]
Is this description entirely accurate?
There appear to be drivers that use 'depends on GPIOLIB_LEGACY' rather than
selecting it, such as MFD_AAT2870_CORE, MFD_SI476X_CORE, and
SND_SOC_TLV320DAC33.
If GPIOLIB_LEGACY defaults to 'n' without COMPILE_TEST enabled, will these
drivers be rendered unselectable and silently disabled on normal builds?
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 020e51e30317a..543de15a12f63 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -4,7 +4,14 @@
> #
>
> config GPIOLIB_LEGACY
> - def_bool y
> + bool "Legacy GPIO interfaces" if COMPILE_TEST
[Severity: Low]
Could disabling this by default cause build failures on legacy platforms that
still call GPIO functions but do not explicitly select GPIOLIB_LEGACY?
For instance, arch/arm/mach-pxa/am200epd.c still uses gpio_request():
arch/arm/mach-pxa/am200epd.c:am200_init_gpio_regs() {
...
err = gpio_request(gpios[i], gpio_names[i]);
...
}
Because include/linux/gpio.h excludes the legacy prototypes when
CONFIG_GPIOLIB_LEGACY is disabled, will this cause implicit declaration
compiler errors during standard builds for architectures like PXA?
> + help
> + There are a few legacy platforms that use the traditional GPIO
> + number based interfaces instead of GPIO descriptors.
> + Say Y here to enable build testing drivers that are specific
> + to those platforms.
> +
> + If unsure, say N.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629130329.1291953-1-arnd@kernel.org?part=6
^ permalink raw reply
* Re: [PATCH] HID: hiddev: keep state alive through disconnect unlock
From: Yousef Alhouseen @ 2026-06-29 13:57 UTC (permalink / raw)
To: Hillf Danton
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-usb,
linux-kernel, syzbot+563191a4939ddbfe73d4
In-Reply-To: <20260628222617.226-1-hdanton@sina.com>
The missing interleaving is that mutex_unlock() clears the owner
before taking wait_lock. A contender already spinning on existancelock
can acquire it after that owner clear, reach the final-release path,
and free hiddev before the disconnecting task reaches
raw_spin_lock_irqsave(&lock->wait_lock, ...). It does not need to be
woken by the disconnecting task.
That is also why mutex_unlock() explicitly requires the containing
object to remain alive until the call returns. I will make this
interleaving explicit in v2.
Thanks,
Yousef
On Mon, 29 Jun 2026 06:26:15 +0800, Hillf Danton <hdanton@sina.com> wrote:
> On Sun, 28 Jun 2026 11:32:45 +0200 Yousef Alhouseen wrote:
> > hiddev_disconnect() drops existancelock before freeing the hiddev state,
> > but a waiting final file release can run as soon as the mutex becomes
> > available. On PREEMPT_RT, that waiter may free hiddev while the disconnect
> > thread is still executing the mutex slow-unlock path, causing a
> > use-after-free in the mutex implementation.
> >
> The root cause is not specified as clearly as expected.
>
> hiddev_disconnect() hiddev_release()
> --- ---
> mutex_lock(&hiddev->existancelock);
> hiddev->exist = 0;
>
> if (hiddev->open) {
> hid_hw_close(hiddev->hid);
> wake_up_interruptible(&hiddev->wait);
> mutex_unlock(&hiddev->existancelock);
> __mutex_unlock_slowpath()
> raw_spin_lock_irqsave() //UAF
>
> mutex_lock(&list->hiddev->existancelock);
> if (!--list->hiddev->open) {
> if (list->hiddev->exist) {
> hid_hw_close(list->hiddev->hid);
> hid_hw_power(list->hiddev->hid, PM_HINT_NORMAL);
> } else {
> mutex_unlock(&list->hiddev->existancelock);
> kfree(list->hiddev); // free mem
> vfree(list);
> return 0;
> }
> }
> mutex_unlock(&list->hiddev->existancelock);
>
> Given the syzbot report, uaf occured upon acquiring the raw spinlock in
> __mutex_unlock_slowpath(), but no mutex waiter could be waken up without
> the raw spinlock held, thus the report sounds false positive.
>
> > Give the connection and each open file an explicit reference. Drop each
> > reference only after its existancelock critical section has completed, so
> > the state cannot be freed from the other unlock path.
> >
> > Fixes: 079034073faf ("HID: hiddev cleanup -- handle all error conditions properly")
> > Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
> > ---
> > drivers/hid/usbhid/hiddev.c | 37 +++++++++++++++++++------------------
> > include/linux/hiddev.h | 2 ++
> > 2 files changed, 21 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> > index 6378801b22c6..21396481995b 100644
> > --- a/drivers/hid/usbhid/hiddev.c
> > +++ b/drivers/hid/usbhid/hiddev.c
> > @@ -46,6 +46,12 @@ struct hiddev_list {
> > struct mutex thread_lock;
> > };
> >
> > +static void hiddev_put(struct hiddev *hiddev)
> > +{
> > + if (refcount_dec_and_test(&hiddev->refcount))
> > + kfree(hiddev);
> > +}
> > +
> > /*
> > * Find a report, given the report's type and ID. The ID can be specified
> > * indirectly by REPORT_ID_FIRST (which returns the first report of the given
> > @@ -216,26 +222,21 @@ static int hiddev_fasync(int fd, struct file *file, int on)
> > static int hiddev_release(struct inode * inode, struct file * file)
> > {
> > struct hiddev_list *list = file->private_data;
> > + struct hiddev *hiddev = list->hiddev;
> > unsigned long flags;
> >
> > - spin_lock_irqsave(&list->hiddev->list_lock, flags);
> > + spin_lock_irqsave(&hiddev->list_lock, flags);
> > list_del(&list->node);
> > - spin_unlock_irqrestore(&list->hiddev->list_lock, flags);
> > + spin_unlock_irqrestore(&hiddev->list_lock, flags);
> >
> > - mutex_lock(&list->hiddev->existancelock);
> > - if (!--list->hiddev->open) {
> > - if (list->hiddev->exist) {
> > - hid_hw_close(list->hiddev->hid);
> > - hid_hw_power(list->hiddev->hid, PM_HINT_NORMAL);
> > - } else {
> > - mutex_unlock(&list->hiddev->existancelock);
> > - kfree(list->hiddev);
> > - vfree(list);
> > - return 0;
> > - }
> > + mutex_lock(&hiddev->existancelock);
> > + if (!--hiddev->open && hiddev->exist) {
> > + hid_hw_close(hiddev->hid);
> > + hid_hw_power(hiddev->hid, PM_HINT_NORMAL);
> > }
> >
> > - mutex_unlock(&list->hiddev->existancelock);
> > + mutex_unlock(&hiddev->existancelock);
> > + hiddev_put(hiddev);
> > vfree(list);
> >
> > return 0;
> > @@ -270,6 +271,7 @@ static int __hiddev_open(struct hiddev *hiddev, struct file *file)
> > spin_unlock_irq(&hiddev->list_lock);
> >
> > file->private_data = list;
> > + refcount_inc(&hiddev->refcount);
> >
> > return 0;
> >
> > @@ -897,6 +899,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
> > INIT_LIST_HEAD(&hiddev->list);
> > spin_lock_init(&hiddev->list_lock);
> > mutex_init(&hiddev->existancelock);
> > + refcount_set(&hiddev->refcount, 1);
> > hid->hiddev = hiddev;
> > hiddev->hid = hid;
> > hiddev->exist = 1;
> > @@ -937,9 +940,7 @@ void hiddev_disconnect(struct hid_device *hid)
> > if (hiddev->open) {
> > hid_hw_close(hiddev->hid);
> > wake_up_interruptible(&hiddev->wait);
> > - mutex_unlock(&hiddev->existancelock);
> > - } else {
> > - mutex_unlock(&hiddev->existancelock);
> > - kfree(hiddev);
> > }
> > + mutex_unlock(&hiddev->existancelock);
> > + hiddev_put(hiddev);
> > }
> > diff --git a/include/linux/hiddev.h b/include/linux/hiddev.h
> > index 2164c03d2c72..8e9f8a33e359 100644
> > --- a/include/linux/hiddev.h
> > +++ b/include/linux/hiddev.h
> > @@ -13,6 +13,7 @@
> > #ifndef _HIDDEV_H
> > #define _HIDDEV_H
> >
> > +#include <linux/refcount.h>
> > #include <uapi/linux/hiddev.h>
> >
> >
> > @@ -24,6 +25,7 @@ struct hiddev {
> > int minor;
> > int exist;
> > int open;
> > + refcount_t refcount;
> > struct mutex existancelock;
> > wait_queue_head_t wait;
> > struct hid_device *hid;
> > --
> > 2.54.0
^ permalink raw reply
* [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 13:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Marcel Holtmann, MyungJoo Ham, Chanwoo Choi,
Geert Uytterhoeven, Andy Shevchenko, Dmitry Torokhov, Ulf Hansson,
linux-bluetooth, linux-kernel, linux-gpio, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc, linux-arm-kernel, linux-pm,
linux-usb
From: Arnd Bergmann <arnd@arndb.de>
Most remaining users of desc_to_gpio() only call it for printing debug
information.
Replace this with a new gpiod_name() helper that returns the
gpio_desc->name string after checking the gpio_desc pointer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Not sure if this the way we want to take this, or if the gpio name is
an appropriate replacement in debug printk.
Since most of the callers of desc_to_gpio() and gpio_to_desc() are
otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
include linux/gpio/legacy.h, only a handful of instances remain that
are otherwise in files that otherwise only use the descriptor interfaces:
arch/arm/mach-pxa/pxa27x.c: reset_gpio = desc_to_gpio(gpiod);
arch/arm/plat-orion/gpio.c: unsigned gpio = desc_to_gpio(desc);
drivers/gpio/gpio-nomadik.c: mode = nmk_prcm_gpiocr_get_mode(pctldev, desc_to_gpio(desc));
drivers/gpio/gpiolib-acpi-core.c: desc = gpio_to_desc(agpio->pin_table[pin_index]);
drivers/gpio/gpiolib-cdev.c: hte_init_line_attr(hdesc, desc_to_gpio(line->desc), flags, NULL,
drivers/gpio/gpiolib-sysfs.c: desc = gpio_to_desc(gpio);
drivers/gpio/gpiolib-sysfs.c: desc_to_gpio(desc));
drivers/gpio/gpiolib.c: trace_gpio_direction(desc_to_gpio(desc), 1, ret);
drivers/input/misc/soc_button_array.c: *gpio_ret = desc_to_gpio(desc);
drivers/pinctrl/core.c: gdev = gpiod_to_gpio_device(gpio_to_desc(gpio_num));
drivers/platform/x86/x86-android-tablets/core.c: * 2. Calling desc_to_gpio() to get an old style GPIO number for gpio-keys
drivers/soc/fsl/qe/gpio.c: gpio_num = desc_to_gpio(gpiod);
---
drivers/bluetooth/hci_intel.c | 4 ++--
drivers/extcon/extcon-rtk-type-c.c | 4 ++--
drivers/gpio/gpio-aggregator.c | 4 ++--
drivers/gpio/gpiolib.c | 13 +++++++++++++
drivers/gpu/drm/bridge/analogix/anx7625.c | 6 +++---
drivers/i2c/busses/i2c-gpio.c | 4 ++--
drivers/iio/accel/mma9551.c | 4 ++--
drivers/iio/humidity/dht11.c | 2 +-
drivers/input/touchscreen/edt-ft5x06.c | 6 +++---
drivers/input/touchscreen/hycon-hy46xx.c | 5 ++---
drivers/mmc/host/atmel-mci.c | 8 ++++----
drivers/power/supply/bq24257_charger.c | 2 +-
drivers/usb/gadget/udc/at91_udc.c | 4 ++--
include/linux/gpio/consumer.h | 8 ++++++++
14 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
index c31105b91e47..2e6ebc152bcb 100644
--- a/drivers/bluetooth/hci_intel.c
+++ b/drivers/bluetooth/hci_intel.c
@@ -1176,8 +1176,8 @@ static int intel_probe(struct platform_device *pdev)
list_add_tail(&idev->list, &intel_device_list);
mutex_unlock(&intel_device_list_lock);
- dev_info(&pdev->dev, "registered, gpio(%d)/irq(%d).\n",
- desc_to_gpio(idev->reset), idev->irq);
+ dev_info(&pdev->dev, "registered, gpio(%s)/irq(%d).\n",
+ gpiod_name(idev->reset), idev->irq);
return 0;
}
diff --git a/drivers/extcon/extcon-rtk-type-c.c b/drivers/extcon/extcon-rtk-type-c.c
index 82b60b927e41..fb57e9d7ddb6 100644
--- a/drivers/extcon/extcon-rtk-type-c.c
+++ b/drivers/extcon/extcon-rtk-type-c.c
@@ -1356,8 +1356,8 @@ static int extcon_rtk_type_c_probe(struct platform_device *pdev)
(int)PTR_ERR(gpio));
} else {
type_c->rd_ctrl_gpio_desc = gpio;
- dev_dbg(dev, "%s get rd-ctrl-gpios (id=%d) OK\n",
- __func__, desc_to_gpio(gpio));
+ dev_dbg(dev, "%s get rd-ctrl-gpios (id=%s) OK\n",
+ __func__, gpiod_name(gpio));
}
}
diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
index bc6699a821ee..27df680fbdbb 100644
--- a/drivers/gpio/gpio-aggregator.c
+++ b/drivers/gpio/gpio-aggregator.c
@@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
fwd->descs[offset] = desc;
- dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
- desc_to_gpio(desc), gpiod_to_irq(desc));
+ dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
+ gpiod_name(desc), gpiod_to_irq(desc));
return 0;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1f498d6c8c68..00de24db74a5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -4122,6 +4122,19 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)
}
EXPORT_SYMBOL_GPL(gpiod_set_consumer_name);
+/**
+ * gpiod_name() - get a name to print for a gpio descriptor
+ * @desc: gpio or NULL pointer to query
+ *
+ * Returns:
+ * The desc->name field or a dummy string for unknown GPIOs.
+ */
+const char *gpiod_name(const struct gpio_desc *desc)
+{
+ return desc ? desc->name : "(no gpio)";
+}
+EXPORT_SYMBOL_GPL(gpiod_name);
+
/**
* gpiod_is_shared() - check if this GPIO can be shared by multiple consumers
* @desc: GPIO to inspect
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c
index fffcd6154c71..5dce097d4045 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1448,9 +1448,9 @@ static void anx7625_init_gpio(struct anx7625_data *platform)
if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
platform->pdata.low_power_mode = 1;
- DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %d, reset %d.\n",
- desc_to_gpio(platform->pdata.gpio_p_on),
- desc_to_gpio(platform->pdata.gpio_reset));
+ DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %s, reset %s.\n",
+ gpiod_name(platform->pdata.gpio_p_on),
+ gpiod_name(platform->pdata.gpio_reset));
} else {
platform->pdata.low_power_mode = 0;
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode.\n");
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index f4355b17bfbf..4c320a833d9e 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -440,8 +440,8 @@ static int i2c_gpio_probe(struct platform_device *pdev)
* get accessors to get the actual name of the GPIO line,
* from the descriptor, then provide that instead.
*/
- dev_info(dev, "using lines %u (SDA) and %u (SCL%s)\n",
- desc_to_gpio(priv->sda), desc_to_gpio(priv->scl),
+ dev_info(dev, "using lines %s (SDA) and %s (SCL%s)\n",
+ gpiod_name(priv->sda), gpiod_name(priv->scl),
pdata->scl_is_output_only
? ", no clock stretching" : "");
diff --git a/drivers/iio/accel/mma9551.c b/drivers/iio/accel/mma9551.c
index 020370b0ec07..b9d1fc3caf83 100644
--- a/drivers/iio/accel/mma9551.c
+++ b/drivers/iio/accel/mma9551.c
@@ -426,8 +426,8 @@ static int mma9551_gpio_probe(struct iio_dev *indio_dev)
return ret;
}
- dev_dbg(dev, "gpio resource, no:%d irq:%d\n",
- desc_to_gpio(gpio), data->irqs[i]);
+ dev_dbg(dev, "gpio resource, no:%s irq:%d\n",
+ gpiod_name(gpio), data->irqs[i]);
}
return 0;
diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
index 980cb946bbf7..ca6b8c53e462 100644
--- a/drivers/iio/humidity/dht11.c
+++ b/drivers/iio/humidity/dht11.c
@@ -305,7 +305,7 @@ static int dht11_probe(struct platform_device *pdev)
dht11->irq = gpiod_to_irq(dht11->gpiod);
if (dht11->irq < 0) {
- dev_err(dev, "GPIO %d has no interrupt\n", desc_to_gpio(dht11->gpiod));
+ dev_err(dev, "GPIO %s has no interrupt\n", gpiod_name(dht11->gpiod));
return -EINVAL;
}
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index d3b1177185a3..2d31c77614b0 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1326,10 +1326,10 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client)
edt_ft5x06_ts_prepare_debugfs(tsdata);
dev_dbg(&client->dev,
- "EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
+ "EDT FT5x06 initialized: IRQ %d, WAKE pin %s, Reset pin %s.\n",
client->irq,
- tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
- tsdata->reset_gpio ? desc_to_gpio(tsdata->reset_gpio) : -1);
+ gpiod_name(tsdata->wake_gpio),
+ gpiod_name(tsdata->reset_gpio));
return 0;
}
diff --git a/drivers/input/touchscreen/hycon-hy46xx.c b/drivers/input/touchscreen/hycon-hy46xx.c
index 1513f20cbf51..797667c5dd99 100644
--- a/drivers/input/touchscreen/hycon-hy46xx.c
+++ b/drivers/input/touchscreen/hycon-hy46xx.c
@@ -528,9 +528,8 @@ static int hycon_hy46xx_probe(struct i2c_client *client)
return error;
dev_dbg(&client->dev,
- "HYCON HY46XX initialized: IRQ %d, Reset pin %d.\n",
- client->irq,
- tsdata->reset_gpio ? desc_to_gpio(tsdata->reset_gpio) : -1);
+ "HYCON HY46XX initialized: IRQ %d, Reset pin %s.\n",
+ client->irq, gpiod_name(tsdata->reset_gpio));
return 0;
}
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 3b4928f5b9b2..b21820564315 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2255,11 +2255,11 @@ static int atmci_init_slot(struct atmel_mci *host,
slot->sdio_irq = sdio_irq;
dev_dbg(&mmc->class_dev,
- "slot[%u]: bus_width=%u, detect_pin=%d, "
- "detect_is_active_high=%s, wp_pin=%d\n",
- id, slot_data->bus_width, desc_to_gpio(slot_data->detect_pin),
+ "slot[%u]: bus_width=%u, detect_pin=%s, "
+ "detect_is_active_high=%s, wp_pin=%s\n",
+ id, slot_data->bus_width, gpiod_name(slot_data->detect_pin),
str_true_false(!gpiod_is_active_low(slot_data->detect_pin)),
- desc_to_gpio(slot_data->wp_pin));
+ gpiod_name(slot_data->wp_pin));
mmc->ops = &atmci_ops;
mmc->f_min = DIV_ROUND_UP(host->bus_hz, 512);
diff --git a/drivers/power/supply/bq24257_charger.c b/drivers/power/supply/bq24257_charger.c
index 72f1bfea8d54..b756bab74eec 100644
--- a/drivers/power/supply/bq24257_charger.c
+++ b/drivers/power/supply/bq24257_charger.c
@@ -868,7 +868,7 @@ static void bq24257_pg_gpio_probe(struct bq24257_device *bq)
}
if (bq->pg)
- dev_dbg(bq->dev, "probed PG pin = %d\n", desc_to_gpio(bq->pg));
+ dev_dbg(bq->dev, "probed PG pin = %s\n", gpiod_name(bq->pg));
}
static int bq24257_fw_probe(struct bq24257_device *bq)
diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c
index 5aa360ba4f03..099313604387 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1896,8 +1896,8 @@ static int at91udc_probe(struct platform_device *pdev)
gpiod_to_irq(udc->board.vbus_pin),
at91_vbus_irq, 0, driver_name, udc);
if (retval) {
- DBG("request vbus irq %d failed\n",
- desc_to_gpio(udc->board.vbus_pin));
+ DBG("request vbus irq %s failed\n",
+ gpiod_name(udc->board.vbus_pin));
goto err_unprepare_iclk;
}
}
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index fceeefd5f893..9c91fae62f8c 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -172,6 +172,8 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name);
bool gpiod_is_shared(const struct gpio_desc *desc);
+const char *gpiod_name(const struct gpio_desc *desc);
+
/* Convert between the old gpio_ and new gpiod_ interfaces */
struct gpio_desc *gpio_to_desc(unsigned gpio);
int desc_to_gpio(const struct gpio_desc *desc);
@@ -538,6 +540,12 @@ static inline bool gpiod_is_shared(const struct gpio_desc *desc)
return false;
}
+static inline const char *gpiod_name(const struct gpio_desc *desc)
+{
+ WARN_ON(desc);
+ return "(no gpio)";
+}
+
static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
{
return NULL;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Andreas Schwab @ 2026-06-29 14:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Jun 29 2026, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
A few of them already used <linux/gpio/consumer.h>, and is duplicated
now.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: sashiko-bot @ 2026-06-29 14:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: dmitry.torokhov, linux-input, dri-devel
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Uncanceled timer in the probe error path leads to a Use-After-Free when the timer fires.
- [High] Uncanceled delayed work in the probe error path and early IRQ request lead to Use-After-Free.
- [High] The return value of extcon_rtk_type_c_edev_register() is assigned but never checked, leading to silent failures.
--
commit fd9fdd473dd5d54a8f94bae5e74133accbec590a
Author: Arnd Bergmann <arnd@arndb.de>
gpiolib: introduce gpio_name() helper
Most remaining users of desc_to_gpio() only call it for printing debug
information.
Replace this with a new gpiod_name() helper that returns the
gpio_desc->name string after checking the gpio_desc pointer.
> diff --git a/drivers/extcon/extcon-rtk-type-c.c b/drivers/extcon/extcon-rtk-type-c.c
> index 82b60b927e41a..fb57e9d7ddb63 100644
> --- a/drivers/extcon/extcon-rtk-type-c.c
> +++ b/drivers/extcon/extcon-rtk-type-c.c
> @@ -1356,8 +1356,8 @@ static int extcon_rtk_type_c_probe(struct platform_device *pdev)
> (int)PTR_ERR(gpio));
> } else {
> type_c->rd_ctrl_gpio_desc = gpio;
> - dev_dbg(dev, "%s get rd-ctrl-gpios (id=%d) OK\n",
> - __func__, desc_to_gpio(gpio));
> + dev_dbg(dev, "%s get rd-ctrl-gpios (id=%s) OK\n",
> + __func__, gpiod_name(gpio));
> }
> }
[Severity: High]
This is a pre-existing issue, but I noticed a potential use-after-free if
extcon_rtk_type_c_init() fails.
In extcon_rtk_type_c_probe(), the code requests an IRQ before the delayed
work is initialized:
ret = devm_request_irq(dev, type_c->irq, type_c_detect_irq, ...);
...
INIT_DELAYED_WORK(&type_c->delayed_work, host_device_switch);
ret = extcon_rtk_type_c_init(type_c);
if (ret) {
dev_err(dev, "%s failed to init type_c\n", __func__);
goto err;
}
Could an early interrupt schedule the uninitialized work?
Also, if extcon_rtk_type_c_init() fails, the code jumps to the err label
and returns without canceling the delayed work. Since the structure is
freed by devres, will this cause a use-after-free when the work executes?
[Severity: High]
This is also a pre-existing issue, but further down in the same function,
the return value of extcon_rtk_type_c_edev_register() is assigned to ret
but is not checked:
ret = extcon_rtk_type_c_edev_register(type_c);
create_debug_files(type_c);
return 0;
Could this mask a registration failure, since the function unconditionally
returns 0?
[ ... ]
> diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c
> index 5aa360ba4f039..0993136043870 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -1896,8 +1896,8 @@ static int at91udc_probe(struct platform_device *pdev)
> gpiod_to_irq(udc->board.vbus_pin),
> at91_vbus_irq, 0, driver_name, udc);
> if (retval) {
> - DBG("request vbus irq %d failed\n",
> - desc_to_gpio(udc->board.vbus_pin));
> + DBG("request vbus irq %s failed\n",
> + gpiod_name(udc->board.vbus_pin));
> goto err_unprepare_iclk;
> }
> }
[Severity: High]
This is a pre-existing issue, but there appears to be a missing timer cleanup
in the probe error path.
In at91udc_probe(), when vbus_polled is true, a timer is armed:
if (udc->board.vbus_polled) {
INIT_WORK(&udc->vbus_timer_work, at91_vbus_timer_work);
timer_setup(&udc->vbus_timer, at91_vbus_timer, 0);
mod_timer(&udc->vbus_timer,
jiffies + VBUS_POLL_TIMEOUT);
}
If usb_add_gadget_udc() fails later, the code jumps to err_unprepare_iclk
and returns without deleting the timer:
retval = usb_add_gadget_udc(dev, &udc->gadget);
if (retval)
goto err_unprepare_iclk;
...
err_unprepare_iclk:
clk_unprepare(udc->iclk);
err_unprepare_fclk:
clk_unprepare(udc->fclk);
return retval;
If the probe fails, devres will free the udc structure. Does this mean the
timer can still fire and access the freed udc memory, causing a
use-after-free?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629135917.1308621-1-arnd@kernel.org?part=1
^ permalink raw reply
* Re: [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
From: Arnd Bergmann @ 2026-06-29 14:13 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-input, linux-leds, Dmitry Torokhov, Lee Jones
In-Reply-To: <20260629134613.F154B1F000E9@smtp.kernel.org>
On Mon, Jun 29, 2026, at 15:46, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider:
> - [High] Drivers depending on `GPIOLIB_LEGACY` rather than selecting it
> are rendered unselectable and silently disabled on normal builds.
> - [Low] Disabling CONFIG_GPIOLIB_LEGACY by default causes widespread
> build failures for platforms and drivers still relying on legacy GPIO
> functions.
That is the idea, yes: If someone adds back a new legacy user, they
will get a build failure after this patch.
>> All users of the legacy interface now select CONFIG_GPIOLIB_LEGACY,
>> so it can be turned off by default and only get built on platforms
>> that still have one unconverted driver.
>
> [Severity: High]
> Is this description entirely accurate?
>
> There appear to be drivers that use 'depends on GPIOLIB_LEGACY' rather than
> selecting it, such as MFD_AAT2870_CORE, MFD_SI476X_CORE, and
> SND_SOC_TLV320DAC33.
>
> If GPIOLIB_LEGACY defaults to 'n' without COMPILE_TEST enabled, will these
> drivers be rendered unselectable and silently disabled on normal builds?
Yes, correct. I made sure that all platforms that do use GPIO
numbers select those symbols. The three drivers listed above
can only work if a platform has a board file with the corresponding
platform data, but nothing provides si476x_platform_data or
aat2870_platform_data, and SND_SOC_TLV320DAC33 is already
a hidden Kconfig symbol and disabled for all platforms.
Arnd
^ permalink raw reply
* [BUG] I2C HID touchpad BLTP7853:00 347D:7853 enumerates but reports no events on MECHREVO XINGYAO Series-P916F-PTL
From: Steve Yang @ 2026-06-29 14:15 UTC (permalink / raw)
To: linux-input, linux-acpi, linux-i2c, linux-gpio
Hello,
Resending as plain text; sorry if this is a duplicate. My previous
message was rejected by linux-acpi because Gmail sent a HTML part.
I am seeing a non-working internal I2C HID touchpad on a new MECHREVO
laptop. The device enumerates, binds to i2c_hid_acpi + hid-multitouch,
and userspace sees it as a touchpad, but touching/clicking it produces
no input events. The GPIO interrupt counter also does not increase
while touching the pad.
I am new to kernel debugging, but I have the machine here and can test
patches, ACPI overrides, debug kernels, etc.
Hardware
========
DMI, with serial/UUID intentionally omitted:
BIOS Vendor: MECHREVO
BIOS Version: 1.00
BIOS Release Date: 03/14/2026
Firmware Revision: 1.48
EC Firmware Revision: 1.0
System Manufacturer: MECHREVO
Product Name: XINGYAO Series
Family: Panther Lake
Base Board Product Name: XINGYAO Series-P916F-PTL
Software
========
Linux archbook 7.0.14-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 27 Jun
2026 16:15:10 +0000 x86_64 GNU/Linux
linux-firmware 20260622-1
libinput 1.31.3
hid-tools 0.12
acpica 20251212
Kernel command line at initial capture time:
BOOT_IMAGE=/vmlinuz-linux root=UUID=<omitted> rw rootflags=subvol=@
loglevel=3 quiet
Device identification
=====================
/sys/bus/i2c/devices/i2c-BLTP7853:00/uevent:
DRIVER=i2c_hid_acpi
MODALIAS=acpi:BLTP7853:PNP0C50:
/sys/bus/hid/devices/0018:347D:7853.0001/uevent:
DRIVER=hid-multitouch
HID_ID=0018:0000347D:00007853
HID_NAME=BLTP7853:00 347D:7853
HID_PHYS=i2c-BLTP7853:00
MODALIAS=hid:b0018g0004v0000347Dp00007853
udev for /dev/input/event5:
DEVNAME=/dev/input/event5
ID_INPUT=1
ID_INPUT_TOUCHPAD=1
ID_INPUT_WIDTH_MM=115
ID_INPUT_HEIGHT_MM=72
ID_BUS=i2c
ID_INTEGRATION=internal
ID_INPUT_TOUCHPAD_INTEGRATION=internal
LIBINPUT_DEVICE_GROUP=18/347d/7853:i2c-BLTP7853:00
Symptoms / tests
================
1. dmesg shows the device binding successfully:
input: BLTP7853:00 347D:7853 Mouse ...
input: BLTP7853:00 347D:7853 Touchpad ...
hid-generic 0018:347D:7853.0001: input,hidraw0: I2C HID v1.00 Mouse
[BLTP7853:00 347D:7853] on i2c-BLTP7853:00
input: BLTP7853:00 347D:7853 Touchpad ...
hid-multitouch 0018:347D:7853.0001: input,hidraw0: I2C HID v1.00
Mouse [BLTP7853:00 347D:7853] on i2c-BLTP7853:00
2. evtest on /dev/input/event5 shows normal-looking touchpad
capabilities, for example
ABS_X/ABS_Y/ABS_MT_POSITION_X/ABS_MT_POSITION_Y/ABS_MT_SLOT/ABS_MT_TRACKING_ID
and BTN_TOUCH/BTN_LEFT. However, during physical touch/click tests it
prints no events after:
Testing ... (interrupt to exit)
3. /proc/interrupts has an IRQ for the touchpad in the original ACPI
configuration:
intel-gpio 18 BLTP7853:00
While physically touching/clicking the touchpad, the counter did not increase.
4. debugfs gpio shows this line as claimed by the touchpad and high:
gpiochip1: 51 GPIOs, parent: platform/INTC10BC:01, INTC10BC:01:
gpio-18 ( |TPD0 GpioInt(0) ) in hi IRQ
5. KDE/libinput sees a touchpad-class input device, but the pointer
does not move and clicks do not work.
Things already tried
====================
None of these changed the behavior:
- acpi_osi=Windows 2021
- BIOS option named "Enable Windows OSI"
- unbind/bind i2c-BLTP7853:00 from i2c_hid_acpi
- echo on > /sys/bus/i2c/devices/i2c-BLTP7853:00/power/control
- unloading huawei_wmi
- setting HID feature Inputmode=3 with hid-feature
- setting HID feature Surface Switch=1 and Button Switch=1
ACPI override experiments
=========================
The kernel supports ACPI table upgrade, and I confirmed the modified
SSDT was loaded each time via dmesg, for example:
ACPI: Table Upgrade: override [SSDT-XXXXXX-I2C_DEVT]
I tried these changes to the touchpad GpioInt resource:
original: GpioInt(Level, ActiveLow, ...)
test 1: GpioInt(Level, ActiveHigh, ...)
test 2: GpioInt(Edge, ActiveLow, ...)
test 3: GpioInt(Edge, ActiveHigh, ...)
All three GpioInt variants still resulted in an intel-gpio IRQ for
BLTP7853:00, but the IRQ counter did not increase while
touching/clicking the touchpad.
I also forced _CRS to return the SBFI Interrupt() resource instead of
the SBFG GpioInt() resource. That changed the interrupt to:
IR-IO-APIC 84-fasteoi BLTP7853:00
but it caused an apparent interrupt storm, with the counter increasing
by thousands over a few seconds, and still no evtest events. So the
Interrupt() path does not look correct either.
ACPI notes
==========
The touchpad ACPI device appears in SSDT under:
\_SB.PC00.I2C5.TPD0
Relevant decompiled pieces from ssdt18.dsl:
Scope (\_SB.PC00.I2C5)
{
Device (TPD0)
{
Name (HID2, Zero)
...
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,
"\\_SB.GPI1", 0x00, ResourceConsumer, ,)
{ 0x0000 }
})
Name (SBFI, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow,
ExclusiveAndWake, ,, _Y08)
{
0x00000000,
}
})
CreateWordField (SBFB, \_SB.PC00.I2C5.TPD0._Y07._ADR, BADR)
CreateDWordField (SBFB, \_SB.PC00.I2C5.TPD0._Y07._SPE, SPED)
CreateWordField (SBFG, 0x17, INT1)
CreateDWordField (SBFI, \_SB.PC00.I2C5.TPD0._Y08._INT, INT2)
Method (_INI, 0, NotSerialized)
{
INT1 = GNUM (\TPIT)
INT2 = INUM (\TPIT)
If ((TPDM == Zero))
{
SHPO (\TPIT, One)
}
SGRA (\TPIT, TPDM)
If ((TPDM == One))
{
SGII (\TPIT, Zero)
GRXE (\TPIT, Zero)
}
If ((\TPTY == One))
{
_HID = "BLTP7853"
HID2 = One
BADR = 0x2C
SPED = 0x00061A80
Return (Zero)
}
}
Name (_HID, "XXXX0000")
Name (_CID, "PNP0C50")
Method (_CRS, 0, NotSerialized)
{
If ((TPDM == Zero))
{
Return (ConcatenateResTemplate (I2CM (I2CX, BADR,
SPED), SBFG))
}
Return (ConcatenateResTemplate (I2CM (I2CX, BADR, SPED), SBFI))
}
}
}
ssdt13.dsl defines the NVS fields used by that code:
OperationRegion (LCNV, SystemMemory, 0x6FDE4000, 0x0300)
Field (LCNV, AnyAcc, Lock, Preserve)
{
EDID, 4096,
TPTY, 8,
TPST, 8,
TPIT, 32,
...
}
A possibly relevant observation from the same SSDT: under
\_SB.PC00.I2C5, TPD0 seems to use the PXTC power resource, and the
Arg0==0 path in PON() appears to only route/configure IRQ. The Arg0==1
path, apparently for the touch panel PTPL resource, is the one that
toggles TPWR/TRST GPIOs. I have not tested overriding TPD0 to use that
power resource yet.
Question
========
Does this still look like an ACPI GPIO/resource issue, or should I now
focus on an i2c-hid/hid-multitouch quirk or a missing vendor-specific
reset/init sequence for HID 347D:7853?
I have a full debug bundle available, including acpidump, decompiled
SSDTs, dmesg, udev info, evtest output, hid-recorder output,
dmidecode, and /proc/interrupts snapshots. I can provide any specific
files or test patches you want.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Arnd Bergmann @ 2026-06-29 14:24 UTC (permalink / raw)
To: Andreas Schwab, Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, Netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <mvmik71win7.fsf@suse.de>
On Mon, Jun 29, 2026, at 16:01, Andreas Schwab wrote:
> On Jun 29 2026, Arnd Bergmann wrote:
>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> The linux/gpio.h header used to be the global definition for the gpio
>> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
>> 130 of those remain, so this series cleans out the rest.
>>
>> In each subsystem, we can replace the header either with
>> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
>
> A few of them already used <linux/gpio/consumer.h>, and is duplicated
> now.
Indeed, I have removed the extra ones now and folded those into
the patches.
Arnd
diff --git a/drivers/gpib/gpio/gpib_bitbang.c b/drivers/gpib/gpio/gpib_bitbang.c
index 2e8d895db06a..34d14b94a0b8 100644
--- a/drivers/gpib/gpio/gpib_bitbang.c
+++ b/drivers/gpib/gpio/gpib_bitbang.c
@@ -64,7 +64,6 @@
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
#include <linux/gpio/machine.h>
-#include <linux/gpio/consumer.h>
#include <linux/irq.h>
static int sn7516x_used = 1, sn7516x;
diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
index 98d0269a978f..8863b741d1a3 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -16,7 +16,6 @@
#include <linux/interrupt.h>
#include <linux/jiffies.h>
#include <linux/module.h>
-#include <linux/gpio/consumer.h>
#include <linux/input/matrix_keypad.h>
#include <linux/slab.h>
#include <linux/of.h>
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index eb11bf2e9436..a6c984205123 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -15,7 +15,6 @@
#include <linux/dmi.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio_keys.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
static bool use_low_level_irq;
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 88c5c52e0e38..5f5adc9c9e83 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -16,7 +16,6 @@
#include <linux/net_tstamp.h>
#include <linux/ptp_classify.h>
#include <linux/ptp_pch.h>
-#include <linux/gpio/consumer.h>
#define PCH_GBE_MAR_ENTRIES 16
#define PCH_GBE_SHORT_PKT 64
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index a18263d5bb02..06151f207134 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -9,7 +9,6 @@
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
index d9c06129ed23..171bf097a8b8 100644
--- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
+++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
@@ -4,7 +4,6 @@
#include <linux/delay.h>
#include <linux/extcon-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 2233babc0078..1f5dba49ace4 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/mfd/syscon.h>
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index 5040c7d1e1b9..2089ec5124e8 100644
--- a/include/linux/mfd/ti-lmu.h
+++ b/include/linux/mfd/ti-lmu.h
@@ -10,7 +10,6 @@
#ifndef __MFD_TI_LMU_H__
#define __MFD_TI_LMU_H__
-#include <linux/gpio/consumer.h>
#include <linux/notifier.h>
#include <linux/regmap.h>
#include <linux/gpio/consumer.h>
diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
index 36c3abc21fed..f2448b4c11fc 100644
--- a/sound/soc/codecs/cs42l84.c
+++ b/sound/soc/codecs/cs42l84.c
@@ -16,7 +16,6 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/i2c.h>
-#include <linux/gpio/consumer.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/acpi.h>
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 8b05d6f9b429..cbed11136935 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -7,7 +7,6 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
^ permalink raw reply related
* Re: [PATCH 5/6] [v5] leds: gpio: make legacy gpiolib interface optional
From: Andy Shevchenko @ 2026-06-29 15:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, 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
In-Reply-To: <20260629130329.1291953-6-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:03:28PM +0200, Arnd Bergmann wrote:
> 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.
...
> gpiod = devm_gpiod_get_index_optional(dev, NULL, idx, GPIOD_OUT_LOW);
> - if (IS_ERR(gpiod))
> - return gpiod;
We can leave these and rather have
gpiod_set_consumer_name(gpiod, template->name);
return gpiod;
than introduce irregular pattern.
> - 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;
> +}
I haven't insisted on this previously as I thought that this was on track to be
applied. Since it's not (yet), please, amend the change.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Andy Shevchenko @ 2026-06-29 15:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
Oh, that's nice!
...
> +/**
> + * gpiod_name() - get a name to print for a gpio descriptor
> + * @desc: gpio or NULL pointer to query
> + *
> + * Returns:
> + * The desc->name field or a dummy string for unknown GPIOs.
> + */
> +const char *gpiod_name(const struct gpio_desc *desc)
> +{
> + return desc ? desc->name : "(no gpio)";
Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
one of validate_desc() / VALIDATE_DESC()?
Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
> +}
...
> +static inline const char *gpiod_name(const struct gpio_desc *desc)
> +{
> + WARN_ON(desc);
> + return "(no gpio)";
Hmm... This will be a second copy with a slight potential of going apart from
the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
and cons, in particular readability with define is questionable.)
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] HID: hiddev: keep state alive through disconnect unlock
From: Yousef Alhouseen @ 2026-06-29 15:29 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-usb, linux-kernel, stable,
syzbot+563191a4939ddbfe73d4, Yousef Alhouseen
mutex_unlock() clears the mutex owner before taking its wait lock. A
thread spinning in the final hiddev file release can acquire
existancelock after hiddev_disconnect() clears the owner, then free
hiddev before the disconnecting thread reaches the mutex wait lock. This
causes a use-after-free in the mutex slow unlock path.
Give the connection and each open file an explicit reference. Drop each
reference only after its existancelock critical section has completed,
so neither unlock path can free the mutex while the other is still using
it.
Fixes: 079034073faf ("HID: hiddev cleanup -- handle all error conditions properly")
Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
Cc: stable@vger.kernel.org
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
Changes in v2:
- Explain the mutex owner-clear/spinning-contender race in the commit log.
- No code changes.
drivers/hid/usbhid/hiddev.c | 37 +++++++++++++++++++------------------
include/linux/hiddev.h | 2 ++
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 6378801b22c6..21396481995b 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -46,6 +46,12 @@ struct hiddev_list {
struct mutex thread_lock;
};
+static void hiddev_put(struct hiddev *hiddev)
+{
+ if (refcount_dec_and_test(&hiddev->refcount))
+ kfree(hiddev);
+}
+
/*
* Find a report, given the report's type and ID. The ID can be specified
* indirectly by REPORT_ID_FIRST (which returns the first report of the given
@@ -216,26 +222,21 @@ static int hiddev_fasync(int fd, struct file *file, int on)
static int hiddev_release(struct inode * inode, struct file * file)
{
struct hiddev_list *list = file->private_data;
+ struct hiddev *hiddev = list->hiddev;
unsigned long flags;
- spin_lock_irqsave(&list->hiddev->list_lock, flags);
+ spin_lock_irqsave(&hiddev->list_lock, flags);
list_del(&list->node);
- spin_unlock_irqrestore(&list->hiddev->list_lock, flags);
+ spin_unlock_irqrestore(&hiddev->list_lock, flags);
- mutex_lock(&list->hiddev->existancelock);
- if (!--list->hiddev->open) {
- if (list->hiddev->exist) {
- hid_hw_close(list->hiddev->hid);
- hid_hw_power(list->hiddev->hid, PM_HINT_NORMAL);
- } else {
- mutex_unlock(&list->hiddev->existancelock);
- kfree(list->hiddev);
- vfree(list);
- return 0;
- }
+ mutex_lock(&hiddev->existancelock);
+ if (!--hiddev->open && hiddev->exist) {
+ hid_hw_close(hiddev->hid);
+ hid_hw_power(hiddev->hid, PM_HINT_NORMAL);
}
- mutex_unlock(&list->hiddev->existancelock);
+ mutex_unlock(&hiddev->existancelock);
+ hiddev_put(hiddev);
vfree(list);
return 0;
@@ -270,6 +271,7 @@ static int __hiddev_open(struct hiddev *hiddev, struct file *file)
spin_unlock_irq(&hiddev->list_lock);
file->private_data = list;
+ refcount_inc(&hiddev->refcount);
return 0;
@@ -897,6 +899,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
INIT_LIST_HEAD(&hiddev->list);
spin_lock_init(&hiddev->list_lock);
mutex_init(&hiddev->existancelock);
+ refcount_set(&hiddev->refcount, 1);
hid->hiddev = hiddev;
hiddev->hid = hid;
hiddev->exist = 1;
@@ -937,9 +940,7 @@ void hiddev_disconnect(struct hid_device *hid)
if (hiddev->open) {
hid_hw_close(hiddev->hid);
wake_up_interruptible(&hiddev->wait);
- mutex_unlock(&hiddev->existancelock);
- } else {
- mutex_unlock(&hiddev->existancelock);
- kfree(hiddev);
}
+ mutex_unlock(&hiddev->existancelock);
+ hiddev_put(hiddev);
}
diff --git a/include/linux/hiddev.h b/include/linux/hiddev.h
index 2164c03d2c72..8e9f8a33e359 100644
--- a/include/linux/hiddev.h
+++ b/include/linux/hiddev.h
@@ -13,6 +13,7 @@
#ifndef _HIDDEV_H
#define _HIDDEV_H
+#include <linux/refcount.h>
#include <uapi/linux/hiddev.h>
@@ -24,6 +25,7 @@ struct hiddev {
int minor;
int exist;
int open;
+ refcount_t refcount;
struct mutex existancelock;
wait_queue_head_t wait;
struct hid_device *hid;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-29 15:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
Hi Arnd,
On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for your patch!
> Not sure if this the way we want to take this, or if the gpio name is
> an appropriate replacement in debug printk.
>
> Since most of the callers of desc_to_gpio() and gpio_to_desc() are
> otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
> include linux/gpio/legacy.h, only a handful of instances remain that
> are otherwise in files that otherwise only use the descriptor interfaces:
> --- a/drivers/gpio/gpio-aggregator.c
> +++ b/drivers/gpio/gpio-aggregator.c
> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>
> fwd->descs[offset] = desc;
>
> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> - desc_to_gpio(desc), gpiod_to_irq(desc));
> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> + gpiod_name(desc), gpiod_to_irq(desc));
>
> return 0;
> }
Before, this printed:
gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
After, this prints:
gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
Same results for instantiation using sysfs or configfs[1], although
the latter does have optional support for specifying the name.
[1] Documentation/admin-guide/gpio/gpio-aggregator.rst
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:45 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <akKN59lv55CXS3HU@ashevche-desk.local>
On Mon, Jun 29, 2026, at 17:23, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
>> +const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + return desc ? desc->name : "(no gpio)";
>
> Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
> one of validate_desc() / VALIDATE_DESC()?
Since all the callers previously call desc_to_gpio and that does
not even check desc at all, it would be a preexisting bug if
any caller passed an error pointer.
I added the NULL pointer check since many callers had that
part originally, like
tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
> Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
Any of those seem fine to me, not sure.
>> +static inline const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + WARN_ON(desc);
>> + return "(no gpio)";
>
> Hmm... This will be a second copy with a slight potential of going apart from
> the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
> and cons, in particular readability with define is questionable.)
I was mostly trying to optimize for consistency with the other
stub functions here. Since it should not actually be used at all
without gpiolib, returning NULL or an empty string here would
also work.
Arnd
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <CAMuHMdXhsM4JzArRuB=A46N-Ogbn2Fans+PVJVA-hEytFq=DeQ@mail.gmail.com>
On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Most remaining users of desc_to_gpio() only call it for printing debug
>> information.
>>
>> Replace this with a new gpiod_name() helper that returns the
>> gpio_desc->name string after checking the gpio_desc pointer.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for your patch!
Thanks for testing!
>> --- a/drivers/gpio/gpio-aggregator.c
>> +++ b/drivers/gpio/gpio-aggregator.c
>> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>>
>> fwd->descs[offset] = desc;
>>
>> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
>> - desc_to_gpio(desc), gpiod_to_irq(desc));
>> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
>> + gpiod_name(desc), gpiod_to_irq(desc));
>>
>> return 0;
>> }
>
> Before, this printed:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
>
> After, this prints:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
>
> Same results for instantiation using sysfs or configfs[1], although
> the latter does have optional support for specifying the name.
I wonder how many of the other instances have the same problem
then. Would it be appropriate for gpiochip_fwd_desc_add() to set
a name itself to address this one?
Arnd
^ permalink raw reply
* Re: (subset) [PATCH v5 0/6] Add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-06-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
On Tue, 23 Jun 2026 22:48:12 +0200, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> [...]
Applied to sunxi/config-for-7.3 in local tree, thanks!
[1/6] arm64: defconfig: Enable Allwinner LRADC input driver
commit: b4158103c45386ab30ba7624bee17ebf33940baa
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] HID: hiddev: keep state alive through disconnect unlock
From: sashiko-bot @ 2026-06-29 15:54 UTC (permalink / raw)
To: Yousef Alhouseen; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260629152947.13821-1-alhouseenyousef@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] A race condition in `hiddev_connect()` exposes the character device before initialization is complete, allowing bypass of `HID_QUIRK_NO_INIT_REPORTS`.
- [Medium] Runtime PM reference on the USB interface is leaked when the device is unbound while a hiddev file is open.
- [Low] An off-by-one error in the `array_index_nospec()` clamping logic prevents reading the last valid usage index during `HIDIOCGUSAGES`.
--
commit afdbfd4c2b634bf186c79d8a144039cac66bc1c8
Author: Yousef Alhouseen <alhouseenyousef@gmail.com>
HID: hiddev: keep state alive through disconnect unlock
This commit fixes a use-after-free issue in the hiddev mutex slow unlock
path. It gives the connection and each open file an explicit reference,
dropping the reference only after the existancelock critical section
completes.
Link: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> index 6378801b22c6d..21396481995b2 100644
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
[ ... ]
> @@ -216,26 +222,21 @@ static int hiddev_fasync(int fd, struct file *file, int on)
> static int hiddev_release(struct inode * inode, struct file * file)
> {
> struct hiddev_list *list = file->private_data;
> + struct hiddev *hiddev = list->hiddev;
> unsigned long flags;
>
> - spin_lock_irqsave(&list->hiddev->list_lock, flags);
> + spin_lock_irqsave(&hiddev->list_lock, flags);
> list_del(&list->node);
> - spin_unlock_irqrestore(&list->hiddev->list_lock, flags);
> + spin_unlock_irqrestore(&hiddev->list_lock, flags);
>
> - mutex_lock(&list->hiddev->existancelock);
> - if (!--list->hiddev->open) {
> - if (list->hiddev->exist) {
> - hid_hw_close(list->hiddev->hid);
> - hid_hw_power(list->hiddev->hid, PM_HINT_NORMAL);
> - } else {
> - mutex_unlock(&list->hiddev->existancelock);
> - kfree(list->hiddev);
> - vfree(list);
> - return 0;
> - }
> + mutex_lock(&hiddev->existancelock);
> + if (!--hiddev->open && hiddev->exist) {
> + hid_hw_close(hiddev->hid);
> + hid_hw_power(hiddev->hid, PM_HINT_NORMAL);
> }
[Severity: Medium]
This is a pre-existing issue, but does this create a runtime PM reference leak
when the device is unbound while a hiddev file is open?
If a device unbind occurs while the file remains open, hiddev_disconnect()
clears hiddev->exist. When hiddev_release() is subsequently called, the
code avoids the hid_hw_power() call because hiddev->exist is 0.
Since the disconnect path does not call hid_hw_power() with PM_HINT_NORMAL,
could this leave the power domain permanently active and defeat USB autosuspend
until physical unplug?
>
> - mutex_unlock(&list->hiddev->existancelock);
> + mutex_unlock(&hiddev->existancelock);
> + hiddev_put(hiddev);
> vfree(list);
>
> return 0;
[ ... ]
> @@ -897,6 +899,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
> INIT_LIST_HEAD(&hiddev->list);
> spin_lock_init(&hiddev->list_lock);
> mutex_init(&hiddev->existancelock);
> + refcount_set(&hiddev->refcount, 1);
> hid->hiddev = hiddev;
> hiddev->hid = hid;
> hiddev->exist = 1;
[Severity: High]
This is a pre-existing issue, but does this create a race condition exposing
the character device before initialization is complete?
Shortly after this block, hiddev_connect() calls usb_register_dev() which
makes the device available to userspace. However, hiddev->initialized is set
later based on HID_QUIRK_NO_INIT_REPORTS.
If a userspace process immediately opens the newly registered device and
issues a HIDIOCGUSAGE ioctl before hiddev->initialized is set, could it
bypass the quirk and improperly trigger usbhid_init_reports() in
hiddev_ioctl()?
[ ... ]
> @@ -937,9 +940,7 @@ void hiddev_disconnect(struct hid_device *hid)
> if (hiddev->open) {
> hid_hw_close(hiddev->hid);
> wake_up_interruptible(&hiddev->wait);
> - mutex_unlock(&hiddev->existancelock);
> - } else {
> - mutex_unlock(&hiddev->existancelock);
> - kfree(hiddev);
> }
> + mutex_unlock(&hiddev->existancelock);
> + hiddev_put(hiddev);
> }
[Severity: Low]
This is a pre-existing issue, but is there an off-by-one error in the clamping
logic within hiddev_ioctl_usage() that prevents reading the last valid usage
index?
When a user issues HIDIOCGUSAGES or HIDIOCSUSAGES, the code does:
uref->usage_index =
array_index_nospec(uref->usage_index,
field->report_count -
uref_multi->num_values);
Because array_index_nospec() strictly requires the index to be less than the
size, does an index exactly equal to the size (which is valid here) get
incorrectly clamped to 0?
Would this silently return the first block of usages instead of the last
valid block?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629152947.13821-1-alhouseenyousef@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 5/6] [v5] leds: gpio: make legacy gpiolib interface optional
From: Arnd Bergmann @ 2026-06-29 15:58 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, 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
In-Reply-To: <akKKxHB6RMymG70Z@ashevche-desk.local>
On Mon, Jun 29, 2026, at 17:09, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 03:03:28PM +0200, Arnd Bergmann wrote:
>
>> gpiod = devm_gpiod_get_index_optional(dev, NULL, idx, GPIOD_OUT_LOW);
>> - if (IS_ERR(gpiod))
>> - return gpiod;
>
> We can leave these and rather have
>
> gpiod_set_consumer_name(gpiod, template->name);
> return gpiod;
>
> than introduce irregular pattern.
>
Ok, changed now.
Arnd
^ permalink raw reply
* Re: (subset) [PATCH v5 0/6] Add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-06-29 16:08 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
On Tue, 23 Jun 2026 22:48:12 +0200, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> [...]
Applied to sunxi/dt-for-7.3 in local tree, thanks!
[2/6] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
commit: c3600c97eb9c1a20a933a7fba08272955f7a7ccc
[3/6] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
commit: 1d81cb06c30746448deb73b6ce9ceccc9fb6ca37
[4/6] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
commit: 5e5e8a2e5a5e31fbe8858f08ef7ac44dff9ee351
[5/6] arm64: dts: allwinner: a100: Add LRADC node
commit: 8fa3a2bf77f0adb5440f25c3e2951543691e1536
[6/6] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
commit: 7204944dcb8f1131b6303a5e9ca11128eb20ac21
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
From: Geert Uytterhoeven @ 2026-06-29 16:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, 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-7-arnd@kernel.org>
On Mon, 29 Jun 2026 at 15:18, Arnd Bergmann <arnd@kernel.org> wrote:
> 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
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware
From: srinivas pandruvada @ 2026-06-29 17:35 UTC (permalink / raw)
To: Wahid7852, linux-input, Zhang, Lixu; +Cc: jikos
In-Reply-To: <20260627224753.35075-1-wahidzk0091@gmail.com>
+Lixu
On Sun, 2026-06-28 at 04:17 +0530, Wahid7852 wrote:
> Some ISH firmware versions (observed on Tiger Lake LP, 8086:a0fc,
> GUID {33AECD58-B679-4E54-9BD9-A04D34F0C226}) periodically re-send an
> unsolicited HOSTIF_DM_ENUM_DEVICES response roughly every 79 seconds.
>
> The current guard collapses two distinct cases into one condition:
>
> if (!(response_flag) || init_done) -> bad packet + ish_hw_reset
>
> This incorrectly treats a valid post-init firmware announcement as a
> corrupted packet, triggering an ISH soft-reset and a full ISHTP
> re-initialisation cycle on each occurrence (~1100 times per day on
> affected hardware).
>
> Split the check: reject messages with no response flag as before, but
> simply discard valid ENUM_DEVICES messages that arrive after init is
> complete.
>
> Signed-off-by: Wahid <wahidzk0091@gmail.com>
Also you need first and last name for sign offs. Not sure this is
allowed format.
Thanks,
Srinivas
> ---
> drivers/hid/intel-ish-hid/ishtp-hid-client.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> index 6d64008f2..ec5e8afe7 100644
> --- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> +++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> @@ -113,8 +113,7 @@ static void process_recv(struct ishtp_cl
> *hid_ishtp_cl, void *recv_buf,
>
> switch (recv_msg->hdr.command & CMD_MASK) {
> case HOSTIF_DM_ENUM_DEVICES:
> - if ((!(recv_msg->hdr.command & ~CMD_MASK) ||
> - client_data->init_done)) {
> + if (!(recv_msg->hdr.command & ~CMD_MASK)) {
> ++client_data->bad_recv_cnt;
> report_bad_packet(hid_ishtp_cl,
> recv_msg,
> cur_pos,
> @@ -122,6 +121,8 @@ static void process_recv(struct ishtp_cl
> *hid_ishtp_cl, void *recv_buf,
> ish_hw_reset(ishtp_get_ishtp_device(
> hid_ishtp_cl));
> break;
> }
> + if (client_data->init_done)
> + break;
> client_data->hid_dev_count = (unsigned
> int)*payload;
> if (!client_data->hid_devices)
> client_data->hid_devices =
> devm_kcalloc(
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware
From: Wahid7852 @ 2026-06-29 18:04 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada; +Cc: jikos, Lixu Zhang, Wahid Khan
In-Reply-To: <20260627224753.35075-1-wahidzk0091@gmail.com>
From: Wahid Khan <wahidzk0091@gmail.com>
Thanks. Correct sign-off should be: Signed-off-by: Wahid Khan <wahidzk0091@gmail.com>.
Should i send a follow up as v2 for this?
^ permalink raw reply
* Re: [PATCH v5 0/5] HID: asus: security fixes and more hardware support
From: Denis Benato @ 2026-06-29 18:00 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-kernel, linux-input, Benjamin Tissoires, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Antheas Kapenekakis, Connor Belli
In-Reply-To: <rr8s664r-5s34-1815-57ss-32p461sopp45@xreary.bet>
On 6/29/26 11:21, Jiri Kosina wrote:
> 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.
Hi Jiri!
Patch 1 contains multiple fixes, mainly use of sleeping calls in atomic contexts:
I'd say slap it in 7.1 fixes.
Patch 2 is a minor improvement removing an OOM message to align the driver
to newer code where that would have been a flagged warning: probably a fix for
7.1 but there's no rush for this one.
Patch 3 is a logic fix, condition is very rare (not sure if even possible) but belongs
to 7.1 almost certainly.
Patch 4 new feature support: goes to 7.2.
Patch 5 unsure. It adds support to the backlight, but to properly do it I'll need
to wait for lamparray to be merged since autonomous mode must be disabled
to take effect. I'd say 7.2 just because of the missing lamparray. Merging in 7.1
has no downsides, yet IDK if putting in 7.1 violates some rule (probably yes?).
Please give a (very) quick read to the following link:
https://github.com/OpenGamingCollective/asusctl/issues/119#issuecomment-4723566635
This is something I am full of tickets for, probably we have reached the thousand
between discord, github and gitlab: very prominent issue and I'm eagerly waiting
for lamparray support to appear upstream.
Thanks,
Denis
> Thanks,
>
^ permalink raw reply
page: | 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