* Re: [PATCH 2/2] input: touchscreen: novatek-nvt-ts: Add support for NT36672A e7t variant
From: Gianluca Boiano @ 2026-01-22 0:09 UTC (permalink / raw)
To: hdegoede; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <b4113f8c-0fbd-4a96-9cf6-9675f837ac91@kernel.org>
Hi Hans,
Thanks for the suggestion. You're right that removing code is better than
adding more variants.
I've sent v3 which drops the wake_type check entirely, as you suggested.
Gianluca
^ permalink raw reply
* [PATCH 2/2] Input: ili210x - convert to disable_valid_irq scoped guard
From: Marek Vasut @ 2026-01-21 23:23 UTC (permalink / raw)
To: linux-input
Cc: Marek Vasut, Peter Zijlstra (Intel), Cheng-Yang Chou,
Dmitry Torokhov, Frank Li, Geert Uytterhoeven, Jinjie Ruan,
Krzysztof Kozlowski, Marc Zyngier, Sebastian Andrzej Siewior,
Thomas Gleixner, linux-kernel, linux-renesas-soc
In-Reply-To: <20260121232522.154771-1-marek.vasut+renesas@mailbox.org>
Use disable_valid_irq scoped guard to simplify the code and
deduplicate the polling and IRQ driver case. No functional
change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Cheng-Yang Chou <yphbchou0911@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/input/touchscreen/ili210x.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/ili210x.c b/drivers/input/touchscreen/ili210x.c
index 3bf524a6ee204..70abbd675bb01 100644
--- a/drivers/input/touchscreen/ili210x.c
+++ b/drivers/input/touchscreen/ili210x.c
@@ -893,10 +893,7 @@ static ssize_t ili210x_firmware_update_store(struct device *dev,
* the touch controller to disable the IRQs during update, so we have
* to do it this way here.
*/
- if (client->irq > 0) {
- guard(disable_irq)(&client->irq);
- error = ili210x_firmware_update(dev, fwbuf, ac_end, df_end);
- } else {
+ scoped_guard(disable_valid_irq, &client->irq) {
error = ili210x_firmware_update(dev, fwbuf, ac_end, df_end);
}
--
2.51.0
^ permalink raw reply related
* [PATCH 1/2] linux/interrupt.h: allow "guard" notation to disable and reenable IRQ with valid IRQ check
From: Marek Vasut @ 2026-01-21 23:23 UTC (permalink / raw)
To: linux-input
Cc: Marek Vasut, Peter Zijlstra (Intel), Cheng-Yang Chou,
Dmitry Torokhov, Frank Li, Geert Uytterhoeven, Jinjie Ruan,
Krzysztof Kozlowski, Marc Zyngier, Sebastian Andrzej Siewior,
Thomas Gleixner, linux-kernel, linux-renesas-soc
Introduce disable_valid_irq scoped guard. This is an extension
of disable_irq scoped guard, which disables and enables IRQs
around a scope. The disable_valid_irq scoped guard does almost
the same, except it handles the case where IRQ is not valid,
in which case it does not do anything. This is meant to be used
by for example touch controller drivers, which can do both IRQ
driven and polling mode of operation, and this makes their code
slighly simpler.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Cheng-Yang Chou <yphbchou0911@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
include/linux/interrupt.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 00c01b0a43be1..becbeab4a7473 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -242,6 +242,21 @@ extern void irq_wake_thread(unsigned int irq, void *dev_id);
DEFINE_LOCK_GUARD_1(disable_irq, int,
disable_irq(*_T->lock), enable_irq(*_T->lock))
+static inline void disable_valid_irq(unsigned int irq)
+{
+ if (irq > 0)
+ disable_irq(irq);
+}
+
+static inline void enable_valid_irq(unsigned int irq)
+{
+ if (irq > 0)
+ enable_irq(irq);
+}
+
+DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
+ disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
+
extern void disable_nmi_nosync(unsigned int irq);
extern void disable_percpu_nmi(unsigned int irq);
extern void enable_nmi(unsigned int irq);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 3/3] Input: ili210x - add support for polling mode
From: Marek Vasut @ 2026-01-21 23:12 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Conor Dooley, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <tuvidadi4sezm5b3ydvuie6pcxpf7pw2jrysafwdhpmtz6vjxl@o4zqdnjxkaed>
On 1/21/26 11:53 PM, Dmitry Torokhov wrote:
> On Wed, Jan 21, 2026 at 11:42:55PM +0100, Marek Vasut wrote:
>> On 1/21/26 6:23 AM, Dmitry Torokhov wrote:
>>> On Tue, Jan 20, 2026 at 11:50:53PM +0100, Marek Vasut wrote:
>>>> On 1/20/26 7:31 PM, Dmitry Torokhov wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On Sat, Jan 17, 2026 at 01:12:04AM +0100, Marek Vasut wrote:
>>>>>> @@ -860,16 +893,12 @@ static ssize_t ili210x_firmware_update_store(struct device *dev,
>>>>>> * the touch controller to disable the IRQs during update, so we have
>>>>>> * to do it this way here.
>>>>>> */
>>>>>> - scoped_guard(disable_irq, &client->irq) {
>>>>>> - dev_dbg(dev, "Firmware update started, firmware=%s\n", fwname);
>>>>>> -
>>>>>> - ili210x_hardware_reset(priv->reset_gpio);
>>>>>> -
>>>>>> - error = ili210x_do_firmware_update(priv, fwbuf, ac_end, df_end);
>>>>>> -
>>>>>> - ili210x_hardware_reset(priv->reset_gpio);
>>>>>> -
>>>>>> - dev_dbg(dev, "Firmware update ended, error=%i\n", error);
>>>>>> + if (client->irq > 0) {
>>>>>> + scoped_guard(disable_irq, &client->irq) {
>>>>>> + error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
>>>>>> + }
>>>>>
>>>>> You already have a scope here, no need to establish a new one:
>>>>>
>>>>> guard(disable_irq)(&client->irq);
>>>>> error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
>>>>
>>>> This part ^ I do not understand. If there is no IRQ defined in DT, I need to
>>>> call ili210x_firmware_update_noirq() without the guard because I cannot
>>>> disable_irq() with client->irq < 0, else I need to call
>>>> ili210x_firmware_update_noirq() within the scoped_guard() to disable IRQs to
>>>> avoid spurious IRQs that would interfere with the firmware update ?
>>>
>>> You do not need to use scoped_guard() because you already define a scope
>>> in your if statement:
>>>
>>> if (client->irq > 0) {
>>> guard(disable_irq)(&client->irq);
>>> error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
>>> } else {
>>> error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
>>> }
>>>
>>> This is sill a bit awkward. Maybe we could add to interrupt.h
>>
>> Let me do the part above in V5 , and then the part below as a separate
>> follow up patch/series. I already added the later in tree so it won't be
>> lost. Does that work for you ?
>
> It does, thanks.
OK, V5 is out, the disable_valid_interrupt guard part is coming shortly.
^ permalink raw reply
* [PATCH v5 2/2] Input: ili210x - add support for polling mode
From: Marek Vasut @ 2026-01-21 23:06 UTC (permalink / raw)
To: linux-input
Cc: Marek Vasut, Frank Li, Conor Dooley, Dmitry Torokhov, Job Noorman,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260121230736.114623-1-marek.vasut+renesas@mailbox.org>
There are designs incorporating Ilitek ILI2xxx touch controller that
do not connect interrupt pin, for example Waveshare 13.3" DSI display.
To support such systems use polling mode for the input device when I2C
client does not have interrupt assigned to it.
Factor out ili210x_firmware_update_noirq() to allow conditional scoped
guard around this code. The scoped guard has to be applied only in case
the IRQ line is connected, and not applied otherwise.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Job Noorman <job@noorman.info>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Test client->irq > 0 for IRQ presence
V3: - Rebase on dev_err_probe() conversion
- Fix if (client->irq > 0) in ili210x_firmware_update_store()
V4: No change
V5: - Add RB from Frank
- Rename ili210x_firmware_update_noirq() to ili210x_firmware_update()
- Change scoped_guard() to guard()
---
drivers/input/touchscreen/ili210x.c | 75 +++++++++++++++++++++--------
1 file changed, 55 insertions(+), 20 deletions(-)
diff --git a/drivers/input/touchscreen/ili210x.c b/drivers/input/touchscreen/ili210x.c
index 264eee3e61d0a..3bf524a6ee204 100644
--- a/drivers/input/touchscreen/ili210x.c
+++ b/drivers/input/touchscreen/ili210x.c
@@ -327,9 +327,8 @@ static bool ili210x_report_events(struct ili210x *priv, u8 *touchdata)
return contact;
}
-static irqreturn_t ili210x_irq(int irq, void *irq_data)
+static void ili210x_process_events(struct ili210x *priv)
{
- struct ili210x *priv = irq_data;
struct i2c_client *client = priv->client;
const struct ili2xxx_chip *chip = priv->chip;
u8 touchdata[ILI210X_DATA_SIZE] = { 0 };
@@ -356,8 +355,22 @@ static irqreturn_t ili210x_irq(int irq, void *irq_data)
usleep_range(time_delta, time_delta + 1000);
}
} while (!priv->stop && keep_polling);
+}
+
+static irqreturn_t ili210x_irq(int irq, void *irq_data)
+{
+ struct ili210x *priv = irq_data;
+
+ ili210x_process_events(priv);
return IRQ_HANDLED;
+};
+
+static void ili210x_work_i2c_poll(struct input_dev *input)
+{
+ struct ili210x *priv = input_get_drvdata(input);
+
+ ili210x_process_events(priv);
}
static int ili251x_firmware_update_resolution(struct device *dev)
@@ -829,12 +842,32 @@ static int ili210x_do_firmware_update(struct ili210x *priv,
return 0;
}
+static ssize_t ili210x_firmware_update(struct device *dev, const u8 *fwbuf,
+ u16 ac_end, u16 df_end)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ili210x *priv = i2c_get_clientdata(client);
+ const char *fwname = ILI251X_FW_FILENAME;
+ int error;
+
+ dev_dbg(dev, "Firmware update started, firmware=%s\n", fwname);
+
+ ili210x_hardware_reset(priv->reset_gpio);
+
+ error = ili210x_do_firmware_update(priv, fwbuf, ac_end, df_end);
+
+ ili210x_hardware_reset(priv->reset_gpio);
+
+ dev_dbg(dev, "Firmware update ended, error=%i\n", error);
+
+ return error;
+}
+
static ssize_t ili210x_firmware_update_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
struct i2c_client *client = to_i2c_client(dev);
- struct ili210x *priv = i2c_get_clientdata(client);
const char *fwname = ILI251X_FW_FILENAME;
u16 ac_end, df_end;
int error;
@@ -860,16 +893,11 @@ static ssize_t ili210x_firmware_update_store(struct device *dev,
* the touch controller to disable the IRQs during update, so we have
* to do it this way here.
*/
- scoped_guard(disable_irq, &client->irq) {
- dev_dbg(dev, "Firmware update started, firmware=%s\n", fwname);
-
- ili210x_hardware_reset(priv->reset_gpio);
-
- error = ili210x_do_firmware_update(priv, fwbuf, ac_end, df_end);
-
- ili210x_hardware_reset(priv->reset_gpio);
-
- dev_dbg(dev, "Firmware update ended, error=%i\n", error);
+ if (client->irq > 0) {
+ guard(disable_irq)(&client->irq);
+ error = ili210x_firmware_update(dev, fwbuf, ac_end, df_end);
+ } else {
+ error = ili210x_firmware_update(dev, fwbuf, ac_end, df_end);
}
return error ?: count;
@@ -945,9 +973,6 @@ static int ili210x_i2c_probe(struct i2c_client *client)
if (!chip)
return dev_err_probe(&client->dev, -ENODEV, "unknown device model\n");
- if (client->irq <= 0)
- return dev_err_probe(dev, -EINVAL, "No IRQ!\n");
-
reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(reset_gpio))
return PTR_ERR(reset_gpio);
@@ -997,10 +1022,20 @@ static int ili210x_i2c_probe(struct i2c_client *client)
if (error)
return dev_err_probe(dev, error, "Unable to set up slots\n");
- error = devm_request_threaded_irq(dev, client->irq, NULL, ili210x_irq,
- IRQF_ONESHOT, client->name, priv);
- if (error)
- return dev_err_probe(dev, error, "Unable to request touchscreen IRQ\n");
+ input_set_drvdata(input, priv);
+
+ if (client->irq > 0) {
+ error = devm_request_threaded_irq(dev, client->irq, NULL, ili210x_irq,
+ IRQF_ONESHOT, client->name, priv);
+ if (error)
+ return dev_err_probe(dev, error, "Unable to request touchscreen IRQ\n");
+ } else {
+ error = input_setup_polling(input, ili210x_work_i2c_poll);
+ if (error)
+ return dev_err_probe(dev, error, "Could not set up polling mode\n");
+
+ input_set_poll_interval(input, ILI2XXX_POLL_PERIOD);
+ }
error = devm_add_action_or_reset(dev, ili210x_stop, priv);
if (error)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: touchscreen: trivial-touch: Drop 'interrupts' requirement for old Ilitek
From: Marek Vasut @ 2026-01-21 23:06 UTC (permalink / raw)
To: linux-input
Cc: Marek Vasut, Frank Li, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Job Noorman, Krzysztof Kozlowski, Rob Herring,
devicetree, linux-kernel, linux-renesas-soc
The old Ilitek touch controllers V3 and V6 can operate without
interrupt line, in polling mode. Drop the 'interrupts' property
requirement for those four controllers. To avoid overloading the
trivial-touch, fork the old Ilitek V3/V6 touch controller binding
into separate document.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Job Noorman <job@noorman.info>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Fork the Ilitek V3/V6 bindings into separate document
V3: Add RB from Frank
V4: No change
V5: - Move allOf: after required:
- Add RB from Krzysztof
---
.../input/touchscreen/ilitek,ili210x.yaml | 51 +++++++++++++++++++
.../input/touchscreen/trivial-touch.yaml | 4 --
2 files changed, 51 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ilitek,ili210x.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ilitek,ili210x.yaml b/Documentation/devicetree/bindings/input/touchscreen/ilitek,ili210x.yaml
new file mode 100644
index 0000000000000..c47d7752a194c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ilitek,ili210x.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/ilitek,ili210x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI21xx/ILI251x V3/V6 touch screen controller with i2c interface
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+ - Marek Vasut <marek.vasut+renesas@mailbox.org>
+
+properties:
+ compatible:
+ enum:
+ - ilitek,ili210x
+ - ilitek,ili2117
+ - ilitek,ili2120
+ - ilitek,ili251x
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: touchscreen.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2120";
+ reg = <0x41>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
index fa27c6754ca4e..6441d21223caf 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
@@ -23,9 +23,6 @@ properties:
# Hynitron cstxxx series touchscreen controller
- hynitron,cst340
# Ilitek I2C Touchscreen Controller
- - ilitek,ili210x
- - ilitek,ili2117
- - ilitek,ili2120
- ilitek,ili2130
- ilitek,ili2131
- ilitek,ili2132
@@ -33,7 +30,6 @@ properties:
- ilitek,ili2322
- ilitek,ili2323
- ilitek,ili2326
- - ilitek,ili251x
- ilitek,ili2520
- ilitek,ili2521
# MAXI MAX11801 Resistive touch screen controller with i2c interface
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 3/3] Input: ili210x - add support for polling mode
From: Dmitry Torokhov @ 2026-01-21 22:53 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-input, Conor Dooley, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <cd8f71db-c2d1-4c85-8148-83822762a916@mailbox.org>
On Wed, Jan 21, 2026 at 11:42:55PM +0100, Marek Vasut wrote:
> On 1/21/26 6:23 AM, Dmitry Torokhov wrote:
> > On Tue, Jan 20, 2026 at 11:50:53PM +0100, Marek Vasut wrote:
> > > On 1/20/26 7:31 PM, Dmitry Torokhov wrote:
> > > > Hi Marek,
> > > >
> > > > On Sat, Jan 17, 2026 at 01:12:04AM +0100, Marek Vasut wrote:
> > > > > @@ -860,16 +893,12 @@ static ssize_t ili210x_firmware_update_store(struct device *dev,
> > > > > * the touch controller to disable the IRQs during update, so we have
> > > > > * to do it this way here.
> > > > > */
> > > > > - scoped_guard(disable_irq, &client->irq) {
> > > > > - dev_dbg(dev, "Firmware update started, firmware=%s\n", fwname);
> > > > > -
> > > > > - ili210x_hardware_reset(priv->reset_gpio);
> > > > > -
> > > > > - error = ili210x_do_firmware_update(priv, fwbuf, ac_end, df_end);
> > > > > -
> > > > > - ili210x_hardware_reset(priv->reset_gpio);
> > > > > -
> > > > > - dev_dbg(dev, "Firmware update ended, error=%i\n", error);
> > > > > + if (client->irq > 0) {
> > > > > + scoped_guard(disable_irq, &client->irq) {
> > > > > + error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
> > > > > + }
> > > >
> > > > You already have a scope here, no need to establish a new one:
> > > >
> > > > guard(disable_irq)(&client->irq);
> > > > error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
> > >
> > > This part ^ I do not understand. If there is no IRQ defined in DT, I need to
> > > call ili210x_firmware_update_noirq() without the guard because I cannot
> > > disable_irq() with client->irq < 0, else I need to call
> > > ili210x_firmware_update_noirq() within the scoped_guard() to disable IRQs to
> > > avoid spurious IRQs that would interfere with the firmware update ?
> >
> > You do not need to use scoped_guard() because you already define a scope
> > in your if statement:
> >
> > if (client->irq > 0) {
> > guard(disable_irq)(&client->irq);
> > error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
> > } else {
> > error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
> > }
> >
> > This is sill a bit awkward. Maybe we could add to interrupt.h
>
> Let me do the part above in V5 , and then the part below as a separate
> follow up patch/series. I already added the later in tree so it won't be
> lost. Does that work for you ?
It does, thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/3] Input: ili210x - add support for polling mode
From: Marek Vasut @ 2026-01-21 22:42 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Conor Dooley, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <nk5qn7ye44lbtppp2opa273ut7lxkcz7jsw6giagwngiwhg7rr@puexvdzd2ymq>
On 1/21/26 6:23 AM, Dmitry Torokhov wrote:
> On Tue, Jan 20, 2026 at 11:50:53PM +0100, Marek Vasut wrote:
>> On 1/20/26 7:31 PM, Dmitry Torokhov wrote:
>>> Hi Marek,
>>>
>>> On Sat, Jan 17, 2026 at 01:12:04AM +0100, Marek Vasut wrote:
>>>> @@ -860,16 +893,12 @@ static ssize_t ili210x_firmware_update_store(struct device *dev,
>>>> * the touch controller to disable the IRQs during update, so we have
>>>> * to do it this way here.
>>>> */
>>>> - scoped_guard(disable_irq, &client->irq) {
>>>> - dev_dbg(dev, "Firmware update started, firmware=%s\n", fwname);
>>>> -
>>>> - ili210x_hardware_reset(priv->reset_gpio);
>>>> -
>>>> - error = ili210x_do_firmware_update(priv, fwbuf, ac_end, df_end);
>>>> -
>>>> - ili210x_hardware_reset(priv->reset_gpio);
>>>> -
>>>> - dev_dbg(dev, "Firmware update ended, error=%i\n", error);
>>>> + if (client->irq > 0) {
>>>> + scoped_guard(disable_irq, &client->irq) {
>>>> + error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
>>>> + }
>>>
>>> You already have a scope here, no need to establish a new one:
>>>
>>> guard(disable_irq)(&client->irq);
>>> error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
>>
>> This part ^ I do not understand. If there is no IRQ defined in DT, I need to
>> call ili210x_firmware_update_noirq() without the guard because I cannot
>> disable_irq() with client->irq < 0, else I need to call
>> ili210x_firmware_update_noirq() within the scoped_guard() to disable IRQs to
>> avoid spurious IRQs that would interfere with the firmware update ?
>
> You do not need to use scoped_guard() because you already define a scope
> in your if statement:
>
> if (client->irq > 0) {
> guard(disable_irq)(&client->irq);
> error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
> } else {
> error = ili210x_firmware_update_noirq(dev, fwbuf, ac_end, df_end);
> }
>
> This is sill a bit awkward. Maybe we could add to interrupt.h
Let me do the part above in V5 , and then the part below as a separate
follow up patch/series. I already added the later in tree so it won't be
lost. Does that work for you ?
> void __disable_valid_irq(unsigned int irq)
> {
> if (irq > 0)
> disable_irq(irq);
> }
>
> void __enable_valid_irq(unsigned int irq)
> {
> if (irq > 0)
> enable_irq(irq);
> }
>
> DEFINE_LOCK_GUARD_1(disable_valid_irq, int,
> disable_valid_irq(*_T->lock), enable_valid_irq(*_T->lock))
>
> and then we'd be able to keep the driver as is (just adjust the type of
> the original scoped_guard).
>
>>
>>> BTW, not a fan of the "_noirq" suffix... Maybe drop it and add
>>> lockdep_is_held() there?
>>
>> This part I understand even less, how does lockdep play into this ? The
>> scoped_guard() disables and enables IRQs if they are available.
>
> Ah, sorry, brainfart on my part. I got confused by _noirq suffix.
OK
^ permalink raw reply
* Re: [PATCH V3 RESEND 2/2] HID: i2c-hid: elan: Add parade-tc3408 timing
From: Dmitry Torokhov @ 2026-01-21 22:40 UTC (permalink / raw)
To: Langyan Ye, Benjamin Tissoires, Jiri Kosina
Cc: robh, krzk+dt, conor+dt, dianders, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260108063524.742464-3-yelangyan@huaqin.corp-partner.google.com>
On Thu, Jan 08, 2026 at 02:35:24PM +0800, Langyan Ye wrote:
> Parade-tc3408 requires reset to pull down time greater than 10ms,
> so the configuration post_power_delay_ms is 10, and the chipset
> initial time is required to be greater than 300ms,
> so the post_gpio_reset_on_delay_ms is set to 300.
>
> Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
Jiri, Benjamin, another I2C hid with bindings...
> ---
> drivers/hid/i2c-hid/i2c-hid-of-elan.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
> index 0215f217f6d8..2a6548fd234a 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
> @@ -188,11 +188,19 @@ static const struct elan_i2c_hid_chip_data ilitek_ili2901_chip_data = {
> .main_supply_name = "vcc33",
> };
>
> +static const struct elan_i2c_hid_chip_data parade_tc3408_chip_data = {
> + .post_power_delay_ms = 10,
> + .post_gpio_reset_on_delay_ms = 300,
> + .hid_descriptor_address = 0x0001,
> + .main_supply_name = "vcc33",
> +};
> +
> static const struct of_device_id elan_i2c_hid_of_match[] = {
> { .compatible = "elan,ekth6915", .data = &elan_ekth6915_chip_data },
> { .compatible = "elan,ekth6a12nay", .data = &elan_ekth6a12nay_chip_data },
> { .compatible = "ilitek,ili9882t", .data = &ilitek_ili9882t_chip_data },
> { .compatible = "ilitek,ili2901", .data = &ilitek_ili2901_chip_data },
> + { .compatible = "parade,tc3408", .data = ¶de_tc3408_chip_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, elan_i2c_hid_of_match);
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: input: i2c-hid: Introduce FocalTech FT8112
From: Dmitry Torokhov @ 2026-01-21 22:27 UTC (permalink / raw)
To: daniel_peng
Cc: linux-input, LKML, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
devicetree
In-Reply-To: <20251117094041.300083-1-Daniel_Peng@pegatron.corp-partner.google.com>
On Mon, Nov 17, 2025 at 05:40:40PM +0800, daniel_peng@pegatron.corp-partner.google.com wrote:
> From: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
>
> Create new binding file for the FocalTech FT8112 due to
> new touchscreen chip. Confirm its compatible, reg for the
> device via vendor, and set the interrupt and reset gpio
> to map for Skywalker platform.
> FocalTech FT8112 also uses vcc33/vccio power supply.
>
> Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: novatek,nvt-ts: Add nt36672a-e7t-ts compatible
From: Rob Herring @ 2026-01-21 22:10 UTC (permalink / raw)
To: Gianluca Boiano; +Cc: linux-input, devicetree, krzk, dmitry.torokhov
In-Reply-To: <20260121214141.36858-2-morf3089@gmail.com>
On Wed, Jan 21, 2026 at 10:41:39PM +0100, Gianluca Boiano wrote:
> Add compatible string for the Novatek NT36672A e7t touchscreen variant
> found on the Xiaomi Redmi Note 6 Pro (tulip).
>
> This variant uses different chip parameters compared to the standard
> NT36672A, specifically a different wake_type value.
>
> Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Missing Krzysztof's Ack.
> ---
> .../devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
> index bd6a60486d1f..aaa9976bd65e 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
> @@ -17,6 +17,7 @@ properties:
> enum:
> - novatek,nt11205-ts
> - novatek,nt36672a-ts
> + - novatek,nt36672a-e7t-ts
>
> reg:
> maxItems: 1
> --
> 2.52.0
>
^ permalink raw reply
* [PATCH v2 2/2] input: touchscreen: novatek-nvt-ts: Add support for NT36672A e7t variant
From: Gianluca Boiano @ 2026-01-21 21:41 UTC (permalink / raw)
To: linux-input; +Cc: devicetree, krzk, dmitry.torokhov, Gianluca Boiano
In-Reply-To: <20260121214141.36858-1-morf3089@gmail.com>
Add support for the Novatek NT36672A touchscreen variant found on the
Xiaomi Redmi Note 6 Pro (tulip) which uses a different wake_type value
(0x02 instead of 0x01).
The touchscreen was failing to initialize with error -5 due to the
wake_type parameter mismatch during probe. This adds a new chip data
structure for the e7t variant with the correct wake_type value.
Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
---
drivers/input/touchscreen/novatek-nvt-ts.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/touchscreen/novatek-nvt-ts.c b/drivers/input/touchscreen/novatek-nvt-ts.c
index 44b58e0dc1ad..b1c379d87de0 100644
--- a/drivers/input/touchscreen/novatek-nvt-ts.c
+++ b/drivers/input/touchscreen/novatek-nvt-ts.c
@@ -323,9 +323,15 @@ static const struct nvt_ts_i2c_chip_data nvt_nt36672a_ts_data = {
.chip_id = 0x08,
};
+static const struct nvt_ts_i2c_chip_data nvt_nt36672a_e7t_ts_data = {
+ .wake_type = 0x02,
+ .chip_id = 0x08,
+};
+
static const struct of_device_id nvt_ts_of_match[] = {
{ .compatible = "novatek,nt11205-ts", .data = &nvt_nt11205_ts_data },
{ .compatible = "novatek,nt36672a-ts", .data = &nvt_nt36672a_ts_data },
+ { .compatible = "novatek,nt36672a-e7t-ts", .data = &nvt_nt36672a_e7t_ts_data },
{ }
};
MODULE_DEVICE_TABLE(of, nvt_ts_of_match);
@@ -333,6 +339,7 @@ MODULE_DEVICE_TABLE(of, nvt_ts_of_match);
static const struct i2c_device_id nvt_ts_i2c_id[] = {
{ "nt11205-ts", (unsigned long) &nvt_nt11205_ts_data },
{ "nt36672a-ts", (unsigned long) &nvt_nt36672a_ts_data },
+ { "nt36672a-e7t-ts", (unsigned long) &nvt_nt36672a_e7t_ts_data },
{ }
};
MODULE_DEVICE_TABLE(i2c, nvt_ts_i2c_id);
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: input: novatek,nvt-ts: Add nt36672a-e7t-ts compatible
From: Gianluca Boiano @ 2026-01-21 21:41 UTC (permalink / raw)
To: linux-input; +Cc: devicetree, krzk, dmitry.torokhov, Gianluca Boiano
In-Reply-To: <20260121214141.36858-1-morf3089@gmail.com>
Add compatible string for the Novatek NT36672A e7t touchscreen variant
found on the Xiaomi Redmi Note 6 Pro (tulip).
This variant uses different chip parameters compared to the standard
NT36672A, specifically a different wake_type value.
Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
---
.../devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
index bd6a60486d1f..aaa9976bd65e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
@@ -17,6 +17,7 @@ properties:
enum:
- novatek,nt11205-ts
- novatek,nt36672a-ts
+ - novatek,nt36672a-e7t-ts
reg:
maxItems: 1
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/2] input: touchscreen: novatek-nvt-ts: Add NT36672A e7t variant
From: Gianluca Boiano @ 2026-01-21 21:41 UTC (permalink / raw)
To: linux-input; +Cc: devicetree, krzk, dmitry.torokhov, Gianluca Boiano
In-Reply-To: <20260120193600.1089458-1-morf3089@gmail.com>
This series adds support for the Novatek NT36672A touchscreen variant
found on the Xiaomi Redmi Note 6 Pro (tulip).
The e7t variant uses a different wake_type value (0x02 instead of 0x01),
which was causing probe failures with error -5.
Changes in v2:
- Removed Closes: tag referencing downstream repository (Krzysztof)
Gianluca Boiano (2):
dt-bindings: input: novatek,nvt-ts: Add nt36672a-e7t-ts compatible
input: touchscreen: novatek-nvt-ts: Add support for NT36672A e7t
variant
.../bindings/input/touchscreen/novatek,nvt-ts.yaml | 1 +
drivers/input/touchscreen/novatek-nvt-ts.c | 7 +++++++
2 files changed, 8 insertions(+)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 0/5] Input: gpio_decoder - update driver to use modern APIs
From: Dmitry Torokhov @ 2026-01-21 21:05 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-input, linux-kernel
In-Reply-To: <20251113154616.3107676-1-andriy.shevchenko@linux.intel.com>
On Thu, Nov 13, 2025 at 04:44:41PM +0100, Andy Shevchenko wrote:
> Update gpio_decoder driver to use modern in-kernel APIs.
>
> Changelog v2:
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v12 2/3] HID: cp2112: Fwnode Support
From: Danny Kaehn @ 2026-01-21 20:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Andi Shyti,
Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <aSdvv3Qss5oz_o6P@smile.fi.intel.com>
Hi Andy,
Finally was able to perform the last tests needed before sending out
v13, but wanted to close the loop on your final questions from v12:
On Wed, Nov 26, 2025 at 11:23:11PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:32:51PM -0600, Danny Kaehn wrote:
> > On Wed, Nov 26, 2025 at 08:27:19PM +0200, Andy Shevchenko wrote:
> > > On Wed, Nov 26, 2025 at 11:05:25AM -0600, Danny Kaehn wrote:
> > > > For ACPI, the i2c_adapter will use the child with _ADR Zero and the
> > > > gpio_chip will use the child with _ADR One. For DeviceTree, the
> > > > i2c_adapter will use the child with name "i2c", but the gpio_chip
> > > > will share a firmware node with the CP2112.
> > >
> > > Hmm... Is there any explanation why DT decided to go that way?
> >
> > I don't have an explanation, but Rob H. had directed that I make this
> > change in [1].
> >
> > In v11, I then removed that child node for both ACPI and DT, hoping to
> > maintain unity, but you had directed that wouldn't be intuitive for ACPI
> > in [2].
> >
> > Thus, in this v12, I have just entirely split the two, as it seemed
> > unlikely that any compromise to unify the schema between the two
> > firmware languages would be possible for a change/driver this
> > inconsquential to the overall kernel.
>
> Even though, would be nice to try to get a rationale from Rob on this.
> Then we can put it in the commit message to explain. Otherwise it will
> confuse history diggers in the future.
>
Will attempt to see if I can get them to weigh in.
> ...
>
> > > > + device_set_node(&dev->adap.dev,
> > > > + device_get_named_child_node(&hdev->dev, "i2c"));
> > >
> > > Here we bump the reference count, where is it going to be dropped?
> > >
> > > Note, in the other branch (ACPI) the reference count is not bumped in
> > > the current code.
> >
> > Great point, forgot that I had dropped that handling in v9. The old
> > behavior was that the CP2112 driver maintained a reference to each node
> > during the lifetime of the device (and released during probe errors,
> > etc..). I'm still a bit confused as to whether that is correct or not,
> > or if the references should immediately be dropped once they're done
> > being parsed during probe()... My understanding previously was that I
> > should keep the reference count for the child fwnodes for the lifetime
> > of the CP2112, since the pointers to those are stored in the child
> > devices but would usually be managed by the parent bus-level code, does
> > that seem correct?
>
> While there is a (theoretical) possibility to have lifetime of fwnode shorter
> than a device's, I don't think we have or ever will have such a practical
> example. So, assumption is that, the fwnode that struct device holds has
> the same or longer lifetime.
>
> Note, I haven't investigated overlays (DT and ACPI) behaviour. IIRC you
> experimented with ACPI SSDT on this device, perhaps you can try to see
> what happens if there is a confirmed that the above is not only a theoretical
> problem.
>
> TL;DR: I would drop reference count just after we got a respective fwnode.
>
Finally got a chance to test this, attempting to apply SSDT overlays at
runtime via configfs to instantiate an I2C device on the CP2112's I2C
bus. I didn't dig terribly deep, but both with and without the fwnode
reference count bumped, the I2C device instantiation happened as
expected when loading the overlay. I'm sure there's more nuanced cases
and things to dig in here, but seems like leving those references
dropped is the right thing, as you say.
Thanks,
Danny Kaehn
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: milos-fairphone-fp6: Add Hall Effect sensor
From: Dmitry Torokhov @ 2026-01-21 20:06 UTC (permalink / raw)
To: Luca Weiss
Cc: Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, linux-input
In-Reply-To: <DFU439A9HP2H.1Y9OS2OPAXGOI@fairphone.com>
On Wed, Jan 21, 2026 at 09:07:44AM +0100, Luca Weiss wrote:
> On Wed Jan 21, 2026 at 12:05 AM CET, Dmitry Baryshkov wrote:
> > On Mon, Jan 19, 2026 at 04:52:23PM +0100, Luca Weiss wrote:
> >> On Mon Jan 19, 2026 at 3:41 PM CET, Konrad Dybcio wrote:
> >> > On 1/16/26 3:22 PM, Luca Weiss wrote:
> >> >> Add a node for the Hall Effect sensor, used to detect whether the Flip
> >> >> Cover is closed or not.
> >> >>
> >> >> The sensor is powered through vreg_l10b, so let's put a
> >> >> regulator-always-on on that to make sure the sensor gets power.
> >> >
> >> > Is there anything else on L10B? Can we turn it off if the hall sensor
> >> > is e.g. user-disabled?
> >>
> >> It's the voltage source for pull-up of sensor I2C bus (so
> >> ADSP-managed?), DVDD for amplifiers and VDD for a most sensors like
> >> the gyro.
> >>
> >> So realistically, it'll probably be (nearly) always on anyways. And I
> >> don't want to shave another yak by adding vdd support to gpio-keys...
> >
> > Why? If it is exactly what happens on the board: the device producing
> > GPIO events _is_ powered via a vdd. Added Input maintainer / list to cc.
>
> Yes, the hall sensor which is connected to the GPIO on the SoC, has an
> extra VDD input which needs to be on in order for the Hall-effect sensor
> to be on.
>
> See page 133 "HALL" in the center of the page
> https://www.fairphone.com/wp-content/uploads/2025/08/Fairphone-Gen.-6_-Information-on-how-to-repair-dispose-of-and-recycle-EN-NL-FR-DE.pdf
>
> The IC is OCH166AEV4AD where VDD is (as expected) "Power Supply Input":
> https://www.orient-chip.com/Public/Uploads/uploadfile/files/20231014/1OCH166Adatasheet202203221.pdf
If we add regulator support to gpio-keys do we expect it to be
per-gpio/per-key? Or we'd recommend splitting into several instances of
gpio-keys so that there is on set of supplies per gpio-keys device?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: synaptics_i2c - guard polling restart in resume
From: Dmitry Torokhov @ 2026-01-21 20:02 UTC (permalink / raw)
To: Minseong Kim; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <20260121063738.799967-1-ii4gsp@gmail.com>
Hi Minseong,
On Wed, Jan 21, 2026 at 03:37:38PM +0900, Minseong Kim wrote:
> synaptics_i2c_resume() restarts delayed work unconditionally, even when
> the input device is not opened. Guard the polling restart by taking the
> input device mutex and checking input_device_enabled() before re-queuing
> the delayed work.
>
> Fixes: eef3e4cab72ea ("Input: add driver for Synaptics I2C touchpad")
> Cc: stable@vger.kernel.org
> Signed-off-by: Minseong Kim <ii4gsp@gmail.com>
> ---
> drivers/input/mouse/synaptics_i2c.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/synaptics_i2c.c b/drivers/input/mouse/synaptics_i2c.c
> index a0d707e47d93..fc65e28c1b31 100644
> --- a/drivers/input/mouse/synaptics_i2c.c
> +++ b/drivers/input/mouse/synaptics_i2c.c
> @@ -615,13 +615,17 @@ static int synaptics_i2c_resume(struct device *dev)
> int ret;
> struct i2c_client *client = to_i2c_client(dev);
> struct synaptics_i2c *touch = i2c_get_clientdata(client);
> + struct input_dev *input = touch->input;
>
> ret = synaptics_i2c_reset_config(client);
> if (ret)
> return ret;
>
> - mod_delayed_work(system_wq, &touch->dwork,
> + mutex_lock(&input->mutex);
This can be
guard(mutex)(&input->mutex);
> + if (input_device_enabled(input))
> + mod_delayed_work(system_wq, &touch->dwork,
> msecs_to_jiffies(NO_DATA_SLEEP_MSECS));
> + mutex_unlock(&input->mutex);
>
> return 0;
> }
I made the adjustment and applied.
Thanks.
--
Dmitry
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 6cebd8e193d023c2580ca7b4f8b22a60701cb3d4
From: kernel test robot @ 2026-01-21 17:32 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: 6cebd8e193d023c2580ca7b4f8b22a60701cb3d4 Input: serio - complete sizeof(*pointer) conversions
elapsed time: 1231m
configs tested: 196
configs skipped: 4
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-22
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260121 clang-18
arc randconfig-002-20260121 clang-18
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm collie_defconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm mv78xx0_defconfig gcc-15.2.0
arm randconfig-001-20260121 clang-18
arm randconfig-002-20260121 clang-18
arm randconfig-003-20260121 clang-18
arm randconfig-004-20260121 clang-18
arm64 allmodconfig clang-19
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260121 gcc-15.2.0
arm64 randconfig-002-20260121 gcc-15.2.0
arm64 randconfig-003-20260121 gcc-15.2.0
arm64 randconfig-004-20260121 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-20260121 gcc-15.2.0
csky randconfig-002-20260121 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260121 gcc-15.2.0
hexagon randconfig-002-20260121 gcc-15.2.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260121 clang-20
i386 buildonly-randconfig-002-20260121 clang-20
i386 buildonly-randconfig-003-20260121 clang-20
i386 buildonly-randconfig-004-20260121 clang-20
i386 buildonly-randconfig-005-20260121 clang-20
i386 buildonly-randconfig-006-20260121 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260121 clang-20
i386 randconfig-002-20260121 clang-20
i386 randconfig-003-20260121 clang-20
i386 randconfig-004-20260121 clang-20
i386 randconfig-005-20260121 clang-20
i386 randconfig-006-20260121 clang-20
i386 randconfig-007-20260121 clang-20
i386 randconfig-011-20260121 gcc-14
i386 randconfig-012-20260121 gcc-14
i386 randconfig-013-20260121 gcc-14
i386 randconfig-014-20260121 gcc-14
i386 randconfig-015-20260121 gcc-14
i386 randconfig-016-20260121 gcc-14
i386 randconfig-017-20260121 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260121 gcc-15.2.0
loongarch randconfig-002-20260121 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
m68k m5272c3_defconfig gcc-15.2.0
m68k mvme16x_defconfig gcc-15.2.0
m68k q40_defconfig gcc-15.2.0
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
nios2 allmodconfig clang-22
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260121 gcc-15.2.0
nios2 randconfig-002-20260121 gcc-15.2.0
openrisc allmodconfig clang-22
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260121 gcc-9.5.0
parisc randconfig-002-20260121 gcc-9.5.0
parisc64 alldefconfig gcc-15.2.0
parisc64 defconfig clang-19
powerpc adder875_defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc kmeter1_defconfig gcc-15.2.0
powerpc linkstation_defconfig gcc-15.2.0
powerpc ps3_defconfig gcc-15.2.0
powerpc randconfig-001-20260121 gcc-9.5.0
powerpc randconfig-002-20260121 gcc-9.5.0
powerpc64 randconfig-001-20260121 gcc-9.5.0
powerpc64 randconfig-002-20260121 gcc-9.5.0
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260121 clang-16
riscv randconfig-002-20260121 clang-16
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260121 clang-16
s390 randconfig-002-20260121 clang-16
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh apsh4a3a_defconfig gcc-15.2.0
sh defconfig gcc-14
sh j2_defconfig gcc-15.2.0
sh randconfig-001-20260121 clang-16
sh randconfig-002-20260121 clang-16
sh se7343_defconfig gcc-15.2.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260121 gcc-8.5.0
sparc randconfig-002-20260121 gcc-8.5.0
sparc sparc64_defconfig gcc-15.2.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260121 gcc-8.5.0
sparc64 randconfig-002-20260121 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260121 gcc-8.5.0
um randconfig-002-20260121 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260121 clang-20
x86_64 buildonly-randconfig-002-20260121 clang-20
x86_64 buildonly-randconfig-003-20260121 clang-20
x86_64 buildonly-randconfig-004-20260121 clang-20
x86_64 buildonly-randconfig-005-20260121 clang-20
x86_64 buildonly-randconfig-006-20260121 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260121 clang-20
x86_64 randconfig-002-20260121 clang-20
x86_64 randconfig-003-20260121 clang-20
x86_64 randconfig-004-20260121 clang-20
x86_64 randconfig-005-20260121 clang-20
x86_64 randconfig-006-20260121 clang-20
x86_64 randconfig-011-20260121 gcc-14
x86_64 randconfig-012-20260121 gcc-14
x86_64 randconfig-013-20260121 gcc-14
x86_64 randconfig-014-20260121 gcc-14
x86_64 randconfig-015-20260121 gcc-14
x86_64 randconfig-016-20260121 gcc-14
x86_64 randconfig-071-20260121 clang-20
x86_64 randconfig-072-20260121 clang-20
x86_64 randconfig-073-20260121 clang-20
x86_64 randconfig-074-20260121 clang-20
x86_64 randconfig-075-20260121 clang-20
x86_64 randconfig-076-20260121 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-22
xtensa allyesconfig clang-22
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260121 gcc-8.5.0
xtensa randconfig-002-20260121 gcc-8.5.0
xtensa smp_lx200_defconfig gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] Add common hall sensor drivers
From: Dmitry Torokhov @ 2026-01-21 17:27 UTC (permalink / raw)
To: Linus Walleij; +Cc: 756271518, brgl, linux-kernel, linux-input, linux-gpio
In-Reply-To: <CAD++jLnSXPhqnTie9U03B7mn2x9ogUpABBLFwbt9dgtzdb3yNQ@mail.gmail.com>
On Wed, Jan 21, 2026 at 12:43:01PM +0100, Linus Walleij wrote:
> Hi Xuchen,
>
> thanks for your patch!
>
> On Wed, Jan 21, 2026 at 9:59 AM <756271518@qq.com> wrote:
>
> > From: xuchen <756271518@qq.com>
> >
> > This patch adds support for common hall sensor ICs used in Qualcomm
> > reference designs. The driver handles both rising and falling edges
> > to detect magnetic field changes.
> >
> > Signed-off-by: xuchen <756271518@qq.com>
>
> Why are you going to such lengths to create this driver?
>
> What people do is usually just create a GPIO "key" input
> for the hall sensor, for example:
>
> gpio_keys {
> compatible = "gpio-keys";
> #address-cells = <1>;
> #size-cells = <0>;
> vdd-supply = <&ab8500_ldo_aux1_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&hall_tvk_mode>;
>
> button@145 {
> /* Hall sensor */
> gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
> linux,code = <0>; /* SW_LID */
> label = "HED54XXU11 Hall Effect Sensor";
> };
> };
>
> This turns the GPIO line into a "lid switch" which is what you want,
> and already supports regulators and pin control out of the box if
> you need them too. (The VDD and pin control properties are optional.)
Right, we do not need a custom driver for that (especially one using
legacy APIs and custom event codes and defining special classes).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 02/16] HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
From: Mark Pearson @ 2026-01-21 16:44 UTC (permalink / raw)
To: Derek J . Clark, Jiri Kosina
Cc: Benjamin Tissoires, Limonciello, Mario, Zhixin Zhang, Mia Shao,
Pierre-Loup A . Griffais, linux-input, linux-doc, linux-kernel
In-Reply-To: <8693204A-60AF-48CF-B453-446ABADDA46C@gmail.com>
On Wed, Jan 21, 2026, at 8:16 AM, Derek J. Clark wrote:
> On January 21, 2026 1:08:18 AM PST, Jiri Kosina <jikos@kernel.org> wrote:
>>On Mon, 12 Jan 2026, Mark Pearson wrote:
>>
>>> >>I am now almost finished with reviewing this pile and am planning to queue
>>> >>it in hid.git shortly, but I have a question regarding the MAINTAINERS
>>> >>entry above.
>>> >>
>>> >>The title claims support for all of Lenovo HID, but there is much more to
>>> >>it than drivers/hid/hid-lenovo-go.c, specifically in hid-lenovo.c.
>>> >>
>>> >>So either please make the title more specific (or claim the ownership of
>>> >>the whole Lenovo HID landscape indeed, fine by me, but the please reflect
>>> >>that in F: :) ).
>>> >>
>>> >>Thanks,
>>> >>
>>> >
>>> > Hi Jiri
>>> >
>>> > Sure, I've debated using LENOVO LEGION GO HID drivers and LENOVO GO HID
>>> > drivers. Do you have a preference?
>>
>>Either works, as far as I am concerned.
>>
>>> > The other drivers are pretty old and I don't have any hardware that
>>> > would use them so I'd prefer to keep them separate (though I'll
>>> > acknowledge that they don't seem to have a MAINTAINERS entry)
>>> >
>>> I should probably take a better look at the lenovo-hid driver.
>>>
>>> The platforms that it's supporting weren't in the Linux program, so it
>>> never crossed my path before - but looking ahead I think we may need to
>>> contribute some changes there (guessing a little, but I'll know in a few
>>> months time).
>>>
>>> Jiri - as that driver is targeted for Thinkpads, I'm OK to take some
>>> responsibility for it if that is useful/helpful.
>>
>>Perfect, could you please then either send that as a followup patch, or
>>even have it included right as part of Derek's series?
>>
>
> If Mark is okay with it I'll just add him and that driver to the same entry.
>
No problem for me.
I always feel my reviews are limited, but I do try and read everything and help wherever I can.
Mark
^ permalink raw reply
* Re: [PATCH v2 00/11] HID: Use pm_*ptr instead of #ifdef CONFIG_PM*
From: Jiri Kosina @ 2026-01-21 14:00 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20260113092546.265734-1-hadess@hadess.net>
On Tue, 13 Jan 2026, Bastien Nocera wrote:
> Changes since v1:
> - Fixed most patches to build
> - Removed surface patch
>
> All changes were compiled successfully with CONFIG_PM disabled.
>
> Bastien Nocera (11):
> HID: hid-alps: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: appletb-kbd: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: asus: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: lenovo: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: logitech-dj: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: nintendo: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: picolcd_core: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: hid-sensor-hub: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: uclogic: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: wacom: Use pm_ptr instead of #ifdef CONFIG_PM
> HID: sony: Use pm_ptr instead of #ifdef CONFIG_PM
Now queued in hid.git#for-6.20/pm_ptr-v2.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 02/16] HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
From: Derek J. Clark @ 2026-01-21 13:16 UTC (permalink / raw)
To: Jiri Kosina, Mark Pearson
Cc: Benjamin Tissoires, Limonciello, Mario, Zhixin Zhang, Mia Shao,
Pierre-Loup A . Griffais, linux-input, linux-doc, linux-kernel
In-Reply-To: <24on5sn2-2726-84q2-635q-9245n343qqrp@xreary.bet>
On January 21, 2026 1:08:18 AM PST, Jiri Kosina <jikos@kernel.org> wrote:
>On Mon, 12 Jan 2026, Mark Pearson wrote:
>
>> >>I am now almost finished with reviewing this pile and am planning to queue
>> >>it in hid.git shortly, but I have a question regarding the MAINTAINERS
>> >>entry above.
>> >>
>> >>The title claims support for all of Lenovo HID, but there is much more to
>> >>it than drivers/hid/hid-lenovo-go.c, specifically in hid-lenovo.c.
>> >>
>> >>So either please make the title more specific (or claim the ownership of
>> >>the whole Lenovo HID landscape indeed, fine by me, but the please reflect
>> >>that in F: :) ).
>> >>
>> >>Thanks,
>> >>
>> >
>> > Hi Jiri
>> >
>> > Sure, I've debated using LENOVO LEGION GO HID drivers and LENOVO GO HID
>> > drivers. Do you have a preference?
>
>Either works, as far as I am concerned.
>
>> > The other drivers are pretty old and I don't have any hardware that
>> > would use them so I'd prefer to keep them separate (though I'll
>> > acknowledge that they don't seem to have a MAINTAINERS entry)
>> >
>> I should probably take a better look at the lenovo-hid driver.
>>
>> The platforms that it's supporting weren't in the Linux program, so it
>> never crossed my path before - but looking ahead I think we may need to
>> contribute some changes there (guessing a little, but I'll know in a few
>> months time).
>>
>> Jiri - as that driver is targeted for Thinkpads, I'm OK to take some
>> responsibility for it if that is useful/helpful.
>
>Perfect, could you please then either send that as a followup patch, or
>even have it included right as part of Derek's series?
>
If Mark is okay with it I'll just add him and that driver to the same entry.
I'll wait a few days to send a v2 in case there's additional input.
Thanks,
Derek
>Thanks,
>
^ permalink raw reply
* Re: [PATCH 2/2] input: touchscreen: novatek-nvt-ts: Add support for NT36672A e7t variant
From: Hans de Goede @ 2026-01-21 12:04 UTC (permalink / raw)
To: Gianluca Boiano
Cc: dmitry.torokhov, robh, krzk+dt, conor+dt, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260120193600.1089458-2-morf3089@gmail.com>
Hi Gianluca,
On 20-Jan-26 20:36, Gianluca Boiano wrote:
> Add support for the Novatek NT36672A touchscreen variant found on the
> Xiaomi Redmi Note 6 Pro (tulip) which uses a different wake_type value
> (0x02 instead of 0x01).
>
> The touchscreen was failing to initialize with error -5 due to the
> wake_type parameter mismatch during probe. This adds a new chip data
> structure for the e7t variant with the correct wake_type value.
>
> Closes: https://github.com/sdm660-mainline/linux/issues/155
> Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Thank you for your patch.
I don't think that adding a new compatible + a new nvt_ts_i2c_chip_data
struct is the right approach here.
I guess the wake-type byte simply encodes some IRQ config settings,
which may indeed be different in different applications using
the some touchscreen controller.
Instead of adding a new compatible my suggestion to fix this would
be to simply drop the wake_type check as well as drop the wake_type
member from struct nvt_ts_i2c_chip_data.
This way you can fix the driver not working on the Xiaomi Redmi
Note 6 Pro by removing code instead of adding code :)
And supporting other models also becomes easier.
Regards,
Hans
> ---
> drivers/input/touchscreen/novatek-nvt-ts.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/touchscreen/novatek-nvt-ts.c b/drivers/input/touchscreen/novatek-nvt-ts.c
> index 44b58e0dc1ad..b1c379d87de0 100644
> --- a/drivers/input/touchscreen/novatek-nvt-ts.c
> +++ b/drivers/input/touchscreen/novatek-nvt-ts.c
> @@ -323,9 +323,15 @@ static const struct nvt_ts_i2c_chip_data nvt_nt36672a_ts_data = {
> .chip_id = 0x08,
> };
>
> +static const struct nvt_ts_i2c_chip_data nvt_nt36672a_e7t_ts_data = {
> + .wake_type = 0x02,
> + .chip_id = 0x08,
> +};
> +
> static const struct of_device_id nvt_ts_of_match[] = {
> { .compatible = "novatek,nt11205-ts", .data = &nvt_nt11205_ts_data },
> { .compatible = "novatek,nt36672a-ts", .data = &nvt_nt36672a_ts_data },
> + { .compatible = "novatek,nt36672a-e7t-ts", .data = &nvt_nt36672a_e7t_ts_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, nvt_ts_of_match);
> @@ -333,6 +339,7 @@ MODULE_DEVICE_TABLE(of, nvt_ts_of_match);
> static const struct i2c_device_id nvt_ts_i2c_id[] = {
> { "nt11205-ts", (unsigned long) &nvt_nt11205_ts_data },
> { "nt36672a-ts", (unsigned long) &nvt_nt36672a_ts_data },
> + { "nt36672a-e7t-ts", (unsigned long) &nvt_nt36672a_e7t_ts_data },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, nvt_ts_i2c_id);
^ permalink raw reply
* Re: [PATCH] Add common hall sensor drivers
From: Linus Walleij @ 2026-01-21 11:43 UTC (permalink / raw)
To: 756271518; +Cc: dmitry.torokhov, brgl, linux-kernel, linux-input, linux-gpio
In-Reply-To: <tencent_3AC818B2FE367BA7DD8940E08827CB146806@qq.com>
Hi Xuchen,
thanks for your patch!
On Wed, Jan 21, 2026 at 9:59 AM <756271518@qq.com> wrote:
> From: xuchen <756271518@qq.com>
>
> This patch adds support for common hall sensor ICs used in Qualcomm
> reference designs. The driver handles both rising and falling edges
> to detect magnetic field changes.
>
> Signed-off-by: xuchen <756271518@qq.com>
Why are you going to such lengths to create this driver?
What people do is usually just create a GPIO "key" input
for the hall sensor, for example:
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
vdd-supply = <&ab8500_ldo_aux1_reg>;
pinctrl-names = "default";
pinctrl-0 = <&hall_tvk_mode>;
button@145 {
/* Hall sensor */
gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
linux,code = <0>; /* SW_LID */
label = "HED54XXU11 Hall Effect Sensor";
};
};
This turns the GPIO line into a "lid switch" which is what you want,
and already supports regulators and pin control out of the box if
you need them too. (The VDD and pin control properties are optional.)
Yours,
Linus Walleij
^ 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