* [PATCH v2 19/20] Input: rmi4 - propagate proper error code in F12 sensor tuning
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Propagate the actual error code returned by rmi_read() in
rmi_f12_read_sensor_tuning() instead of hardcoding -ENODEV.
Also, since rmi_read() returns 0 on success, use 'if (ret)'
instead of 'if (ret < 0)'.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index ea72d5ce8050..bf8c4a0e10de 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -166,9 +166,9 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
RMI_F12_QUERY_RESOLUTION);
query_dpm_addr = fn->fd.query_base_addr + offset;
ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf);
- if (ret < 0) {
+ if (ret) {
dev_err(&fn->dev, "Failed to read DPM value: %d\n", ret);
- return -ENODEV;
+ return ret;
}
dpm_resolution = buf[0];
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 20/20] Input: rmi4 - update formatting in F12
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Clean up various style and formatting issues in the F12 code.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 120 +++++++++++++++++------------------
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index bf8c4a0e10de..88c28089de99 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -51,7 +51,6 @@ struct f12_data {
const struct rmi_register_desc_item *data6;
u16 data6_offset;
-
/* F12 Data9 reports relative data */
const struct rmi_register_desc_item *data9;
u16 data9_offset;
@@ -124,8 +123,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
return -ENODEV;
}
- ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr + offset, buf,
- item->reg_size);
+ ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr + offset,
+ buf, item->reg_size);
if (ret)
return ret;
@@ -163,7 +162,7 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
if (rmi_get_register_desc_item(&f12->query_reg_desc,
RMI_F12_QUERY_RESOLUTION)) {
offset = rmi_register_desc_calc_reg_offset(&f12->query_reg_desc,
- RMI_F12_QUERY_RESOLUTION);
+ RMI_F12_QUERY_RESOLUTION);
query_dpm_addr = fn->fd.query_base_addr + offset;
ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf);
if (ret) {
@@ -248,18 +247,17 @@ static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1, u32 size)
static irqreturn_t rmi_f12_attention(int irq, void *ctx)
{
- int retval;
struct rmi_function *fn = ctx;
struct rmi_device *rmi_dev = fn->rmi_dev;
struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
struct f12_data *f12 = dev_get_drvdata(&fn->dev);
struct rmi_2d_sensor *sensor = &f12->sensor;
u32 valid_bytes = sensor->pkt_size;
+ int retval;
if (drvdata->attn_data.data) {
valid_bytes = min_t(u32, sensor->attn_size, drvdata->attn_data.size);
- memcpy(sensor->data_pkt, drvdata->attn_data.data,
- valid_bytes);
+ memcpy(sensor->data_pkt, drvdata->attn_data.data, valid_bytes);
drvdata->attn_data.data += valid_bytes;
drvdata->attn_data.size -= valid_bytes;
} else {
@@ -273,70 +271,74 @@ static irqreturn_t rmi_f12_attention(int irq, void *ctx)
}
if (f12->data1)
- rmi_f12_process_objects(f12,
- &sensor->data_pkt[f12->data1_offset], valid_bytes);
+ rmi_f12_process_objects(f12, &sensor->data_pkt[f12->data1_offset],
+ valid_bytes);
input_mt_sync_frame(sensor->input);
return IRQ_HANDLED;
}
-static int rmi_f12_write_control_regs(struct rmi_function *fn)
+static int rmi_f12_update_dribble(struct rmi_function *fn, struct f12_data *f12)
{
- int ret;
const struct rmi_register_desc_item *item;
struct rmi_device *rmi_dev = fn->rmi_dev;
- struct f12_data *f12 = dev_get_drvdata(&fn->dev);
- int control_size;
- char buf[3];
- u16 control_offset = 0;
u8 subpacket_offset = 0;
+ u16 control_offset;
+ u32 control_size;
+ int error;
+ u8 buf[3];
- if (f12->has_dribble
- && (f12->sensor.dribble != RMI_REG_STATE_DEFAULT)) {
- item = rmi_get_register_desc_item(&f12->control_reg_desc, 20);
- if (item) {
- control_offset = rmi_register_desc_calc_reg_offset(
- &f12->control_reg_desc, 20);
-
- /*
- * The byte containing the EnableDribble bit will be
- * in either byte 0 or byte 2 of control 20. Depending
- * on the existence of subpacket 0. If control 20 is
- * larger then 3 bytes, just read the first 3.
- */
- control_size = min(item->reg_size, 3U);
-
- ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr
- + control_offset, buf, control_size);
- if (ret)
- return ret;
-
- if (rmi_register_desc_has_subpacket(item, 0))
- subpacket_offset += 1;
-
- switch (f12->sensor.dribble) {
- case RMI_REG_STATE_OFF:
- buf[subpacket_offset] &= ~BIT(2);
- break;
- case RMI_REG_STATE_ON:
- buf[subpacket_offset] |= BIT(2);
- break;
- case RMI_REG_STATE_DEFAULT:
- default:
- break;
- }
+ item = rmi_get_register_desc_item(&f12->control_reg_desc, 20);
+ if (!item)
+ return 0;
- ret = rmi_write_block(rmi_dev,
- fn->fd.control_base_addr + control_offset,
- buf, control_size);
- if (ret)
- return ret;
- }
+ control_offset = rmi_register_desc_calc_reg_offset(&f12->control_reg_desc, 20);
+
+ /*
+ * The byte containing the EnableDribble bit will be
+ * in either byte 0 or byte 2 of control 20. Depending
+ * on the existence of subpacket 0. If control 20 is
+ * larger then 3 bytes, just read the first 3.
+ */
+ control_size = min(item->reg_size, 3U);
+
+ error = rmi_read_block(rmi_dev, fn->fd.control_base_addr + control_offset,
+ buf, control_size);
+ if (error)
+ return error;
+
+ if (rmi_register_desc_has_subpacket(item, 0))
+ subpacket_offset += 1;
+
+ switch (f12->sensor.dribble) {
+ case RMI_REG_STATE_OFF:
+ buf[subpacket_offset] &= ~BIT(2);
+ break;
+ case RMI_REG_STATE_ON:
+ buf[subpacket_offset] |= BIT(2);
+ break;
+ case RMI_REG_STATE_DEFAULT:
+ default:
+ break;
}
+ error = rmi_write_block(rmi_dev, fn->fd.control_base_addr + control_offset,
+ buf, control_size);
+ if (error)
+ return error;
+
return 0;
+}
+static int rmi_f12_write_control_regs(struct rmi_function *fn)
+{
+ struct f12_data *f12 = dev_get_drvdata(&fn->dev);
+
+ if (f12->has_dribble && f12->sensor.dribble != RMI_REG_STATE_DEFAULT)
+ return rmi_f12_update_dribble(fn, f12);
+
+ return 0;
}
static int rmi_f12_config(struct rmi_function *fn)
@@ -362,7 +364,7 @@ static int rmi_f12_config(struct rmi_function *fn)
ret = rmi_f12_write_control_regs(fn);
if (ret)
dev_warn(&fn->dev,
- "Failed to write F12 control registers: %d\n", ret);
+ "Failed to write F12 control registers: %d\n", ret);
return 0;
}
@@ -433,16 +435,14 @@ static int rmi_f12_probe(struct rmi_function *fn)
}
sensor->pkt_size = pkt_size;
- sensor->axis_align =
- f12->sensor_pdata.axis_align;
+ sensor->axis_align = f12->sensor_pdata.axis_align;
sensor->x_mm = f12->sensor_pdata.x_mm;
sensor->y_mm = f12->sensor_pdata.y_mm;
sensor->dribble = f12->sensor_pdata.dribble;
if (sensor->sensor_type == rmi_sensor_default)
- sensor->sensor_type =
- f12->sensor_pdata.sensor_type;
+ sensor->sensor_type = f12->sensor_pdata.sensor_type;
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: data packet size: %u\n", __func__,
sensor->pkt_size);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH] Input: xpad - remove unused xpad_init_output intf parameter
From: Tobias Klauser @ 2026-05-05 8:08 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
The intf parameter to xpad_init_output is unused since commit
c01b5e7464f0 ("Input: xpad - don't depend on endpoint order"). Remove
it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/input/joystick/xpad.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index feb8f368f834..4c5528eb94b3 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1388,8 +1388,8 @@ static void xpad_irq_out(struct urb *urb)
}
}
-static int xpad_init_output(struct usb_interface *intf, struct usb_xpad *xpad,
- struct usb_endpoint_descriptor *ep_irq_out)
+static int xpad_init_output(struct usb_xpad *xpad,
+ struct usb_endpoint_descriptor *ep_irq_out)
{
int error;
@@ -2136,7 +2136,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
goto err_free_in_urb;
}
- error = xpad_init_output(intf, xpad, ep_irq_out);
+ error = xpad_init_output(xpad, ep_irq_out);
if (error)
goto err_free_in_urb;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 1/3] Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem
From: Ricardo Ribalda @ 2026-05-05 9:08 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Nick Dyer, linux-input, linux-kernel, stable
In-Reply-To: <20260504185448.4055973-1-dmitry.torokhov@gmail.com>
HI Dmitry
FWIW this patch looks correct to me...
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
But there are a couple of things that look weird.
1) The patch line (1503) does not seem to match your tree
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/tree/drivers/input/touchscreen/atmel_mxt_ts.c#n1503
2) The sscanf just before this check has two conversions (val and
offset), but you only check for ret != 1. Should't it be ret !=2? or I
am missing something?
On Mon, 4 May 2026 at 20:54, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> When a configuration file provides an object size that is larger than the
> driver's known mxt_obj_size(object), the driver intends to discard the
> extra bytes.
>
> The loop iterates using for (i = 0; i < size; i++). Inside the loop, the
> condition to skip processing extra bytes is:
>
> if (i > mxt_obj_size(object))
> continue;
>
> Since i is a 0-based index, the valid indices for the object are 0 through
> mxt_obj_size(object) - 1.
>
> When i == mxt_obj_size(object), the condition evaluates to false, and the
> code processes the byte instead of discarding it.
>
> This causes the code to calculate byte_offset = reg + i - cfg->start_ofs
> and writes the byte there, overwriting exactly one byte of the adjacent
> instance or object.
>
> Update the boundary check to skip extra bytes correctly by using >=.
>
> Fixes: 50a77c658b80 ("Input: atmel_mxt_ts - download device config using firmware loader")
> Cc: stable@vger.kernel.org
> Assisted-by: Gemini:gemini-3.1-pro
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index d62bf2c95578..28b2bd889c70 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -1503,7 +1503,7 @@ static int mxt_prepare_cfg_mem(struct mxt_data *data, struct mxt_cfg *cfg)
> }
> cfg->raw_pos += offset;
>
> - if (i > mxt_obj_size(object))
> + if (i >= mxt_obj_size(object))
> continue;
>
> byte_offset = reg + i - cfg->start_ofs;
> --
> 2.54.0.545.g6539524ca2-goog
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 3/3] Input: atmel_mxt_ts - use __free() for obuf in mxt_object_show
From: Ricardo Ribalda @ 2026-05-05 9:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Nick Dyer, linux-input, linux-kernel
In-Reply-To: <20260504185448.4055973-3-dmitry.torokhov@gmail.com>
On Mon, 4 May 2026 at 20:54, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> Use the __free(kfree) macro for the obuf allocation in mxt_object_show()
> to simplify the code.
>
> Assisted-by: Gemini:gemini-3.1-pro
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index d660cc5b5fe3..6af4db5ed117 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2870,14 +2870,12 @@ static ssize_t mxt_object_show(struct device *dev,
> int count = 0;
> int i, j;
> int error;
> - u8 *obuf;
>
> /* Pre-allocate buffer large enough to hold max sized object. */
> - obuf = kmalloc(256, GFP_KERNEL);
> + u8 *obuf __free(kfree) = kmalloc(256, GFP_KERNEL);
> if (!obuf)
> return -ENOMEM;
>
> - error = 0;
> for (i = 0; i < data->info->object_num; i++) {
> object = data->object_table + i;
>
> @@ -2892,15 +2890,13 @@ static ssize_t mxt_object_show(struct device *dev,
>
> error = __mxt_read_reg(data->client, addr, size, obuf);
> if (error)
> - goto done;
> + return error;
>
> count = mxt_show_instance(buf, count, object, j, obuf);
> }
> }
>
> -done:
> - kfree(obuf);
> - return error ?: count;
> + return count;
> }
>
> static int mxt_check_firmware_format(struct device *dev,
> --
> 2.54.0.545.g6539524ca2-goog
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Linus Walleij @ 2026-05-05 10:39 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAPVz0n3h+zWi-b-ZTLqwXR-9JNGcUgVodUgo+ywhBfK-UDQJAw@mail.gmail.com>
On Thu, Apr 30, 2026 at 11:46 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> чт, 30 квіт. 2026 р. о 12:22 Linus Walleij <linusw@kernel.org> пише:
> In you original code
> /*
> * This is done in the vendor tree with the commment
> * "Duty 0x64 == nForce 90", and no force feedback happens
> * unless we do this.
> */
> if (isa->clk)
> regmap_write(isa->map, ISA1200_HCTRL5, 0x64);
>
> 0x64 is actually some conversion of duty cycle, you got this accurately.
I wonder if 0x64 = 100 is simply 100% duty cycle?
So the value in this register can only be 0..100.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-05-05 11:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAD++jLk_SojErY4gxjixzwEF3sfSownH=jBYaoPD2LeoxibhWw@mail.gmail.com>
вт, 5 трав. 2026 р. о 13:39 Linus Walleij <linusw@kernel.org> пише:
>
> On Thu, Apr 30, 2026 at 11:46 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > чт, 30 квіт. 2026 р. о 12:22 Linus Walleij <linusw@kernel.org> пише:
>
> > In you original code
> > /*
> > * This is done in the vendor tree with the commment
> > * "Duty 0x64 == nForce 90", and no force feedback happens
> > * unless we do this.
> > */
> > if (isa->clk)
> > regmap_write(isa->map, ISA1200_HCTRL5, 0x64);
> >
> > 0x64 is actually some conversion of duty cycle, you got this accurately.
>
> I wonder if 0x64 = 100 is simply 100% duty cycle?
> So the value in this register can only be 0..100.
>
Assumption is interesting, but it is still just a guess based on
observation of a single hw configuration. For example, Samsung Galaxy
Tab 10.1 (GT-P7501) passes 133 (0x85) into duty register.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 6/6] leds: led-class: mark classdev as unregistering early
From: James Ye @ 2026-05-05 14:16 UTC (permalink / raw)
To: kernel test robot
Cc: jikos, bentiss, lee, pavel, oe-kbuild-all, linux-input,
linux-leds, linux-kernel, denis.benato
In-Reply-To: <202605050414.YJmW3t4y-lkp@intel.com>
On Tue, 5 May 2026 at 12:24, kernel test robot <lkp@intel.com> wrote:
>
> Hi James,
>
> kernel test robot noticed the following build errors:
This is due to CONFIG_HID_BATTERY_STRENGTH being turned off, I will
fix it in the next version.
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS e7b91b21755924c2b26bd4f925c1b538a48b2370
From: kernel test robot @ 2026-05-05 14:38 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: e7b91b21755924c2b26bd4f925c1b538a48b2370 Input: atmel_mxt_ts - set byte_offset as signed
elapsed time: 728m
configs tested: 222
configs skipped: 15
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 allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260505 gcc-8.5.0
arc randconfig-002-20260505 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm mmp2_defconfig gcc-15.2.0
arm randconfig-001-20260505 gcc-8.5.0
arm randconfig-002-20260505 gcc-8.5.0
arm randconfig-003-20260505 gcc-8.5.0
arm randconfig-004-20260505 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260505 gcc-14.3.0
arm64 randconfig-002-20260505 gcc-14.3.0
arm64 randconfig-003-20260505 gcc-14.3.0
arm64 randconfig-004-20260505 gcc-14.3.0
csky alldefconfig gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260505 gcc-14.3.0
csky randconfig-002-20260505 gcc-14.3.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260505 clang-23
hexagon randconfig-001-20260505 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260505 clang-23
hexagon randconfig-002-20260505 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260505 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260505 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260505 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260505 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260505 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260505 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260505 clang-20
i386 randconfig-002-20260505 clang-20
i386 randconfig-003-20260505 clang-20
i386 randconfig-004-20260505 clang-20
i386 randconfig-005-20260505 clang-20
i386 randconfig-006-20260505 clang-20
i386 randconfig-007-20260505 clang-20
i386 randconfig-011-20260505 clang-20
i386 randconfig-012-20260505 clang-20
i386 randconfig-013-20260505 clang-20
i386 randconfig-014-20260505 clang-20
i386 randconfig-015-20260505 clang-20
i386 randconfig-016-20260505 clang-20
i386 randconfig-017-20260505 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260505 clang-23
loongarch randconfig-001-20260505 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260505 clang-23
loongarch randconfig-002-20260505 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
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 decstation_64_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260505 clang-23
nios2 randconfig-001-20260505 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260505 clang-23
nios2 randconfig-002-20260505 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc de0_nano_multicore_defconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc generic-32bit_defconfig gcc-15.2.0
parisc randconfig-001 gcc-14.3.0
parisc randconfig-001-20260505 gcc-14.3.0
parisc randconfig-002 gcc-14.3.0
parisc randconfig-002-20260505 gcc-14.3.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001 gcc-14.3.0
powerpc randconfig-001-20260505 gcc-14.3.0
powerpc randconfig-002 gcc-14.3.0
powerpc randconfig-002-20260505 gcc-14.3.0
powerpc tqm8541_defconfig clang-23
powerpc64 randconfig-001 gcc-14.3.0
powerpc64 randconfig-001-20260505 gcc-14.3.0
powerpc64 randconfig-002 gcc-14.3.0
powerpc64 randconfig-002-20260505 gcc-14.3.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260505 gcc-10.5.0
riscv randconfig-002-20260505 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260505 gcc-10.5.0
s390 randconfig-002-20260505 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260505 gcc-10.5.0
sh randconfig-002-20260505 gcc-10.5.0
sh urquell_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-15.2.0
sparc randconfig-001-20260505 gcc-15.2.0
sparc randconfig-002 gcc-15.2.0
sparc randconfig-002-20260505 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-15.2.0
sparc64 randconfig-001-20260505 gcc-15.2.0
sparc64 randconfig-002 gcc-15.2.0
sparc64 randconfig-002-20260505 gcc-15.2.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-15.2.0
um randconfig-001-20260505 gcc-15.2.0
um randconfig-002 gcc-15.2.0
um randconfig-002-20260505 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260505 clang-20
x86_64 buildonly-randconfig-002-20260505 clang-20
x86_64 buildonly-randconfig-003-20260505 clang-20
x86_64 buildonly-randconfig-004-20260505 clang-20
x86_64 buildonly-randconfig-005-20260505 clang-20
x86_64 buildonly-randconfig-006-20260505 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001 clang-20
x86_64 randconfig-001-20260505 clang-20
x86_64 randconfig-002 clang-20
x86_64 randconfig-002-20260505 clang-20
x86_64 randconfig-003 clang-20
x86_64 randconfig-003-20260505 clang-20
x86_64 randconfig-004 clang-20
x86_64 randconfig-004-20260505 clang-20
x86_64 randconfig-005 clang-20
x86_64 randconfig-005-20260505 clang-20
x86_64 randconfig-006 clang-20
x86_64 randconfig-006-20260505 clang-20
x86_64 randconfig-011 clang-20
x86_64 randconfig-011-20260505 clang-20
x86_64 randconfig-012 clang-20
x86_64 randconfig-012-20260505 clang-20
x86_64 randconfig-013 clang-20
x86_64 randconfig-013-20260505 clang-20
x86_64 randconfig-014 clang-20
x86_64 randconfig-014-20260505 clang-20
x86_64 randconfig-015 clang-20
x86_64 randconfig-015-20260505 clang-20
x86_64 randconfig-016 clang-20
x86_64 randconfig-016-20260505 clang-20
x86_64 randconfig-071-20260505 clang-20
x86_64 randconfig-071-20260505 gcc-14
x86_64 randconfig-072-20260505 clang-20
x86_64 randconfig-073-20260505 clang-20
x86_64 randconfig-073-20260505 gcc-14
x86_64 randconfig-074-20260505 clang-20
x86_64 randconfig-074-20260505 gcc-14
x86_64 randconfig-075-20260505 clang-20
x86_64 randconfig-076-20260505 clang-20
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 allyesconfig clang-23
xtensa randconfig-001 gcc-15.2.0
xtensa randconfig-001-20260505 gcc-15.2.0
xtensa randconfig-002 gcc-15.2.0
xtensa randconfig-002-20260505 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/3] Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem
From: Dmitry Torokhov @ 2026-05-05 15:03 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: Nick Dyer, linux-input, linux-kernel, stable
In-Reply-To: <CANiDSCv+h_ry7W1e1mFNLhont-1xigEZj6jL3m=FVgv2UC+KzQ@mail.gmail.com>
Hi Ricardo,
On Tue, May 05, 2026 at 11:08:15AM +0200, Ricardo Ribalda wrote:
> HI Dmitry
>
> FWIW this patch looks correct to me...
Thank you for looking this over.
>
> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
>
> But there are a couple of things that look weird.
>
> 1) The patch line (1503) does not seem to match your tree
> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/tree/drivers/input/touchscreen/atmel_mxt_ts.c#n1503
Yeah, I have an unrelated path in my queue that affects line offsets,
>
> 2) The sscanf just before this check has two conversions (val and
> offset), but you only check for ret != 1. Should't it be ret !=2? or I
> am missing something?
"%n" format specifier does not increment number of successfully parsed
elements returned by sscanf(). It kind of makes sense although may look
surprising.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Kris Bahnsen @ 2026-05-05 16:21 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <aflcL6y_ugHV5p8s@google.com>
Dmitry,
On 5/4/26 8:01 PM, Dmitry Torokhov wrote:
> Hi Kris,
>
> On Thu, Apr 30, 2026 at 05:37:38PM +0000, Kris Bahnsen wrote:
>> The workaround for XPT2046 clears the command register, giving the
>> touchscreen controller a NOP. The change incorrectly re-uses the
>> req->scratch variable which is used as rx_buf for xfer[5], so by
>> the time xfer[6] occurs, the contents of req->scratch may not be
>> 0. It was found that the touchscreen controller can end up in
>> a completely unresponsive state due to it being given a command
>> the driver does not expect.
>>
>> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
>> transmit all 0 bits and use the scratch variable for the rx_buf for
>> both the 1 byte command to and 2 byte response from the controller.
>>
>> This change was tested on real TSC2046 and ADS7843 controllers,
>> but not the XPT2046 the workaround was originally created for.
>> Confirming that the original modification to clear the command
>> register does not impact either real controller.
>>
>> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
>> Cc: stable@vger.kernel.org
>> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
>> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
>> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
>> ---
>>
>> V1 -> V2: Don't use rx_buf when clearing command reg
>> V2 -> V3: Modify original 2 xfer command to eliminate dev_err()
>> output on xfer with len and NULL buffers
>>
>> drivers/input/touchscreen/ads7846.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>> index 4b39f7212d35c..488bcc8393293 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -403,8 +403,7 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
>> spi_message_add_tail(&req->xfer[5], &req->msg);
>>
>> /* clear the command register */
>> - req->scratch = 0;
>> - req->xfer[6].tx_buf = &req->scratch;
>> + req->xfer[6].rx_buf = &req->scratch;
>
> Sashiko (I believe correctly) pointed out that by doing this "scratch"
> is now write only and this may cause DMA from the device stomp on
> message status and other unrelated data that shares the same cacheline
> with scracth. While it was already a problem before now it is even more
> likely.
>
> Since scratch is now write-only I believe moving it below "sample"
> forces it into separate cacheline and fixes this problem. Could you
> please try making this change?
Apologies, I'm not quite certain I understand what you mean by
"moving it below sample." Do you mean relocating the xfer[6] block
immediately below the xfer[3] block like so? If yes, I can get this
tested and a v4 patch together. If not, can you please clarify?
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 4b39f7212d35..6d57865ff505 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -390,6 +390,11 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
req->xfer[3].len = 2;
spi_message_add_tail(&req->xfer[3], &req->msg);
+ /* clear the command register */
+ req->xfer[6].rx_buf = &req->scratch;
+ req->xfer[6].len = 1;
+ spi_message_add_tail(&req->xfer[6], &req->msg);
+
/* REVISIT: take a few more samples, and compare ... */
/* converter in low power mode & enable PENIRQ */
@@ -402,12 +407,6 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
req->xfer[5].len = 2;
spi_message_add_tail(&req->xfer[5], &req->msg);
- /* clear the command register */
- req->scratch = 0;
- req->xfer[6].tx_buf = &req->scratch;
- req->xfer[6].len = 1;
- spi_message_add_tail(&req->xfer[6], &req->msg);
-
req->xfer[7].rx_buf = &req->scratch;
req->xfer[7].len = 2;
CS_CHANGE(req->xfer[7]);
>
> Thanks.
>
--
Kris Bahnsen
Software Engineer
embeddedTS
^ permalink raw reply related
* Re: [PATCH v2 4/4] iio: humidity: drop hid_sensor_remove_trigger() using devm API
From: Jonathan Cameron @ 2026-05-05 16:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, Andy Shevchenko, jikos, srinivas.pandruvada,
dlechner, nuno.sa, andy, sakari.ailus, linux-input, linux-iio,
linux-kernel
In-Reply-To: <CAHp75VdzPr+SLCPT85zw6aK8pSueBHr-OFpJ1Vmsow61e8=p4w@mail.gmail.com>
On Fri, 1 May 2026 21:25:35 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Apr 30, 2026 at 10:21 PM Sanjay Chitroda
> <sanjayembeddedse@gmail.com> wrote:
> > On 30 April 2026 1:03:56 am IST, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > >On Wed, Apr 29, 2026 at 11:29:18PM +0530, Sanjay Chitroda wrote:
> > >
> > >> Use devm_hid_sensor_setup_trigger() to automatically release resource
>
> resources
>
> > >> during fail, unbind or removal of driver using devres framework.
>
> failure
>
> > >>
> > >> This simplify the setup, remove goto, avoid manual resource cleanup in
>
> simplifies
> removes
> and avoids
>
> OR
>
> "This is done in a way to simplify..."
>
> > >> teardown path.
>
> ...
>
> > >> + ret = devm_hid_sensor_setup_trigger(&indio_dev->dev, indio_dev, name,
> > >> + &humid_st->common_attributes);
> > >
> > >I believe the first parameter is utterly wrong here.
> > >Or other way around, same issue but in the previous patch.
> > >
> > Thank you Andy for the review comment.
> >
> > It looks in same humidity probe of hid sensor with devm API two device pointer are used &pdev->dev and &indio_dev->dev; ideally all devm should have same parent device for devres resource framework and over here preferable and consistent device should be &pdev->dev;
> >
> > I would first update existing devm_* API to have consistent device and on top of that will use same device in devm conversation.
> >
> > While for gyro change device is consistent as &pdev->dev across all devm API.
>
> The idea is that you have to go deeply understanding the object
> lifetimes for the cases of different device instances along with
> userspace communication channels (all possible ABIs the driver uses).
> With only that the proper parameter may be chosen or even confirmed
> that device managed resources must not be used. Yeah, this is one of
> the downsides of devm_*() APIs.
>
FWIW it's always wrong from a design point of view to use iio_dev->dev
for devm. It works but leaves us open to getting the ordering wrong
as some other stuff (including things you can't necessarily see explicitly
in a driver) will be using the parent device.
Jonathan
^ permalink raw reply
* Re: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and cleanup
From: Jonathan Cameron @ 2026-05-05 16:33 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Sanjay Chitroda, jikos, dlechner, nuno.sa, andy, sakari.ailus,
linux-input, linux-iio, linux-kernel, Zhang Lixu
In-Reply-To: <15509f5e5a6642d2a4b0ccc13bc7d40d3b79f72a.camel@linux.intel.com>
On Fri, 01 May 2026 04:53:38 -0700
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> + Lixu
>
> On Wed, 2026-04-29 at 23:29 +0530, Sanjay Chitroda wrote:
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Key highlights:
> > - Prepare change as pre-requisite for devm conversion for HID IIO
> > drivers by removing redundant argument
> > - Add devm API to setup trigger and clenaup resource using
> > devm_add_action_or_reset()
> > - few sample driver update using devm conversion to auto release
> > resource
> >
>
> devm_* calls are fine but needs tests particularly when forces ISH PCI
> drivers unbind, while iio-sensor-proxy has open sessions.
>
> Lixu, Please check.
Hold off perhaps until we have a v3 with fixes for the existing devm
calls against wrong struct device.
Thanks,
Jonathan
>
> Thanks,
> Srinivas
>
>
>
> > changes in v2:
> > - Following input from Jonathan and Andy, squash initial patch v1
> > series in single change as individual change should not break
> > anything
> > - Add devm API support and two driver using the same
> > - v1 series ->
> > https://lore.kernel.org/all/20260428071613.1134053-1-sanjayembedded@gmail.com/
> >
> > Testing:
> > - Compiled with W=1
> > - Build-tested on QEMU x86_64
> >
> > Based on further feedback and reviews, I would extend this series to
> > convert all HID IIO driver to use devm_* API.
> >
> > Thanks,
> > Sanjay Chitroda
> >
> > Sanjay Chitroda (4):
> > iio: hid-sensors: drop redundant iio_dev argument
> > iio: hid-sensors: introduce device managed API
> > iio: gyro: drop hid_sensor_remove_trigger() using devm API
> > iio: humidity: drop hid_sensor_remove_trigger() using devm API
> >
> > drivers/iio/accel/hid-sensor-accel-3d.c | 4 +--
> > .../common/hid-sensors/hid-sensor-trigger.c | 27
> > +++++++++++++++++--
> > .../common/hid-sensors/hid-sensor-trigger.h | 5 ++--
> > drivers/iio/gyro/hid-sensor-gyro-3d.c | 10 +++----
> > drivers/iio/humidity/hid-sensor-humidity.c | 10 +++----
> > drivers/iio/light/hid-sensor-als.c | 4 +--
> > drivers/iio/light/hid-sensor-prox.c | 4 +--
> > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 4 +--
> > drivers/iio/orientation/hid-sensor-incl-3d.c | 4 +--
> > drivers/iio/orientation/hid-sensor-rotation.c | 4 +--
> > .../position/hid-sensor-custom-intel-hinge.c | 4 +--
> > drivers/iio/pressure/hid-sensor-press.c | 4 +--
> > .../iio/temperature/hid-sensor-temperature.c | 4 +--
> > 13 files changed, 52 insertions(+), 36 deletions(-)
> >
> >
> > base-commit: eade2b843d9b1f668fc1775f15611bb0a1999cd9
^ permalink raw reply
* Re: [PATCH v3] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Dmitry Torokhov @ 2026-05-05 18:10 UTC (permalink / raw)
To: Kris Bahnsen
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <c49600c3-a78d-4d74-82bd-7f95328388a5@embeddedTS.com>
On Tue, May 05, 2026 at 09:21:50AM -0700, Kris Bahnsen wrote:
> Dmitry,
>
> On 5/4/26 8:01 PM, Dmitry Torokhov wrote:
> > Hi Kris,
> >
> > On Thu, Apr 30, 2026 at 05:37:38PM +0000, Kris Bahnsen wrote:
> >> The workaround for XPT2046 clears the command register, giving the
> >> touchscreen controller a NOP. The change incorrectly re-uses the
> >> req->scratch variable which is used as rx_buf for xfer[5], so by
> >> the time xfer[6] occurs, the contents of req->scratch may not be
> >> 0. It was found that the touchscreen controller can end up in
> >> a completely unresponsive state due to it being given a command
> >> the driver does not expect.
> >>
> >> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
> >> transmit all 0 bits and use the scratch variable for the rx_buf for
> >> both the 1 byte command to and 2 byte response from the controller.
> >>
> >> This change was tested on real TSC2046 and ADS7843 controllers,
> >> but not the XPT2046 the workaround was originally created for.
> >> Confirming that the original modification to clear the command
> >> register does not impact either real controller.
> >>
> >> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
> >> Cc: stable@vger.kernel.org
> >> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
> >> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
> >> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
> >> ---
> >>
> >> V1 -> V2: Don't use rx_buf when clearing command reg
> >> V2 -> V3: Modify original 2 xfer command to eliminate dev_err()
> >> output on xfer with len and NULL buffers
> >>
> >> drivers/input/touchscreen/ads7846.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> >> index 4b39f7212d35c..488bcc8393293 100644
> >> --- a/drivers/input/touchscreen/ads7846.c
> >> +++ b/drivers/input/touchscreen/ads7846.c
> >> @@ -403,8 +403,7 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
> >> spi_message_add_tail(&req->xfer[5], &req->msg);
> >>
> >> /* clear the command register */
> >> - req->scratch = 0;
> >> - req->xfer[6].tx_buf = &req->scratch;
> >> + req->xfer[6].rx_buf = &req->scratch;
> >
> > Sashiko (I believe correctly) pointed out that by doing this "scratch"
> > is now write only and this may cause DMA from the device stomp on
> > message status and other unrelated data that shares the same cacheline
> > with scracth. While it was already a problem before now it is even more
> > likely.
> >
> > Since scratch is now write-only I believe moving it below "sample"
> > forces it into separate cacheline and fixes this problem. Could you
> > please try making this change?
>
> Apologies, I'm not quite certain I understand what you mean by
> "moving it below sample." Do you mean relocating the xfer[6] block
> immediately below the xfer[3] block like so? If yes, I can get this
> tested and a v4 patch together. If not, can you please clarify?
I meant doing this:
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 093f4b56cc18..04ba98b62f70 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -328,7 +328,6 @@ struct ser_req {
u8 ref_on;
u8 command;
u8 ref_off;
- u16 scratch;
struct spi_message msg;
struct spi_transfer xfer[8];
/*
@@ -336,6 +335,7 @@ struct ser_req {
* transfer buffers to live in their own cache lines.
*/
__be16 sample ____cacheline_aligned;
+ u16 scratch;
};
struct ads7845_ser_req {
Thanks.
--
Dmitry
^ permalink raw reply related
* Re: [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Rob Herring (Arm) @ 2026-05-05 19:41 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Sen Chu, Matthias Brugger, Mark Brown, Gary Bisson,
AngeloGioacchino Del Regno, Lee Jones, linux-mediatek,
linux-kernel, linux-input, Louis-Alexis Eyraud, linux-arm-kernel,
linux-gpio, devicetree, Julien Massot, Fabien Parent, Macpaul Lin,
Val Packett, Liam Girdwood, Linus Walleij, linux-pm, Sean Wang,
Dmitry Torokhov, Conor Dooley, Akari Tsuyukusa, Chen Zhong,
Krzysztof Kozlowski
In-Reply-To: <20260420213529.1645560-5-l.scorcia@gmail.com>
On Mon, 20 Apr 2026 22:30:03 +0100, Luca Leonardo Scorcia wrote:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
> the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../pinctrl/mediatek,mt65xx-pinctrl.yaml | 1 +
> .../pinctrl/mediatek,mt6392-pinfunc.h | 39 +++++++++++++++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 00/11] Input: support for STM FTS5
From: Dmitry Torokhov @ 2026-05-05 21:54 UTC (permalink / raw)
To: david
Cc: Maxime Coquelin, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg,
Bjorn Andersson, Konrad Dybcio, Petr Hodina, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel, Krzysztof Kozlowski,
devicetree, linux-arm-msm, phone-devel, Konrad Dybcio
In-Reply-To: <20260409-stmfts5-v4-0-64fe62027db5@ixit.cz>
On Thu, Apr 09, 2026 at 12:15:43AM +0200, David Heidelberg via B4 Relay wrote:
> Used on various phones. Minimal viable driver.
>
> Includes device-tree enabling touchscreen on Pixel 3.
>
> What is missing:
> - switching between AP and SLPI mode (to be able to wake up phone by touch)
> - firmware loading
> - anything above basic touch
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied #1 through #8 (#5 with minor edits).
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and cleanup
From: Zhang, Lixu @ 2026-05-06 1:51 UTC (permalink / raw)
To: Jonathan Cameron, srinivas pandruvada
Cc: Sanjay Chitroda, jikos@kernel.org, Lechner, David,
nuno.sa@analog.com, andy@kernel.org, sakari.ailus@linux.intel.com,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260505173302.4284a077@jic23-huawei>
>-----Original Message-----
>From: Jonathan Cameron <jic23@kernel.org>
>Sent: Wednesday, May 6, 2026 12:33 AM
>To: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
>Cc: Sanjay Chitroda <sanjayembeddedse@gmail.com>; jikos@kernel.org;
>Lechner, David <dlechner@baylibre.com>; nuno.sa@analog.com;
>andy@kernel.org; sakari.ailus@linux.intel.com; linux-input@vger.kernel.org;
>linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; Zhang, Lixu
><lixu.zhang@intel.com>
>Subject: Re: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and
>cleanup
>
>On Fri, 01 May 2026 04:53:38 -0700
>srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
>
>> + Lixu
>>
>> On Wed, 2026-04-29 at 23:29 +0530, Sanjay Chitroda wrote:
>> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> >
>> > Key highlights:
>> > - Prepare change as pre-requisite for devm conversion for HID IIO
>> > drivers by removing redundant argument
>> > - Add devm API to setup trigger and clenaup resource using
>> > devm_add_action_or_reset()
>> > - few sample driver update using devm conversion to auto release
>> > resource
>> >
>>
>> devm_* calls are fine but needs tests particularly when forces ISH PCI
>> drivers unbind, while iio-sensor-proxy has open sessions.
>>
>> Lixu, Please check.
>Hold off perhaps until we have a v3 with fixes for the existing devm calls against
>wrong struct device.
Sure, I'll test the ISH unbind scenario once v3 is out.
Thanks,
Lixu
>
>Thanks,
>
>Jonathan
>
>>
>> Thanks,
>> Srinivas
>>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Krzysztof Kozlowski @ 2026-05-06 7:39 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, linux-input, devicetree, linux-kernel
In-Reply-To: <20260503165243.215979-2-clamor95@gmail.com>
On Sun, May 03, 2026 at 07:52:42PM +0300, Svyatoslav Ryhel wrote:
> Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> handheld devices and capable of supporting up to two motors.
>
> The exact datasheet for the ISA1200 is not available; all data was modeled
> based on available downstream kernel sources for various devices and
> fragments of information scattered across the internet.
>
> Tested-by: Linus Walleij <linusw@kernel.org> # Samsung GT-I9070 Janice
Drop the tag here, you cannot test a binding. It's not possible or
otherwise explain how YAML file was tested by this device.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Linus Walleij @ 2026-05-06 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Svyatoslav Ryhel, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260506-nautilus-of-abstract-efficiency-eebe94@quoll>
On Wed, May 6, 2026 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, May 03, 2026 at 07:52:42PM +0300, Svyatoslav Ryhel wrote:
> > Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> > handheld devices and capable of supporting up to two motors.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Tested-by: Linus Walleij <linusw@kernel.org> # Samsung GT-I9070 Janice
>
> Drop the tag here, you cannot test a binding. It's not possible or
> otherwise explain how YAML file was tested by this device.
Right, I was probably sloppy and replied Tested-by on the cover
letter.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Lee Jones @ 2026-05-06 9:16 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260504-wip-fix-core-v3-0-ce1f11f4968f@kernel.org>
On Mon, 04 May 2026, Benjamin Tissoires wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()") enforced the provided data to be at least the size of
> the declared buffer in the report descriptor to prevent a buffer
> overflow.
>
> We only had corner cases of malicious devices exposing the OOM because
> in most cases, the buffer provided by the transport layer needs to be
> allocated at probe time and is large enough to handle all the possible
> reports.
>
> However, the patch from above, which enforces the spec a little bit more
> introduced both regressions for devices not following the spec (not
> necesserally malicious), but also a stream of errors for those devices.
>
> Let's revert to the old behavior by giving more information to HID core
> to be able to decide whether it can or not memset the rest of the buffer
> to 0 and continue the processing.
>
> Note that the first commit makes an API change, but the callers are
> relatively limited, so it should be fine on its own. The second patch
> can't really make the same kind of API change because we have too many
> callers in various subsystems. We can switch them one by one to the safe
> approach when needed.
>
> The last 2 patches are small cleanups I initially put together with the
> 2 first patches, but they can be applied on their own and don't need to
> be pulled in stable like the first 2.
>
> Cheers,
> Benjamin
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> ---
> Changes in v3:
> - fixed ghib -> ghid in greybus
> - fixed i386 size_t debug size reported by kernel-bot
> - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
>
> Changes in v2:
> - added a small blurb explaining the difference between the safe and the
> non safe version of hid_safe_input_report
> - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
>
> ---
> Benjamin Tissoires (4):
> HID: pass the buffer size to hid_report_raw_event
> HID: core: introduce hid_safe_input_report()
> HID: multitouch: use __free(kfree) to clean up temporary buffers
> HID: wacom: use __free(kfree) to clean up temporary buffers
>
> drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> drivers/hid/hid-gfrm.c | 4 +--
> drivers/hid/hid-logitech-hidpp.c | 2 +-
> drivers/hid/hid-multitouch.c | 18 ++++------
> drivers/hid/hid-primax.c | 2 +-
> drivers/hid/hid-vivaldi-common.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> drivers/hid/usbhid/hid-core.c | 11 ++++---
> drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> drivers/staging/greybus/hid.c | 2 +-
> include/linux/hid.h | 6 ++--
> include/linux/hid_bpf.h | 14 +++++---
> 13 files changed, 109 insertions(+), 78 deletions(-)
What's the plan for this set Benjamin? -rcs or -next?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: Fix heap buffer overflow in mcp2221_raw_event()
From: Benoît Sevens @ 2026-05-06 14:40 UTC (permalink / raw)
To: Rishi Gupta, Jiri Kosina, Benjamin Tissoires
Cc: linux-i2c, linux-input, linux-kernel
In-Reply-To: <20260415114752.1181079-1-bsevens@google.com>
Hi,
Just checking in to see if anyone had a chance to look at this patch,
or if there is any feedback I can address.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
From: Rob Herring (Arm) @ 2026-05-06 15:31 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Sen Chu, Macpaul Lin, Sean Wang, Lee Jones, linux-mediatek,
Jonathan Cameron, devicetree, kernel, Nuno Sá, linux-input,
Conor Dooley, David Lechner, AngeloGioacchino Del Regno,
linux-arm-kernel, Chen Zhong, linux-pm, Matthias Brugger,
Dmitry Torokhov, linux-iio, Krzysztof Kozlowski, Andy Shevchenko,
linux-kernel
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-1-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:14 +0200, Louis-Alexis Eyraud wrote:
> The rtc block of MT6359 PMIC is compatible with the one found in MT6358
> but this compatibility was never expressed in the dt-bindings, so add
> the missing compatible string for the rtc subnode.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
From: Rob Herring (Arm) @ 2026-05-06 15:32 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: AngeloGioacchino Del Regno, Dmitry Torokhov, Krzysztof Kozlowski,
kernel, Andy Shevchenko, Conor Dooley, linux-kernel,
Matthias Brugger, Nuno Sá, David Lechner, Macpaul Lin,
linux-iio, linux-pm, Jonathan Cameron, Sean Wang, Sen Chu,
linux-mediatek, linux-arm-kernel, Lee Jones, linux-input,
Chen Zhong, devicetree
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-2-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:15 +0200, Louis-Alexis Eyraud wrote:
> MT6365 PMIC is compatible with MT6359, so add the compatible strings
> for the main and sub devices (regulator, rtc, audio codec).
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
From: Rob Herring (Arm) @ 2026-05-06 15:32 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: linux-iio, Macpaul Lin, Sean Wang, Jonathan Cameron, kernel,
Lee Jones, Dmitry Torokhov, Conor Dooley, linux-kernel,
linux-input, devicetree, Krzysztof Kozlowski, linux-pm,
Nuno Sá, David Lechner, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-kernel, Sen Chu,
linux-mediatek, Andy Shevchenko, Chen Zhong
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-3-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:16 +0200, Louis-Alexis Eyraud wrote:
> Add compatible string for the pmic keys block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> .../bindings/input/mediatek,pmic-keys.yaml | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
From: Rob Herring (Arm) @ 2026-05-06 15:32 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: AngeloGioacchino Del Regno, Dmitry Torokhov, Nuno Sá, kernel,
linux-kernel, devicetree, Chen Zhong, Krzysztof Kozlowski,
linux-arm-kernel, Sen Chu, David Lechner, Jonathan Cameron,
Matthias Brugger, linux-iio, linux-input, Lee Jones,
linux-mediatek, Sean Wang, Andy Shevchenko, linux-pm,
Conor Dooley, Macpaul Lin
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-4-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:17 +0200, Louis-Alexis Eyraud wrote:
> Add compatible string for the AuxADC block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ 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