* Re: [PATCH 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Ping Cheng @ 2026-05-13 15:47 UTC (permalink / raw)
To: Lee Jones
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel, stable
In-Reply-To: <20260513075935.1715836-1-lee@kernel.org>
On Wed, May 13, 2026 at 1:05 AM Lee Jones <lee@kernel.org> wrote:
>
> wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
> usage is always located in the first field (field[0]) of the feature report.
> However, a device can specify HID_DG_INPUTMODE in a different field.
>
> If HID_DG_INPUTMODE is in a field other than the first one and the first
> field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
> this leads to an out-of-bounds write to r->field[0]->value.
>
> Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
> hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
> this stored field index to access the correct field and add bounds
> checks to ensure both the field index and the value index are within
> valid ranges before writing.
>
> Cc: stable@vger.kernel.org
> Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling")
> Signed-off-by: Lee Jones <lee@kernel.org>
Patch looks sensible to me. Thank you for your effort, Lee!
Tested-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Cheers,
Ping
> ---
> drivers/hid/wacom_sys.c | 13 ++++++++++---
> drivers/hid/wacom_wac.h | 1 +
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 1b1112772777..a6c5281afa06 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -341,6 +341,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
>
> hid_data->inputmode = field->report->id;
> hid_data->inputmode_index = usage->usage_index;
> + hid_data->inputmode_field_index = field->index;
> break;
>
> case HID_UP_DIGITIZER:
> @@ -556,9 +557,14 @@ static int wacom_hid_set_device_mode(struct hid_device *hdev)
>
> re = &(hdev->report_enum[HID_FEATURE_REPORT]);
> r = re->report_id_hash[hid_data->inputmode];
> - if (r) {
> - r->field[0]->value[hid_data->inputmode_index] = 2;
> - hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
> + if (r && hid_data->inputmode_field_index >= 0 &&
> + hid_data->inputmode_field_index < r->maxfield) {
> + struct hid_field *field = r->field[hid_data->inputmode_field_index];
> +
> + if (field && hid_data->inputmode_index < field->report_count) {
> + field->value[hid_data->inputmode_index] = 2;
> + hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
> + }
> }
> return 0;
> }
> @@ -2819,6 +2825,7 @@ static int wacom_probe(struct hid_device *hdev,
> return error;
>
> wacom_wac->hid_data.inputmode = -1;
> + wacom_wac->hid_data.inputmode_field_index = -1;
> wacom_wac->mode_report = -1;
>
> if (hid_is_usb(hdev)) {
> diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
> index c8803d5c6a71..b2e74d7ab3c4 100644
> --- a/drivers/hid/wacom_wac.h
> +++ b/drivers/hid/wacom_wac.h
> @@ -298,6 +298,7 @@ struct wacom_shared {
> struct hid_data {
> __s16 inputmode; /* InputMode HID feature, -1 if non-existent */
> __s16 inputmode_index; /* InputMode HID feature index in the report */
> + __s16 inputmode_field_index; /* InputMode HID feature field index in the report */
> bool sense_state;
> bool inrange_state;
> bool invert_state;
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS b7710233c16c1f42e0b58a1f0485658fc4fa61c1
From: kernel test robot @ 2026-05-13 14:37 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: b7710233c16c1f42e0b58a1f0485658fc4fa61c1 Input: atmel_mxt_ts - use __free() for obuf in mxt_object_show
elapsed time: 1225m
configs tested: 244
configs skipped: 14
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc nsimosci_defconfig gcc-15.2.0
arc randconfig-001-20260513 gcc-14.3.0
arc randconfig-002-20260513 gcc-14.3.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm gemini_defconfig clang-20
arm ixp4xx_defconfig gcc-15.2.0
arm randconfig-001-20260513 gcc-14.3.0
arm randconfig-002-20260513 gcc-14.3.0
arm randconfig-003-20260513 gcc-14.3.0
arm randconfig-004-20260513 gcc-14.3.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260513 clang-23
arm64 randconfig-001-20260513 gcc-12.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260513 clang-23
arm64 randconfig-002-20260513 gcc-12.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260513 clang-23
arm64 randconfig-003-20260513 gcc-12.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260513 clang-23
arm64 randconfig-004-20260513 gcc-12.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260513 clang-23
csky randconfig-001-20260513 gcc-12.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260513 clang-23
csky randconfig-002-20260513 gcc-12.5.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260513 gcc-11.5.0
hexagon randconfig-001-20260513 gcc-8.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260513 gcc-11.5.0
hexagon randconfig-002-20260513 gcc-8.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260513 clang-20
i386 buildonly-randconfig-002-20260513 clang-20
i386 buildonly-randconfig-003-20260513 clang-20
i386 buildonly-randconfig-004-20260513 clang-20
i386 buildonly-randconfig-005-20260513 clang-20
i386 buildonly-randconfig-006-20260513 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260513 clang-20
i386 randconfig-002-20260513 clang-20
i386 randconfig-003-20260513 clang-20
i386 randconfig-004-20260513 clang-20
i386 randconfig-005-20260513 clang-20
i386 randconfig-006-20260513 clang-20
i386 randconfig-007-20260513 clang-20
i386 randconfig-011-20260513 clang-20
i386 randconfig-012-20260513 clang-20
i386 randconfig-012-20260513 gcc-14
i386 randconfig-013-20260513 clang-20
i386 randconfig-014-20260513 clang-20
i386 randconfig-015-20260513 clang-20
i386 randconfig-016-20260513 clang-20
i386 randconfig-017-20260513 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260513 gcc-11.5.0
loongarch randconfig-001-20260513 gcc-8.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260513 gcc-11.5.0
loongarch randconfig-002-20260513 gcc-8.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k atari_defconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
mips maltaup_xpa_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260513 gcc-11.5.0
nios2 randconfig-001-20260513 gcc-8.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260513 gcc-11.5.0
nios2 randconfig-002-20260513 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260513 gcc-8.5.0
parisc randconfig-002-20260513 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc mpc832x_rdb_defconfig gcc-15.2.0
powerpc mpc834x_itx_defconfig clang-16
powerpc rainier_defconfig gcc-15.2.0
powerpc randconfig-001-20260513 gcc-8.5.0
powerpc randconfig-002-20260513 gcc-8.5.0
powerpc64 randconfig-001-20260513 gcc-8.5.0
powerpc64 randconfig-002-20260513 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260513 gcc-15.2.0
riscv randconfig-002-20260513 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260513 gcc-15.2.0
s390 randconfig-002-20260513 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh kfr2r09-romimage_defconfig gcc-15.2.0
sh randconfig-001-20260513 gcc-15.2.0
sh randconfig-002-20260513 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-11.5.0
sparc randconfig-001-20260513 gcc-11.5.0
sparc randconfig-002 gcc-11.5.0
sparc randconfig-002-20260513 gcc-11.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-11.5.0
sparc64 randconfig-001-20260513 gcc-11.5.0
sparc64 randconfig-002 gcc-11.5.0
sparc64 randconfig-002-20260513 gcc-11.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-11.5.0
um randconfig-001-20260513 gcc-11.5.0
um randconfig-002 gcc-11.5.0
um randconfig-002-20260513 gcc-11.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001 gcc-12
x86_64 buildonly-randconfig-001-20260513 gcc-12
x86_64 buildonly-randconfig-002 gcc-12
x86_64 buildonly-randconfig-002-20260513 gcc-12
x86_64 buildonly-randconfig-003 gcc-12
x86_64 buildonly-randconfig-003-20260513 gcc-12
x86_64 buildonly-randconfig-004 gcc-12
x86_64 buildonly-randconfig-004-20260513 gcc-12
x86_64 buildonly-randconfig-005 gcc-12
x86_64 buildonly-randconfig-005-20260513 gcc-12
x86_64 buildonly-randconfig-006 gcc-12
x86_64 buildonly-randconfig-006-20260513 gcc-12
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260513 clang-20
x86_64 randconfig-002-20260513 clang-20
x86_64 randconfig-003-20260513 clang-20
x86_64 randconfig-004-20260513 clang-20
x86_64 randconfig-005-20260513 clang-20
x86_64 randconfig-006-20260513 clang-20
x86_64 randconfig-011-20260513 gcc-14
x86_64 randconfig-012-20260513 gcc-14
x86_64 randconfig-013-20260513 gcc-14
x86_64 randconfig-014-20260513 gcc-14
x86_64 randconfig-015-20260513 gcc-14
x86_64 randconfig-016-20260513 gcc-14
x86_64 randconfig-071-20260513 gcc-14
x86_64 randconfig-072-20260513 gcc-14
x86_64 randconfig-073-20260513 gcc-14
x86_64 randconfig-074-20260513 gcc-14
x86_64 randconfig-075-20260513 gcc-14
x86_64 randconfig-076-20260513 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001 gcc-11.5.0
xtensa randconfig-001-20260513 gcc-11.5.0
xtensa randconfig-002 gcc-11.5.0
xtensa randconfig-002-20260513 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: Lee Jones @ 2026-05-13 14:05 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pavel Machek, David Lechner, Tony Lindgren, linux-input,
devicetree, linux-kernel, linux-leds
In-Reply-To: <CAPVz0n1Ubvj9MHHMcM2BpxAcTCCheMihr3aJUqcDVoi_V0OQ5g@mail.gmail.com>
On Thu, 07 May 2026, Svyatoslav Ryhel wrote:
> чт, 7 трав. 2026 р. о 17:05 Lee Jones <lee@kernel.org> пише:
> >
> > On Tue, 28 Apr 2026, Svyatoslav Ryhel wrote:
> >
> > > MFD have rigid subdevice structure which does not allow flexible dynamic
> > > subdevice linking. Address this by diverging CPCAP subdevice composition
> > > to take into account board specific configuration.
> > >
> > > Create a common default subdevice composition, rename existing subdevice
> > > composition into cpcap_mapphone_mfd_devices since it targets mainly
> > > Mapphone board.
> > >
> > > Removed st,6556002 as it is no longer applicable to all cases and
> > > duplicates motorola,cpcap, which is used as the default composition.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> >
> > Changelog?
> >
>
> Changelog is in the cover.
>
> > > drivers/mfd/motorola-cpcap.c | 101 ++++++++++++++++++++++++++++-------
> > > 1 file changed, 83 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> > > index d8243b956f87..516d1e33affa 100644
> > > --- a/drivers/mfd/motorola-cpcap.c
> > > +++ b/drivers/mfd/motorola-cpcap.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/kernel.h>
> > > #include <linux/module.h>
> > > #include <linux/mod_devicetable.h>
> > > +#include <linux/property.h>
> > > #include <linux/regmap.h>
> > > #include <linux/sysfs.h>
> > >
> > > @@ -24,10 +25,16 @@
> > > #define CPCAP_REGISTER_SIZE 4
> > > #define CPCAP_REGISTER_BITS 16
> > >
> > > +struct cpcap_chip_data {
> > > + const struct mfd_cell *mfd_devices;
> > > + unsigned int num_devices;
> > > +};
> >
> > This is a red flag.
> >
> > > struct cpcap_ddata {
> > > struct spi_device *spi;
> > > struct regmap_irq *irqs;
> > > struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
> > > + const struct cpcap_chip_data *cdata;
> > > const struct regmap_config *regmap_conf;
> > > struct regmap *regmap;
> > > };
> > > @@ -195,20 +202,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
> > > return 0;
> > > }
> > >
> > > -static const struct of_device_id cpcap_of_match[] = {
> > > - { .compatible = "motorola,cpcap", },
> > > - { .compatible = "st,6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(of, cpcap_of_match);
> > > -
> > > -static const struct spi_device_id cpcap_spi_ids[] = {
> > > - { .name = "cpcap", },
> > > - { .name = "6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
> > > -
> > > static const struct regmap_config cpcap_regmap_config = {
> > > .reg_bits = 16,
> > > .reg_stride = 4,
> > > @@ -241,7 +234,56 @@ static int cpcap_resume(struct device *dev)
> > >
> > > static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
> > >
> > > -static const struct mfd_cell cpcap_mfd_devices[] = {
> > > +static const struct mfd_cell cpcap_default_mfd_devices[] = {
> > > + {
> > > + .name = "cpcap_adc",
> > > + .of_compatible = "motorola,cpcap-adc",
> > > + }, {
> > > + .name = "cpcap_battery",
> > > + .of_compatible = "motorola,cpcap-battery",
> > > + }, {
> > > + .name = "cpcap-regulator",
> > > + .of_compatible = "motorola,cpcap-regulator",
> > > + }, {
> > > + .name = "cpcap-rtc",
> > > + .of_compatible = "motorola,cpcap-rtc",
> > > + }, {
> > > + .name = "cpcap-pwrbutton",
> > > + .of_compatible = "motorola,cpcap-pwrbutton",
> > > + }, {
> > > + .name = "cpcap-usb-phy",
> > > + .of_compatible = "motorola,cpcap-usb-phy",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 0,
> > > + .of_compatible = "motorola,cpcap-led-red",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 1,
> > > + .of_compatible = "motorola,cpcap-led-green",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 2,
> > > + .of_compatible = "motorola,cpcap-led-blue",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 3,
> > > + .of_compatible = "motorola,cpcap-led-adl",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 4,
> > > + .of_compatible = "motorola,cpcap-led-cp",
> > > + }, {
> > > + .name = "cpcap-codec",
> > > + },
> > > +};
> > > +
> > > +static const struct cpcap_chip_data cpcap_default_data = {
> > > + .mfd_devices = cpcap_default_mfd_devices,
> > > + .num_devices = ARRAY_SIZE(cpcap_default_mfd_devices),
> > > +};
> > > +
> > > +static const struct mfd_cell cpcap_mapphone_mfd_devices[] = {
> > > {
> > > .name = "cpcap_adc",
> > > .of_compatible = "motorola,mapphone-cpcap-adc",
> > > @@ -285,7 +327,12 @@ static const struct mfd_cell cpcap_mfd_devices[] = {
> > > .of_compatible = "motorola,cpcap-led-cp",
> > > }, {
> > > .name = "cpcap-codec",
> > > - }
> > > + },
> > > +};
> > > +
> > > +static const struct cpcap_chip_data cpcap_mapphone_data = {
> > > + .mfd_devices = cpcap_mapphone_mfd_devices,
> > > + .num_devices = ARRAY_SIZE(cpcap_mapphone_mfd_devices),
> > > };
> > >
> > > static int cpcap_probe(struct spi_device *spi)
> > > @@ -297,9 +344,17 @@ static int cpcap_probe(struct spi_device *spi)
> > > if (!cpcap)
> > > return -ENOMEM;
> > >
> > > + cpcap->cdata = device_get_match_data(&spi->dev);
> > > + if (!cpcap->cdata)
> > > + return -ENODEV;
> > > +
> > > cpcap->spi = spi;
> > > spi_set_drvdata(spi, cpcap);
> > >
> > > @@ -331,16 +382,24 @@ static int cpcap_probe(struct spi_device *spi)
> > > spi->dev.coherent_dma_mask = 0;
> > > spi->dev.dma_mask = &spi->dev.coherent_dma_mask;
> > >
> > > - return devm_mfd_add_devices(&spi->dev, 0, cpcap_mfd_devices,
> > > - ARRAY_SIZE(cpcap_mfd_devices), NULL, 0, NULL);
> > > + return devm_mfd_add_devices(&spi->dev, 0, cpcap->cdata->mfd_devices,
> > > + cpcap->cdata->num_devices, NULL, 0, NULL);
> > > }
> > >
> > > +static const struct of_device_id cpcap_of_match[] = {
> > > + { .compatible = "motorola,cpcap", .data = &cpcap_default_data },
> > > + { .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
> >
> > We don't allow data from one device registration API (MFD) to be passed
> > through another (OF) because it tends to lead to all sorts of "creative
> > solutions". Pass a value instead and match on that in a switch()
> > statement like all of the other MFD drivers do.
> >
>
> You don't allow this. I have not seen this enforced anywhere in the
> kernel except the mfd subsystem. Fine, does not matter, if this makes
> you happy I will adjust.
Where else would this rule be applicable? I can't think of anywhere.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v4 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: Lee Jones @ 2026-05-13 14:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pavel Machek, David Lechner, Tony Lindgren, linux-input,
devicetree, linux-kernel, linux-leds
In-Reply-To: <CAPVz0n24U3=hwda5BTXUhHiiFHKmWUfLy_nxJp_CFHBHEYDWsA@mail.gmail.com>
On Thu, 07 May 2026, Svyatoslav Ryhel wrote:
> чт, 7 трав. 2026 р. о 17:05 Lee Jones <lee@kernel.org> пише:
> >
> > On Tue, 28 Apr 2026, Svyatoslav Ryhel wrote:
> >
> > > MFD have rigid subdevice structure which does not allow flexible dynamic
> > > subdevice linking. Address this by diverging CPCAP subdevice composition
> > > to take into account board specific configuration.
> > >
> > > Create a common default subdevice composition, rename existing subdevice
> > > composition into cpcap_mapphone_mfd_devices since it targets mainly
> > > Mapphone board.
> > >
> > > Removed st,6556002 as it is no longer applicable to all cases and
> > > duplicates motorola,cpcap, which is used as the default composition.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> >
> > Changelog?
> >
> > > drivers/mfd/motorola-cpcap.c | 101 ++++++++++++++++++++++++++++-------
> > > 1 file changed, 83 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> > > index d8243b956f87..516d1e33affa 100644
> > > --- a/drivers/mfd/motorola-cpcap.c
> > > +++ b/drivers/mfd/motorola-cpcap.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/kernel.h>
> > > #include <linux/module.h>
> > > #include <linux/mod_devicetable.h>
> > > +#include <linux/property.h>
> > > #include <linux/regmap.h>
> > > #include <linux/sysfs.h>
> > >
> > > @@ -24,10 +25,16 @@
> > > #define CPCAP_REGISTER_SIZE 4
> > > #define CPCAP_REGISTER_BITS 16
> > >
> > > +struct cpcap_chip_data {
> > > + const struct mfd_cell *mfd_devices;
> > > + unsigned int num_devices;
> > > +};
> >
> > This is a red flag.
> >
> > > struct cpcap_ddata {
> > > struct spi_device *spi;
> > > struct regmap_irq *irqs;
> > > struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
> > > + const struct cpcap_chip_data *cdata;
> > > const struct regmap_config *regmap_conf;
> > > struct regmap *regmap;
> > > };
> > > @@ -195,20 +202,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
> > > return 0;
> > > }
> > >
> > > -static const struct of_device_id cpcap_of_match[] = {
> > > - { .compatible = "motorola,cpcap", },
> > > - { .compatible = "st,6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(of, cpcap_of_match);
> > > -
> > > -static const struct spi_device_id cpcap_spi_ids[] = {
> > > - { .name = "cpcap", },
> > > - { .name = "6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
> > > -
> > > static const struct regmap_config cpcap_regmap_config = {
> > > .reg_bits = 16,
> > > .reg_stride = 4,
> > > @@ -241,7 +234,56 @@ static int cpcap_resume(struct device *dev)
> > >
> > > static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
> > >
> > > -static const struct mfd_cell cpcap_mfd_devices[] = {
> > > +static const struct mfd_cell cpcap_default_mfd_devices[] = {
> > > + {
> > > + .name = "cpcap_adc",
> > > + .of_compatible = "motorola,cpcap-adc",
> > > + }, {
> > > + .name = "cpcap_battery",
> > > + .of_compatible = "motorola,cpcap-battery",
> > > + }, {
> > > + .name = "cpcap-regulator",
> > > + .of_compatible = "motorola,cpcap-regulator",
> > > + }, {
> > > + .name = "cpcap-rtc",
> > > + .of_compatible = "motorola,cpcap-rtc",
> > > + }, {
> > > + .name = "cpcap-pwrbutton",
> > > + .of_compatible = "motorola,cpcap-pwrbutton",
> > > + }, {
> > > + .name = "cpcap-usb-phy",
> > > + .of_compatible = "motorola,cpcap-usb-phy",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 0,
> > > + .of_compatible = "motorola,cpcap-led-red",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 1,
> > > + .of_compatible = "motorola,cpcap-led-green",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 2,
> > > + .of_compatible = "motorola,cpcap-led-blue",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 3,
> > > + .of_compatible = "motorola,cpcap-led-adl",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 4,
> > > + .of_compatible = "motorola,cpcap-led-cp",
> > > + }, {
> > > + .name = "cpcap-codec",
> > > + },
> > > +};
>
> Lee, would you mind if I convert these mfd_cell structures to use
> macros in this commit since I am refactoring them anyway?
Sure.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH RESEND 2] HID: Add force feedback support for Speedlink Cougar Vibration Flightstick
From: Harald Judt @ 2026-05-13 13:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <af5tJlRJr_GFTjVH@google.com>
Hi,
Am 09.05.26 um 01:14 schrieb Dmitry Torokhov:
[ ... ]
>>> + strong = (strong / 0xff) * 0x1f / 0xff;
>>> + weak = (weak / 0xff) * 0x1f / 0xff;
>>> +
>>> + /* ... and to support the notions of strong vs weak rumble effects,
>>> + * increase the magnitude for the strong rumble effect if it is below the
>>> + * half of the maximum value, as the strong motor has the same strength as
>>> + * the weak one. Likewise, decrease the magnitude for the weak effect.
>>> + */
>>> + if (strong < 0x10 && !weak) /* fftest effect 4 strong rumble */
>>> + strong *= 2;
>>> + else if (!strong && weak >= 0x10) /* fftest effect 5 weak rumble */
>>> + weak /= 2;
>>
>> Will this cause issues with non-monotonic force feedback behavior and
>> unintended truncation?
I thought about this too. I have not experienced any negative behavior with
this solution, the stick seems to work fine with it. But honestly, there
are not many tests available. fftest and SuperTuxKart have been the only
applications I found supporting force feedback, it worked fine there,
but the stick is also a bit limited in capabilities, it does not really
support "force feedback", only some degrees of rumble.
Since I wrote this patch some time passed and I have gained a bit more
experience with force feedback in general and implementing support for it.
>> Since the math uses integer division, any input value below 255 for strong
>> or weak will evaluate to zero during the first division by 0xff.
I am aware of this but IIRC this does not have any practical impact for
this stick. It seems to correspond to the values I got from the SET_REPORTs
in Windows and the vibrating behaviour.
>> Additionally, could the conditional scaling cause abrupt changes in rumble
>> strength? For instance, if a game requests a strong magnitude that scales
>> down to 15, it gets doubled to 30 because of the strong < 0x10 check.
>> However, a slightly stronger requested magnitude that scales to 16 will
>> remain 16, meaning an increase in requested strength results in a drop in
>> physical rumble.
True. I have tested this only with fftest and observed the behaviour in
SuperTuxKart, where it worked fine, as it uses both strong and weak
attributes. Existing implementations for other devices in the kernel
source I found sometimes use a "left" motor and a "right" motor,
other times a "strong" motor and a "weak" motor. But the games do a
variation of strong vs weak. So I finally decided to somehow get it
to work with the game I could test it with. I will do more checks
with other parameters/gain and try to improve this or think about
another, better solution. I might probably need to write some
ff tests myself for this, but why not...
>> [ ... ]
>>
>>> +static int gembird_joy_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>> +{
>>> + int ret;
>>> +
>>> + ret = hid_parse(hdev);
>>> + if (ret) {
>>> + hid_err(hdev, "parse failed\n");
>>> + return ret;
>>> + }
>>> +
>>> + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT & ~HID_CONNECT_FF);
>>> + if (ret) {
>>> + hid_err(hdev, "hw start failed\n");
>>> + return ret;
>>> + }
>>> +
>>> + gembird_joy_init(hdev);
>>> +
>>> + return 0;
>>> +}
>>
>> What happens if gembird_joy_init fails?
>>
>> If input_ff_create_memless returns an error, gembird_joy_init
>> propagates it, but the return value is ignored here and probe succeeds.
>>
>> Because set_bit(FF_RUMBLE, dev->ffbit) was already called, the device
>> remains registered and advertises rumble support. If userspace then issues
>> an EVIOCSFF ioctl, the kernel will allow it, which could lead to a panic
>> when it tries to dereference the missing force feedback structures.
>
> Need to have error handling.
I have looked at some other implementations, and if I have not missed
anything, then they do it similarly (hid-gaff.c, hid-sjoy.c, hid-emsff.c,
hid-megaworld.c). I will take a closer look again and try to fix it.
> Thanks.
Thank you for your suggestions and spending your time on this review.
I will try to improve it and send a new patch when ready.
Regards,
Harald
--
`Experience is the best teacher.'
PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD
^ permalink raw reply
* Re: [PATCH v2] HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification
From: Dave Carey @ 2026-05-13 12:57 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, bentiss
In-Reply-To: <364r776o-6771-o29n-8ss3-857n32071op7@xreary.bet>
It's pretty rad. Have one more patch coming in a bit to fix a trailing
ghost touch issue.
On 5/12/26 11:39 AM, Jiri Kosina wrote:
> On Mon, 13 Apr 2026, Dave Carey wrote:
>
>> The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a
>> HID_DG_TOUCHPAD application collection designed for the Windows inbox HID
>> driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN
>> collections provide the correct direct-touch interface. The presence of
>> the touchpad collection causes hid-multitouch to misclassify the
>> touchscreen nodes as indirect buttonpads, leaving them non-functional.
>>
>> Within the touchpad collection:
>> - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic
>> that sets INPUT_MT_POINTER on the touchscreen applications.
>> - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via
>> mt_allocate_application(), propagating to all touchscreen nodes.
>> - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD,
>> setting td->is_buttonpad = true for the entire device.
>>
>> Additionally, the firmware resets if any USB control request arrives while
>> the CDC-ACM interface is initialising (~1.18 s after enumeration).
>> The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature
>> reports in the touchscreen collections trigger GET_REPORT calls at probe
>> that hit this window. Surface Switch (0x57) and Button Switch (0x58)
>> feature reports are sent by mt_set_modes() on every input-device open and
>> close, repeatedly hitting this window throughout device lifetime.
>>
>> The firmware also leaves a persistent ghost contact in its contact buffer
>> (contact ID 2, fixed coordinates, tip always asserted) on every enumeration.
>> This ghost occupies a multitouch slot and prevents KWin from seeing a clean
>> finger-lift, causing stuck touch state. The ghost is cleared when Input
>> Mode is set via HID_REQ_SET_REPORT at probe.
> Oh man, what a device.
> Applied, thanks.
>
^ permalink raw reply
* Re: [PATCH RESEND 2] HID: Add force feedback support for Speedlink Cougar Vibration Flightstick
From: Harald Judt @ 2026-05-13 12:00 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <1q46pn22-177p-9no9-q4p7-4qq8n38po504@xreary.bet>
Hi,
Thanks for reviewing this.
Am 12.05.26 um 18:11 schrieb Jiri Kosina:
> On Fri, 8 May 2026, Harald Judt wrote:
[...]
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 04420a713be0..b4e2c8f67728 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -406,6 +406,14 @@ config HID_GEMBIRD
>> help
>> Support for Gembird JPD-DualForce 2.
>>
>> +config HID_GEMBIRD_JOY_FF
>> + tristate "Gembird Joysticks force feedback support"
>> + depends on USB_HID
>> + select INPUT_FF_MEMLESS
>> + help
>> + Force feedback support for Gembird (Vendor ID 0x12bd) based devices:
>> + - Speed Link Cougar Vibration Flightstick (SL-6630)
>> +
>> config HID_GFRM
>> tristate "Google Fiber TV Box remote control support"
>> help
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index 361a7daedeb8..593a429661ed 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -54,6 +54,7 @@ obj-$(CONFIG_HID_EVISION) += hid-evision.o
>> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
>> obj-$(CONFIG_HID_FT260) += hid-ft260.o
>> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
>> +obj-$(CONFIG_HID_GEMBIRD_JOY_FF) += hid-gembird-joy.o
>
> Would it be possible to link this support to hid-gembird if enabled?
The problem I encountered is that gembird != gembird, that is,
the USB Vendor IDs differ. These are defined:
#define USB_VENDOR_ID_GEMBIRD 0x11ff
#define USB_DEVICE_ID_GEMBIRD_JPD_DUALFORCE2 0x3331
#define USB_VENDOR_ID_GEMBIRD_JOY 0x12bd
#define USB_DEVICE_ID_GEMBIRD_JOY_SL_6630 0xa02f
What would be the best way to solve this? Can my implementation
reside in separate files or should it be integrated into the
existing hid-gembird implementation? I am pretty new to
writing kernel modules, and doing it separately simply seemed
more suited for an easier start...
Regards,
Harald
--
`Experience is the best teacher.'
PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD
^ permalink raw reply
* [PATCH 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Lee Jones @ 2026-05-13 7:59 UTC (permalink / raw)
To: lee, Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
Cc: stable
wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
usage is always located in the first field (field[0]) of the feature report.
However, a device can specify HID_DG_INPUTMODE in a different field.
If HID_DG_INPUTMODE is in a field other than the first one and the first
field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
this leads to an out-of-bounds write to r->field[0]->value.
Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
this stored field index to access the correct field and add bounds
checks to ensure both the field index and the value index are within
valid ranges before writing.
Cc: stable@vger.kernel.org
Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling")
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/wacom_sys.c | 13 ++++++++++---
drivers/hid/wacom_wac.h | 1 +
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 1b1112772777..a6c5281afa06 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -341,6 +341,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
hid_data->inputmode = field->report->id;
hid_data->inputmode_index = usage->usage_index;
+ hid_data->inputmode_field_index = field->index;
break;
case HID_UP_DIGITIZER:
@@ -556,9 +557,14 @@ static int wacom_hid_set_device_mode(struct hid_device *hdev)
re = &(hdev->report_enum[HID_FEATURE_REPORT]);
r = re->report_id_hash[hid_data->inputmode];
- if (r) {
- r->field[0]->value[hid_data->inputmode_index] = 2;
- hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
+ if (r && hid_data->inputmode_field_index >= 0 &&
+ hid_data->inputmode_field_index < r->maxfield) {
+ struct hid_field *field = r->field[hid_data->inputmode_field_index];
+
+ if (field && hid_data->inputmode_index < field->report_count) {
+ field->value[hid_data->inputmode_index] = 2;
+ hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
+ }
}
return 0;
}
@@ -2819,6 +2825,7 @@ static int wacom_probe(struct hid_device *hdev,
return error;
wacom_wac->hid_data.inputmode = -1;
+ wacom_wac->hid_data.inputmode_field_index = -1;
wacom_wac->mode_report = -1;
if (hid_is_usb(hdev)) {
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index c8803d5c6a71..b2e74d7ab3c4 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -298,6 +298,7 @@ struct wacom_shared {
struct hid_data {
__s16 inputmode; /* InputMode HID feature, -1 if non-existent */
__s16 inputmode_index; /* InputMode HID feature index in the report */
+ __s16 inputmode_field_index; /* InputMode HID feature field index in the report */
bool sense_state;
bool inrange_state;
bool invert_state;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH] Input: elan_i2c - prevent division by zero on invalid device parameters
From: Ranjan Kumar @ 2026-05-13 7:39 UTC (permalink / raw)
To: dmitry.torokhov
Cc: bleung, dusonlin, bentiss, linux-input, linux-kernel,
Ranjan Kumar
The Elan I2C touchpad driver queries the device for its physical
dimensions and trace counts to calculate the device resolution and width.
However, if the device firmware or device tree provides invalid zero
values for x_traces, y_traces, x_mm, or y_mm, it results in a fatal
division-by-zero exception leading to a kernel panic during device probe.
Add sanity checks to ensure these physical parameters are non-zero
before performing the division. If invalid values are detected, log an
error and return -EINVAL to gracefully abort the initialization and
maintain system stability.
Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad")
Fixes: e3a9a1290688 ("Input: elan_i2c - do not query the info if they are provided")
Signed-off-by: Ranjan Kumar <kumarranja@chromium.org>
---
drivers/input/mouse/elan_i2c_core.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index fee1796da3d0..b5fd63928afd 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -425,6 +425,14 @@ static int elan_query_device_parameters(struct elan_tp_data *data)
if (error)
return error;
}
+
+ if (unlikely(x_traces == 0 || y_traces == 0)) {
+ dev_err(&client->dev,
+ "Invalid trace numbers: x=%u, y=%u\n",
+ x_traces, y_traces);
+ return -EINVAL;
+ }
+
data->width_x = data->max_x / x_traces;
data->width_y = data->max_y / y_traces;
@@ -440,6 +448,14 @@ static int elan_query_device_parameters(struct elan_tp_data *data)
data->x_res = elan_convert_resolution(hw_x_res, data->pattern);
data->y_res = elan_convert_resolution(hw_y_res, data->pattern);
} else {
+
+ if (unlikely(x_mm == 0 || y_mm == 0)) {
+ dev_err(&client->dev,
+ "Invalid physical dimensions: x_mm=%u, y_mm=%u\n",
+ x_mm, y_mm);
+ return -EINVAL;
+ }
+
data->x_res = (data->max_x + 1) / x_mm;
data->y_res = (data->max_y + 1) / y_mm;
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH] HID: mcp2221: Fix heap buffer overflow in mcp2221_raw_event()
From: Benoît Sevens @ 2026-05-13 7:22 UTC (permalink / raw)
To: Jiri Kosina
Cc: Rishi Gupta, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel
In-Reply-To: <417rqoq0-1q2q-r96q-p258-240n74nr3n14@xreary.bet>
On Tue, 12 May 2026 at 17:47, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Wed, 15 Apr 2026, Benoit Sevens wrote:
>
> > From: Benoît Sevens <bsevens@google.com>
> >
> > A heap buffer overflow can occur in the mcp2221_raw_event() function
> > when handling I2C read responses. The driver failed to check if the
> > total incoming data length fits within the originally allocated buffer
> > `mcp->rxbuf`.
> >
> > Fix this by introducing `rxbuf_len` to `struct mcp2221` to keep track
> > of the allocated buffer size. Initialize it in `mcp_i2c_smbus_read()`
> > and `mcp_smbus_xfer()`, and ensure the copied data length combined with
> > the current index does not exceed this length in `mcp2221_raw_event()`.
> >
> > Signed-off-by: Benoît Sevens <bsevens@google.com>
>
> Unfortunately the patch seems to have been somehow mangled by your mail
> client:
>
> patching file drivers/hid/hid-mcp2221.c
> Hunk #1 succeeded at 126 (offset 7 lines).
> Hunk #2 FAILED at 324.
> patch: **** malformed patch at line 173: u16 addr,
>
> Fix for the same issue has later been submitted by Florian Pradines [1],
> so I will be taking that one and adding you as Reported-by: or so, ok?
>
> Thanks.
>
> [1] https://lore.kernel.org/all/20260509094517.2691246-1-florian.pradines@gmail.com/
>
> --
> Jiri Kosina
> SUSE Labs
>
Hi Jiri,
That sounds good to me. Thanks for adding me in the Reported-by
One thing though: Florian's patch doesn't set `mcp->rxbuf_size` in all
places. I believe it should be set in every place where `mcp->rxbuf`
is set. There are 2 places in `mcp_smbus_xfer` where it is missing
(see my original patch):
```c
@@ -538,6 +541,7 @@ static int mcp_smbus_xfer(struct i2c_adapter
*adapter, u16 addr,
mcp->rxbuf_idx = 0;
mcp->rxbuf = data->block;
+ mcp->rxbuf_size = sizeof(data->block);
mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
if (ret)
@@ -561,6 +565,7 @@ static int mcp_smbus_xfer(struct i2c_adapter
*adapter, u16 addr,
mcp->rxbuf_idx = 0;
mcp->rxbuf = data->block;
+ mcp->rxbuf_size = sizeof(data->block);
mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
if (ret)
```
Thanks,
Benoit
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 6f89d96fff65aec1ff12bc566fca0eb1bb59e16e
From: kernel test robot @ 2026-05-13 7:09 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 6f89d96fff65aec1ff12bc566fca0eb1bb59e16e Input: atlas - check ACPI_COMPANION() against NULL
elapsed time: 778m
configs tested: 212
configs skipped: 9
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260513 gcc-14.3.0
arc randconfig-002-20260513 gcc-14.3.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm gemini_defconfig clang-20
arm randconfig-001-20260513 gcc-14.3.0
arm randconfig-002-20260513 gcc-14.3.0
arm randconfig-003-20260513 gcc-14.3.0
arm randconfig-004-20260513 gcc-14.3.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260513 clang-23
arm64 randconfig-001-20260513 gcc-12.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260513 clang-23
arm64 randconfig-002-20260513 gcc-12.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260513 clang-23
arm64 randconfig-003-20260513 gcc-12.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260513 clang-23
arm64 randconfig-004-20260513 gcc-12.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260513 clang-23
csky randconfig-001-20260513 gcc-12.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260513 clang-23
csky randconfig-002-20260513 gcc-12.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260513 gcc-8.5.0
hexagon randconfig-002-20260513 gcc-8.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260513 clang-20
i386 buildonly-randconfig-002-20260513 clang-20
i386 buildonly-randconfig-003-20260513 clang-20
i386 buildonly-randconfig-004-20260513 clang-20
i386 buildonly-randconfig-005-20260513 clang-20
i386 buildonly-randconfig-006-20260513 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260513 clang-20
i386 randconfig-002-20260513 clang-20
i386 randconfig-003-20260513 clang-20
i386 randconfig-004-20260513 clang-20
i386 randconfig-005-20260513 clang-20
i386 randconfig-006-20260513 clang-20
i386 randconfig-007-20260513 clang-20
i386 randconfig-011-20260513 clang-20
i386 randconfig-012-20260513 clang-20
i386 randconfig-012-20260513 gcc-14
i386 randconfig-013-20260513 clang-20
i386 randconfig-014-20260513 clang-20
i386 randconfig-015-20260513 clang-20
i386 randconfig-016-20260513 clang-20
i386 randconfig-017-20260513 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260513 gcc-8.5.0
loongarch randconfig-002-20260513 gcc-8.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k atari_defconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips maltaup_xpa_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260513 gcc-8.5.0
nios2 randconfig-002-20260513 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260513 gcc-8.5.0
parisc randconfig-002-20260513 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc mpc834x_itx_defconfig clang-16
powerpc rainier_defconfig gcc-15.2.0
powerpc randconfig-001-20260513 gcc-8.5.0
powerpc randconfig-002-20260513 gcc-8.5.0
powerpc64 randconfig-001-20260513 gcc-8.5.0
powerpc64 randconfig-002-20260513 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260513 gcc-15.2.0
riscv randconfig-002-20260513 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260513 gcc-15.2.0
s390 randconfig-002-20260513 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260513 gcc-15.2.0
sh randconfig-002-20260513 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260513 gcc-11.5.0
sparc randconfig-002-20260513 gcc-11.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260513 gcc-11.5.0
sparc64 randconfig-002-20260513 gcc-11.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260513 gcc-11.5.0
um randconfig-002-20260513 gcc-11.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260513 gcc-12
x86_64 buildonly-randconfig-002-20260513 gcc-12
x86_64 buildonly-randconfig-003-20260513 gcc-12
x86_64 buildonly-randconfig-004-20260513 gcc-12
x86_64 buildonly-randconfig-005-20260513 gcc-12
x86_64 buildonly-randconfig-006-20260513 gcc-12
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260513 clang-20
x86_64 randconfig-002-20260513 clang-20
x86_64 randconfig-003-20260513 clang-20
x86_64 randconfig-004-20260513 clang-20
x86_64 randconfig-005-20260513 clang-20
x86_64 randconfig-006-20260513 clang-20
x86_64 randconfig-011-20260513 gcc-14
x86_64 randconfig-012-20260513 gcc-14
x86_64 randconfig-013-20260513 gcc-14
x86_64 randconfig-014-20260513 gcc-14
x86_64 randconfig-015-20260513 gcc-14
x86_64 randconfig-016-20260513 gcc-14
x86_64 randconfig-071-20260513 gcc-14
x86_64 randconfig-072-20260513 gcc-14
x86_64 randconfig-073-20260513 gcc-14
x86_64 randconfig-074-20260513 gcc-14
x86_64 randconfig-075-20260513 gcc-14
x86_64 randconfig-076-20260513 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260513 gcc-11.5.0
xtensa randconfig-002-20260513 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] HID: google: hammer: stop hardware on devres action failure
From: Myeonghun Pak @ 2026-05-13 6:52 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <42o9po52-64po-n8o8-or3q-q439o09s2p0p@xreary.bet>
Dear Jiri,
Thanks for applying the patch.
Best regards,
Myeonghun
2026년 5월 13일 (수) 오전 1:01, Jiri Kosina <jikos@kernel.org>님이 작성:
>
> On Fri, 24 Apr 2026, 박명훈 wrote:
>
> > From: Myeonghun Pak <mhun512@gmail.com>
> >
> > hammer_probe() starts the HID hardware before registering the devres
> > action that stops it. If devm_add_action() fails, probe returns an
> > error with the hardware still started because the cleanup action was
> > never registered and the driver's remove callback is not called after a
> > failed probe.
> >
> > Use devm_add_action_or_reset() so the stop action runs immediately on
> > registration failure while preserving the existing devres-managed cleanup
> > path for later probe failures and remove.
> >
> > Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> > ---
> > drivers/hid/hid-google-hammer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> > index 1af477e584..c99c3c0d44 100644
> > --- a/drivers/hid/hid-google-hammer.c
> > +++ b/drivers/hid/hid-google-hammer.c
> > @@ -496,7 +496,7 @@ static int hammer_probe(struct hid_device *hdev,
> > if (error)
> > return error;
> >
> > - error = devm_add_action(&hdev->dev, hammer_stop, hdev);
> > + error = devm_add_action_or_reset(&hdev->dev, hammer_stop, hdev);
>
> Makes sense, thanks for catching it. Applied.
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* [PATCH] Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490
From: contacto @ 2026-05-13 4:57 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Nicolás Bazaes
From: Nicolás Bazaes <contacto@bazaes.cl>
The Lenovo ThinkPad E490 (PNP ID: LEN2058) has a Synaptics TM3471-020
touchpad that supports SMBus/RMI4 mode but is not listed in
smbus_pnp_ids[]. Without this entry, psmouse ignores the
synaptics_intertouch parameter and falls back to PS/2 mode even when
explicitly requested.
Adding LEN2058 to the passlist enables RMI4 over SMBus, which provides
better multitouch support and matches the behavior of similar ThinkPad
models already in the list (E480/LEN2054, E580/LEN2055).
Tested on ThinkPad E490 with kernel 7.0.5-zen1 and Arch Linux.
Signed-off-by: Nicolás Bazaes <contacto@bazaes.cl>
Assisted-by: Claude <claude.ai>
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 26071128f..c70502e24 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -190,6 +190,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN2044", /* L470 */
"LEN2054", /* E480 */
"LEN2055", /* E580 */
+ "LEN2058", /* E490 */
"LEN2068", /* T14 Gen 1 */
"SYN1221", /* TUXEDO InfinityBook Pro 14 v5 */
"SYN3003", /* HP EliteBook 850 G1 */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 6/6] iio: pressure: HID: hid-sensor-press: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:30 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-7-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The struct iio_scan_type compound literal uses a non-existent field `.format` instead of `.sign`.
--
commit a042b8c22df5e0522e82213c0d6f025b115babe7
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: pressure: HID: hid-sensor-press: Refactor channel initialization
This commit refactors the initialization of the pressure sensor's scan_type
by replacing a local helper function with a compound literal to improve
code readability.
> diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
> index 5f1d6abda3e40..a039b99d9851d 100644
> --- a/drivers/iio/pressure/hid-sensor-press.c
> +++ b/drivers/iio/pressure/hid-sensor-press.c
[ ... ]
> @@ -225,8 +215,11 @@ static int press_parse_report(struct platform_device *pdev,
> &st->press_attr);
> if (ret < 0)
> return ret;
> - press_adjust_channel_bit_mask(channels, CHANNEL_SCAN_INDEX_PRESSURE,
> - st->press_attr.size);
> + channels[CHANNEL_SCAN_INDEX_PRESSURE].scan_type = (struct iio_scan_type) {
> + .format = 's',
Is .format correct here? Looking at struct iio_scan_type in
include/linux/iio/iio.h, it appears the member for indicating the sign is
named .sign, not .format.
Could this assignment cause a compilation error due to a missing member?
> + .realbits = BYTES_TO_BITS(st->press_attr.size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
>
> dev_dbg(&pdev->dev, "press %x:%x\n", st->press_attr.index,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=6
^ permalink raw reply
* RE: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Zhang, Lixu @ 2026-05-13 3:27 UTC (permalink / raw)
To: Jonathan Cameron, Natália Salvino André
Cc: andy@kernel.org, Lechner, David, jikos@kernel.org,
nuno.sa@analog.com, srinivas.pandruvada@linux.intel.com,
linux-iio@vger.kernel.org, linux-input@vger.kernel.org
In-Reply-To: <20260512154853.10aa2902@jic23-huawei>
>-----Original Message-----
>From: Jonathan Cameron <jic23@kernel.org>
>Sent: Tuesday, May 12, 2026 10:49 PM
>To: Natália Salvino André <natalia.andre@ime.usp.br>
>Cc: andy@kernel.org; Lechner, David <dlechner@baylibre.com>;
>jikos@kernel.org; nuno.sa@analog.com; srinivas.pandruvada@linux.intel.com;
>linux-iio@vger.kernel.org; linux-input@vger.kernel.org; Zhang, Lixu
><lixu.zhang@intel.com>
>Subject: Re: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
>
>On Mon, 11 May 2026 22:16:16 -0300
>Natália Salvino André <natalia.andre@ime.usp.br> wrote:
>
>> This series refactors the HID sensor drivers to standardize the
>> initialization of the iio_chan_spec scan_type structure.
>> Direct initialization using compound literals was used.
>>
>> This change improves code readability and ensures that all fields of
>> the scan_type structure are properly zero-initialized.
>> Additionally, for the hid-sensor-accel-3d driver, the channel
>> initialization loop was refactored to iterate directly over the scan
>> indices, eliminating redundant logic.
>
>Series looks good to me but I'll leave it on the list a while to both let sashiko catch
>up and anyone else who wants to can have time to look. Also ideally get some
>testing.
>
>Lixu, if you don't mind, please can you give this a test on top of the more radical
>refactor patches?
Sure, I'll test this series on top of the refactor patches when I have some time.
Thanks,
Lixu
>
>To me it looks safe enough but this is the sort of series that subtle typos can hide
>in!
>
>Thanks,
>
>Jonathan
>
^ permalink raw reply
* Re: [PATCH v3 5/6] iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:19 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-6-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The refactored code uses a non-existent member `.format` in `struct iio_scan_type` instead of `.sign`, leading to a compilation error.
--
commit 579bb9f2450aced0e3f18e7e7316e70845e6e72b
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel initialization
This commit replaces the local magn_3d_adjust_channel_bit_mask() function
with a compound literal for scan_type initialization to improve code
readability.
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index c673f9323e476..3b26dc41dd4cf 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
[ ... ]
> @@ -418,9 +408,11 @@ static int magn_3d_parse_report(struct platform_device *pdev,
> if (i != CHANNEL_SCAN_INDEX_TIMESTAMP) {
> /* Set magn_val_addr to iio value address */
> st->magn_val_addr[i] = &st->iio_vals[*chan_count];
> - magn_3d_adjust_channel_bit_mask(_channels,
> - *chan_count,
> - st->magn[i].size);
> + _channels[*chan_count].scan_type = (struct iio_scan_type) {
> + .format = 's',
Will this regression cause a compilation error?
Looking at struct iio_scan_type in include/linux/iio/iio.h, there is a member
named sign, but no member named format.
For example, other channel setups use sign:
include/linux/iio/iio.h:
#define IIO_CHAN_SOFT_TIMESTAMP(_si) { \
... \
.scan_type = { \
.sign = 's', \
.realbits = 64, \
.storagebits = 64, \
}, \
}
Should this compound literal be updated to use .sign = 's' instead?
> + .realbits = BYTES_TO_BITS(st->magn[i].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> }
> (*chan_count)++;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=5
^ permalink raw reply
* Re: [PATCH v3 4/6] iio: light: HID: hid-sensor-prox: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:10 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-5-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a compilation error by incorrectly initializing a non-existent '.format' field in `struct iio_scan_type`.
--
commit b9cbff53934f8976c34e3030a4b171bfc276e140
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: light: HID: hid-sensor-prox: Refactor channel initialization
This commit refactors the initialization of the scan_type field for proximity
sensor channels by replacing the prox_adjust_channel_bit_mask() function with
a compound literal.
> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
> index efa904a70d0ef..edc9274a2c076 100644
> --- a/drivers/iio/light/hid-sensor-prox.c
> +++ b/drivers/iio/light/hid-sensor-prox.c
[ ... ]
> @@ -250,8 +240,11 @@ static int prox_parse_report(struct platform_device *pdev,
> st->scan_mask[0] |= BIT(index);
> channels[index] = prox_channels[i];
> channels[index].scan_index = index;
> - prox_adjust_channel_bit_mask(channels, index,
> - st->prox_attr[index].size);
> + channels[index].scan_type = (struct iio_scan_type) {
> + .format = 's',
Will this cause a compilation error? struct iio_scan_type does not have a
member named format. The previous code set the sign member to 's'. Should
this be .sign instead of .format?
> + .realbits = BYTES_TO_BITS(st->prox_attr[index].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> dev_dbg(&pdev->dev, "prox %x:%x\n", st->prox_attr[index].index,
> st->prox_attr[index].report_id);
> st->scale_precision[index] =
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=4
^ permalink raw reply
* Re: [PATCH v3 3/6] iio: light: HID: hid-sensor-als: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:00 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-4-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a build error by initializing a non-existent `.format` field in `struct iio_scan_type`.
--
commit 0b0eb5f75d5c3745616a7e7de9ace24a35760cff
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: light: HID: hid-sensor-als: Refactor channel initialization
This commit replaces the local als_adjust_channel_bit_mask() function
with a compound literal for scan_type initialization to improve code
readability.
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index 830e5ae7f34a7..e5b4c5e80f1cf 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
[ ... ]
> @@ -334,7 +324,11 @@ static int als_parse_report(struct platform_device *pdev,
>
> channels[index] = als_channels[i];
> st->als_scan_mask[0] |= BIT(i);
> - als_adjust_channel_bit_mask(channels, index, st->als[i].size);
> + channels[index].scan_type = (struct iio_scan_type) {
> + .format = 's',
Does this cause a build failure? Looking at struct iio_scan_type in
include/linux/iio/iio.h, there is no field named format.
The removed code assigned this value to the sign field:
channels[channel].scan_type.sign = 's';
Should this compound literal initialize .sign instead of .format?
> + .realbits = BYTES_TO_BITS(st->als[i].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> ++index;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=3
^ permalink raw reply
* Re: [PATCH v3 2/6] iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 2:50 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-3-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The struct iio_scan_type does not have a member named 'format', which causes a build failure.
--
commit 8a26f68e644f245021a8896a54c6e164b2d81277
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
This commit refactors the channel initialization in the hid-sensor-gyro-3d
driver by replacing the local gyro_3d_adjust_channel_bit_mask function with
a compound literal for scan_type initialization to improve readability.
> diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> index c43990c518f77..be8406da32f0e 100644
> --- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> +++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
[ ... ]
> -/* Adjust channel real bits based on report descriptor */
> -static void gyro_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
> - int channel, int size)
> -{
> - channels[channel].scan_type.sign = 's';
> - /* Real storage bits will change based on the report desc. */
> - channels[channel].scan_type.realbits = size * 8;
> - /* Maximum size of a sample to capture is u32 */
> - channels[channel].scan_type.storagebits = sizeof(u32) * 8;
> -}
> -
[ ... ]
> @@ -251,16 +241,20 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
> int i;
>
> for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
[ ... ]
> - gyro_3d_adjust_channel_bit_mask(channels,
> - CHANNEL_SCAN_INDEX_X + i,
> - st->gyro[CHANNEL_SCAN_INDEX_X + i].size);
> + channels[ch].scan_type = (struct iio_scan_type) {
> + .format = 's',
Will this cause a build failure?
Struct iio_scan_type defines the field as sign, not format. The original
code being replaced here correctly assigned the value using
channels[channel].scan_type.sign = 's'.
> + .realbits = BYTES_TO_BITS(st->gyro[ch].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=2
^ permalink raw reply
* [PATCH v2] HID: lenovo: Fix buffer over-read and unaligned access in X12 Tab raw_event handler
From: Kean @ 2026-05-13 2:40 UTC (permalink / raw)
To: Derek J . Clark, Mark Pearson, linux-input
Cc: Kean, Jiri Kosina, Benjamin Tissoires, linux-kernel
In-Reply-To: <20260511132854.1351379-1-rh_king%40163.com>
In lenovo_raw_event(), the X12 Tab keyboard handler reads a 4-byte
little-endian value via *(__le32 *)data but only guards the access
with a size >= 3 check. If a 3-byte report with ID 0x03 is received,
the code reads one byte beyond the end of the buffer.
Change the size check to >= 4 to match the actual access width.
Additionally, casting a u8 *data pointer directly to __le32 * can
trigger unaligned access faults on architectures that enforce memory
alignment (ARM, MIPS, SPARC). The HID core provides no alignment
guarantee for the data buffer — for example, uhid payloads via
UHID_INPUT2 start at offset 6 in the uhid_event struct, giving only
2-byte alignment.
Use get_unaligned_le32() to safely read the little-endian value
regardless of the buffer's alignment. get_unaligned_le32() already
handles the LE-to-CPU conversion, so the le32_to_cpu() wrapper is
no longer needed.
Signed-off-by: Kean <rh_king@163.com>
---
Thank you for the review!
Both issues you identified are correct. This v2 addresses both memory
safety concerns in one patch:
1. Buffer over-read: size >= 3 → size >= 4 to match the 4-byte access.
2. Unaligned access: *( __le32 *)data cast → get_unaligned_le32(data),
which safely handles the uhid scenario you described (2-byte alignment
at offset 6 of uhid_event). get_unaligned_le32() already does the
LE-to-CPU conversion so le32_to_cpu() is no longer needed.
Regarding the missing key capability registration — you are correct
that these hotkey events would be silently dropped by the input core.
I'll need some time to reproduce and test this on the actual hardware
before submitting a separate patch for it.
drivers/hid/hid-lenovo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index a6b73e03c16b..10c86f4e1467 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -31,6 +31,7 @@
#include <linux/input.h>
#include <linux/leds.h>
#include <linux/workqueue.h>
+#include <linux/unaligned.h>
#include "hid-ids.h"
@@ -793,8 +794,8 @@ static int lenovo_raw_event(struct hid_device *hdev,
*/
if (unlikely((hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB
|| hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB2)
- && size >= 3 && report->id == 0x03))
- return lenovo_raw_event_TP_X12_tab(hdev, le32_to_cpu(*(__le32 *)data));
+ && size >= 4 && report->id == 0x03))
+ return lenovo_raw_event_TP_X12_tab(hdev, get_unaligned_le32(data));
return 0;
}
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 1/6] iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 2:21 UTC (permalink / raw)
To: Natália Salvino André; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260512012302.20883-2-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect HID attribute usage ID passed to `sensor_hub_input_get_attribute_info()`, breaking device initialization.
- [Low] Invalid struct member `.format` used in `struct iio_scan_type` initialization.
--
commit b8c3d6dce107c50c4bd37c0ec71526208891109a
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
This commit cleans up the channel initialization loop in the HID 3D
accelerometer driver. It replaces a local helper function with a compound
literal to directly initialize the channel scan type configuration.
> diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
> index 2ff591b3458f7..99ca67732bbe2 100644
> --- a/drivers/iio/accel/hid-sensor-accel-3d.c
> +++ b/drivers/iio/accel/hid-sensor-accel-3d.c
[ ... ]
> @@ -297,19 +287,20 @@ static int accel_3d_parse_report(struct platform_device *pdev,
> struct accel_3d_state *st)
> {
> int ret;
> - int i;
>
> - for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
> + for (unsigned int ch = CHANNEL_SCAN_INDEX_X; ch <= CHANNEL_SCAN_INDEX_Z; ch++) {
> ret = sensor_hub_input_get_attribute_info(hsdev,
> HID_INPUT_REPORT,
> usage_id,
> - HID_USAGE_SENSOR_ACCEL_X_AXIS + i,
> - &st->accel[CHANNEL_SCAN_INDEX_X + i]);
> + ch,
The fourth argument to sensor_hub_input_get_attribute_info() is the
attribute usage ID. Previously, this passed HID_USAGE_SENSOR_ACCEL_X_AXIS + i.
Does passing the loop variable ch (which represents internal index values
like 0, 1, 2) prevent the driver from finding the accelerometer fields in
the HID report descriptor?
> + &st->accel[ch]);
> if (ret < 0)
> break;
> - accel_3d_adjust_channel_bit_mask(channels,
> - CHANNEL_SCAN_INDEX_X + i,
> - st->accel[CHANNEL_SCAN_INDEX_X + i].size);
> + channels[ch].scan_type = (struct iio_scan_type) {
> + .format = 's',
Does struct iio_scan_type have a format member? Looking at
include/linux/iio/iio.h, it appears the correct member name for this
field is sign.
> + .realbits = BYTES_TO_BITS(st->accel[ch].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=1
^ permalink raw reply
* [hid:for-next 9/14] drivers/hid/hid-core.c:2054:29: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int')
From: kernel test robot @ 2026-05-13 2:11 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: llvm, oe-kbuild-all, linux-input, Jiri Kosina, Greg Kroah-Hartman
tree: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
head: 5d1aae9252b4632ef942017fdd18b9993a5a22ef
commit: 2c85c61d1332e1e16f020d76951baf167dcb6f7a [9/14] HID: pass the buffer size to hid_report_raw_event
config: arm-sama7_defconfig (https://download.01.org/0day-ci/archive/20260513/202605131044.Xc1Uihhm-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260513/202605131044.Xc1Uihhm-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605131044.Xc1Uihhm-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/hid/hid-core.c:2054:29: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~~
| %zu
2054 | report->id, csize, bsize);
| ^~~~~
include/linux/hid.h:1340:43: note: expanded from macro 'hid_warn_ratelimited'
1340 | dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:227:46: note: expanded from macro 'dev_warn_ratelimited'
227 | dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:215:25: note: expanded from macro 'dev_level_ratelimited'
215 | dev_level(dev, fmt, ##__VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:156:70: note: expanded from macro 'dev_warn'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
drivers/hid/hid-core.c:2076:29: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~~
| %zu
2076 | report->id, rsize, bsize);
| ^~~~~
include/linux/hid.h:1340:43: note: expanded from macro 'hid_warn_ratelimited'
1340 | dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:227:46: note: expanded from macro 'dev_warn_ratelimited'
227 | dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:215:25: note: expanded from macro 'dev_level_ratelimited'
215 | dev_level(dev, fmt, ##__VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:156:70: note: expanded from macro 'dev_warn'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
2 warnings generated.
vim +2054 drivers/hid/hid-core.c
2035
2036 int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
2037 size_t bufsize, u32 size, int interrupt)
2038 {
2039 struct hid_report_enum *report_enum = hid->report_enum + type;
2040 struct hid_report *report;
2041 struct hid_driver *hdrv;
2042 int max_buffer_size = HID_MAX_BUFFER_SIZE;
2043 u32 rsize, csize = size;
2044 size_t bsize = bufsize;
2045 u8 *cdata = data;
2046 int ret = 0;
2047
2048 report = hid_get_report(report_enum, data);
2049 if (!report)
2050 return 0;
2051
2052 if (unlikely(bsize < csize)) {
2053 hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
> 2054 report->id, csize, bsize);
2055 return -EINVAL;
2056 }
2057
2058 if (report_enum->numbered) {
2059 cdata++;
2060 csize--;
2061 bsize--;
2062 }
2063
2064 rsize = hid_compute_report_size(report);
2065
2066 if (hid->ll_driver->max_buffer_size)
2067 max_buffer_size = hid->ll_driver->max_buffer_size;
2068
2069 if (report_enum->numbered && rsize >= max_buffer_size)
2070 rsize = max_buffer_size - 1;
2071 else if (rsize > max_buffer_size)
2072 rsize = max_buffer_size;
2073
2074 if (bsize < rsize) {
2075 hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
2076 report->id, rsize, bsize);
2077 return -EINVAL;
2078 }
2079
2080 if (csize < rsize) {
2081 dbg_hid("report %d is too short, (%d < %d)\n", report->id,
2082 csize, rsize);
2083 memset(cdata + csize, 0, rsize - csize);
2084 }
2085
2086 if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
2087 hid->hiddev_report_event(hid, report);
2088 if (hid->claimed & HID_CLAIMED_HIDRAW) {
2089 ret = hidraw_report_event(hid, data, size);
2090 if (ret)
2091 return ret;
2092 }
2093
2094 if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
2095 hid_process_report(hid, report, cdata, interrupt);
2096 hdrv = hid->driver;
2097 if (hdrv && hdrv->report)
2098 hdrv->report(hid, report);
2099 }
2100
2101 if (hid->claimed & HID_CLAIMED_INPUT)
2102 hidinput_report_event(hid, report);
2103
2104 return ret;
2105 }
2106 EXPORT_SYMBOL_GPL(hid_report_raw_event);
2107
2108
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] HID: magicmouse: add haptic click configuration for Magic Trackpad 2
From: sashiko-bot @ 2026-05-13 0:16 UTC (permalink / raw)
To: Christian Fressl; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260511203115.104087-1-christian@fressl.at>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The module parameter `haptic_click` is read multiple times without being cached, resulting in a Time-of-Check to Time-of-Use (TOCTOU) race condition.
--
commit 160ed71822c4a0697b90debaa037251a7e50642c
Author: Christian Fressl <christian@fressl.at>
HID: magicmouse: add haptic click configuration for Magic Trackpad 2
This commit adds support for configuring the haptic feedback on Apple
Magic Trackpad 2 devices. It introduces the haptic_click module parameter
to choose between unchanged, silent-low, or off states.
Link: https://github.com/mwyborski/Linux-Magic-Trackpad-2-Driver/issues/28#issuecomment-451625504
> diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> index e70bd3dc07ab7..31002cb1f1089 100644
> --- a/drivers/hid/hid-magicmouse.c
> +++ b/drivers/hid/hid-magicmouse.c
[ ... ]
> @@ -812,6 +827,81 @@ static bool is_usb_magictrackpad2(__u32 vendor, __u32 product)
[ ... ]
> +static int magicmouse_apply_haptic_click(struct hid_device *hdev)
> +{
> + u32 click_feedback;
> + u32 release_feedback;
> + int ret;
> +
> + if (haptic_click == TRACKPAD2_HAPTIC_CLICK_UNCHANGED)
> + return 0;
> +
> + switch (haptic_click) {
Since haptic_click is a module parameter with 0644 permissions, can it
change concurrently between the if statement and the switch statement?
If it changes from TRACKPAD2_HAPTIC_CLICK_SILENT_LOW (1) to
TRACKPAD2_HAPTIC_CLICK_UNCHANGED (0) right after the early return check,
this regression could cause the switch statement to fall through to the
default case. This would result in an incorrect warning and return -EINVAL.
Would it be safer to read the parameter into a local variable once using
READ_ONCE() to avoid this race condition?
> + case TRACKPAD2_HAPTIC_CLICK_SILENT_LOW:
> + click_feedback = TRACKPAD2_HAPTIC_SILENT_CLICK;
> + release_feedback = TRACKPAD2_HAPTIC_SILENT_RELEASE;
> + break;
> + case TRACKPAD2_HAPTIC_CLICK_OFF:
> + click_feedback = TRACKPAD2_HAPTIC_OFF;
> + release_feedback = TRACKPAD2_HAPTIC_OFF;
> + break;
> + default:
> + hid_warn(hdev, "invalid haptic_click value %u\n", haptic_click);
> + return -EINVAL;
> + }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511203115.104087-1-christian@fressl.at?part=1
^ permalink raw reply
* Re: [PATCH] HID: playstation: Clamp num_touch_reports
From: T.J. Mercier @ 2026-05-12 23:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: roderick.colenbrander, linux-input, Benjamin Tissoires, stable,
Xingyu Jin, Roderick Colenbrander, linux-kernel
In-Reply-To: <89s27nso-4053-p971-4q69-p4nqo5n7p65q@xreary.bet>
On Tue, May 12, 2026 at 8:55 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Fri, 17 Apr 2026, T.J. Mercier wrote:
>
> > A device would never lie about the number of touch reports would it?
> >
> > If it does the loop in dualshock4_parse_report will read off the end of
> > the touch_reports array, up to about 2 KiB for the maximum number of 256
> > loop iteraions. The data that is read is emitted via evdev if the
> > DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by
> > clamping the num_touch_reports value provided by the device to the
> > maximum size of the touch_reports array.
> >
> > Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.")
> > Cc: stable@vger.kernel.org
> > Reported-by: Xingyu Jin <xingyuj@google.com>
> > Signed-off-by: T.J. Mercier <tjmercier@google.com>
>
> Applied, thanks.
>
> --
> Jiri Kosina
> SUSE Labs
Hi Jiri,
Thanks for applying this. However now I see that a different fix from
Benoît Sevens from around the same time has landed:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=82a4fc46330910b4c1d9b189561439d468e3ff11
That fix was not yet present at
3cd8b194bf3428dfa53120fee47e827a7c495815 which I used as my base.
His patch prints and returns an error in this situation while mine
silently avoids the OOB read.
So I think it probably makes sense to keep Benoît's patch, and drop
mine since his code means mine will never be reached.
Thanks,
T.J.
^ permalink raw reply
* [hid:for-next 9/14] drivers/hid/hid-core.c:2053:43: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'}
From: kernel test robot @ 2026-05-12 22:10 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: oe-kbuild-all, linux-input, Jiri Kosina, Greg Kroah-Hartman
tree: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
head: 5d1aae9252b4632ef942017fdd18b9993a5a22ef
commit: 2c85c61d1332e1e16f020d76951baf167dcb6f7a [9/14] HID: pass the buffer size to hid_report_raw_event
config: nios2-defconfig (https://download.01.org/0day-ci/archive/20260513/202605130624.FPpzDGhD-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260513/202605130624.FPpzDGhD-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605130624.FPpzDGhD-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/linux/input.h:19,
from drivers/hid/hid-core.c:25:
drivers/hid/hid-core.c: In function 'hid_report_raw_event':
>> drivers/hid/hid-core.c:2053:43: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:156:61: note: in expansion of macro 'dev_fmt'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
include/linux/dev_printk.h:215:17: note: in expansion of macro 'dev_warn'
215 | dev_level(dev, fmt, ##__VA_ARGS__); \
| ^~~~~~~~~
include/linux/dev_printk.h:227:9: note: in expansion of macro 'dev_level_ratelimited'
227 | dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~
include/linux/hid.h:1340:9: note: in expansion of macro 'dev_warn_ratelimited'
1340 | dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2053:17: note: in expansion of macro 'hid_warn_ratelimited'
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2053:91: note: format string is defined here
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~^
| |
| long int
| %d
In file included from include/linux/device.h:15,
from include/linux/input.h:19,
from drivers/hid/hid-core.c:25:
drivers/hid/hid-core.c:2075:43: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:156:61: note: in expansion of macro 'dev_fmt'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
include/linux/dev_printk.h:215:17: note: in expansion of macro 'dev_warn'
215 | dev_level(dev, fmt, ##__VA_ARGS__); \
| ^~~~~~~~~
include/linux/dev_printk.h:227:9: note: in expansion of macro 'dev_level_ratelimited'
227 | dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~
include/linux/hid.h:1340:9: note: in expansion of macro 'dev_warn_ratelimited'
1340 | dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2075:17: note: in expansion of macro 'hid_warn_ratelimited'
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2075:92: note: format string is defined here
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~^
| |
| long int
| %d
vim +2053 drivers/hid/hid-core.c
2035
2036 int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
2037 size_t bufsize, u32 size, int interrupt)
2038 {
2039 struct hid_report_enum *report_enum = hid->report_enum + type;
2040 struct hid_report *report;
2041 struct hid_driver *hdrv;
2042 int max_buffer_size = HID_MAX_BUFFER_SIZE;
2043 u32 rsize, csize = size;
2044 size_t bsize = bufsize;
2045 u8 *cdata = data;
2046 int ret = 0;
2047
2048 report = hid_get_report(report_enum, data);
2049 if (!report)
2050 return 0;
2051
2052 if (unlikely(bsize < csize)) {
> 2053 hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
2054 report->id, csize, bsize);
2055 return -EINVAL;
2056 }
2057
2058 if (report_enum->numbered) {
2059 cdata++;
2060 csize--;
2061 bsize--;
2062 }
2063
2064 rsize = hid_compute_report_size(report);
2065
2066 if (hid->ll_driver->max_buffer_size)
2067 max_buffer_size = hid->ll_driver->max_buffer_size;
2068
2069 if (report_enum->numbered && rsize >= max_buffer_size)
2070 rsize = max_buffer_size - 1;
2071 else if (rsize > max_buffer_size)
2072 rsize = max_buffer_size;
2073
2074 if (bsize < rsize) {
2075 hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
2076 report->id, rsize, bsize);
2077 return -EINVAL;
2078 }
2079
2080 if (csize < rsize) {
2081 dbg_hid("report %d is too short, (%d < %d)\n", report->id,
2082 csize, rsize);
2083 memset(cdata + csize, 0, rsize - csize);
2084 }
2085
2086 if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
2087 hid->hiddev_report_event(hid, report);
2088 if (hid->claimed & HID_CLAIMED_HIDRAW) {
2089 ret = hidraw_report_event(hid, data, size);
2090 if (ret)
2091 return ret;
2092 }
2093
2094 if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
2095 hid_process_report(hid, report, cdata, interrupt);
2096 hdrv = hid->driver;
2097 if (hdrv && hdrv->report)
2098 hdrv->report(hid, report);
2099 }
2100
2101 if (hid->claimed & HID_CLAIMED_INPUT)
2102 hidinput_report_event(hid, report);
2103
2104 return ret;
2105 }
2106 EXPORT_SYMBOL_GPL(hid_report_raw_event);
2107
2108
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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