* [PATCH] Add common hall sensor drivers
From: 756271518 @ 2026-01-21 8:59 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linusw, brgl, linux-kernel, linux-input, linux-gpio, xuchen
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>
---
drivers/input/keyboard/pogo_switch.c | 323 +++++++++++++++++++++++++++
1 file changed, 323 insertions(+)
create mode 100644 drivers/input/keyboard/pogo_switch.c
diff --git a/drivers/input/keyboard/pogo_switch.c b/drivers/input/keyboard/pogo_switch.c
new file mode 100644
index 000000000000..ea91037caeb3
--- /dev/null
+++ b/drivers/input/keyboard/pogo_switch.c
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Pogo switch/hall sensor driver
+ *
+ * Copyright (c) 2024 faiot.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/sched.h>
+#include <linux/pm.h>
+#include <linux/slab.h>
+#include <linux/sysctl.h>
+#include <linux/proc_fs.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/input.h>
+#include <linux/gpio_keys.h>
+#include <linux/workqueue.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/spinlock.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+
+#define LID_DEV_NAME "hall_sensor"
+#define HALL_INPUT "/dev/input/hall_dev"
+#define KEY_HALL 84
+
+struct hall_data {
+ int gpio; /* device use gpio number */
+ int irq; /* device request irq number */
+ int active_low; /* gpio active high or low for valid value */
+ bool wakeup; /* device can wakeup system or not */
+ struct input_dev *hall_dev;
+ struct device *dev;
+ int detect_irq;
+ struct workqueue_struct *hall_wq;
+ struct delayed_work hall_debounce_work_det;
+};
+
+static struct hall_data *p_hall_data;
+static struct class extbd_ctrl_class;
+static int g_extbd_status;
+
+static void hall_driver_remove(struct platform_device *dev);
+
+static int hall_parse_dt(struct device *dev, struct hall_data *data)
+{
+ struct device_node *np = dev->of_node;
+
+ data->gpio = of_get_named_gpio(np, "faiot,hall-int", 0);
+ if (!gpio_is_valid(data->gpio)) {
+ dev_err(dev, "hall gpio is not valid\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static irqreturn_t hall_interrupt_handler(int irq, void *dev)
+{
+ if (p_hall_data == NULL || p_hall_data->hall_wq == NULL) {
+ pr_err("zy : irq resource not rdy\n");
+ return IRQ_HANDLED;
+ }
+
+ queue_delayed_work(p_hall_data->hall_wq,
+ &p_hall_data->hall_debounce_work_det,
+ msecs_to_jiffies(50));
+ return IRQ_HANDLED;
+}
+
+static void hall_det_debounce_work_func(struct work_struct *work)
+{
+ int value;
+
+ value = (gpio_get_value_cansleep(p_hall_data->gpio) ? 1 : 0) ^
+ p_hall_data->active_low;
+ if (value) {
+ input_report_key(p_hall_data->hall_dev, KEY_HALL, 0);
+ input_sync(p_hall_data->hall_dev);
+ dev_info(&p_hall_data->hall_dev->dev,
+ "hall_interrupt_handler near\n");
+ } else {
+ input_report_key(p_hall_data->hall_dev, KEY_HALL, 1);
+ input_sync(p_hall_data->hall_dev);
+ dev_info(&p_hall_data->hall_dev->dev,
+ "hall_interrupt_handler far\n");
+ }
+}
+
+static int hall_input_init(struct platform_device *pdev,
+ struct hall_data *data)
+{
+ int err;
+
+ data->hall_dev = devm_input_allocate_device(&pdev->dev);
+ if (!data->hall_dev) {
+ dev_err(&pdev->dev, "input device allocation failed\n");
+ return -EINVAL;
+ }
+
+ data->hall_dev->name = LID_DEV_NAME;
+ data->hall_dev->phys = HALL_INPUT;
+ set_bit(EV_KEY, data->hall_dev->evbit);
+ set_bit(KEY_HALL, data->hall_dev->keybit);
+
+ err = input_register_device(data->hall_dev);
+ if (err < 0) {
+ dev_err(&pdev->dev, "unable to register input device %s\n",
+ LID_DEV_NAME);
+ return err;
+ }
+
+ return 0;
+}
+
+static ssize_t extbd_status_store(const struct class *c,
+ const struct class_attribute *attr,
+ const char *buf, size_t count)
+{
+ if (kstrtoint(buf, 0, &g_extbd_status))
+ return -EINVAL;
+
+ return count;
+}
+
+static ssize_t extbd_status_show(const struct class *c,
+ const struct class_attribute *attr,
+ char *buf)
+{
+ g_extbd_status = (gpio_get_value_cansleep(p_hall_data->gpio) ? 1 : 0) ^
+ p_hall_data->active_low;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", g_extbd_status);
+}
+
+static CLASS_ATTR_RW(extbd_status);
+
+static struct attribute *extbd_ctrl_class_attrs[] = {
+ &class_attr_extbd_status.attr,
+ NULL,
+};
+
+ATTRIBUTE_GROUPS(extbd_ctrl_class);
+
+static int hall_driver_probe(struct platform_device *dev)
+{
+ struct hall_data *data;
+ int err;
+ int irq_flags;
+
+ dev_info(&dev->dev, "hall_driver probe\n");
+
+ data = devm_kzalloc(&dev->dev, sizeof(struct hall_data), GFP_KERNEL);
+ if (data == NULL) {
+ err = -ENOMEM;
+ dev_err(&dev->dev, "failed to allocate memory %d\n", err);
+ goto exit;
+ }
+
+ data->dev = &dev->dev;
+ dev_set_drvdata(&dev->dev, data);
+
+ err = hall_parse_dt(&dev->dev, data);
+ if (err < 0) {
+ dev_err(&dev->dev, "Failed to parse device tree\n");
+ goto exit;
+ }
+
+ err = hall_input_init(dev, data);
+ if (err < 0) {
+ dev_err(&dev->dev, "input init failed\n");
+ goto exit;
+ }
+
+ if (!gpio_is_valid(data->gpio)) {
+ dev_err(&dev->dev, "gpio is not valid\n");
+ err = -EINVAL;
+ goto free_gpio;
+ }
+
+ irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
+ err = gpio_request_one(data->gpio, GPIOF_IN, "hall_sensor_irq");
+ if (err) {
+ dev_err(&dev->dev, "unable to request gpio %d\n", data->gpio);
+ goto exit;
+ }
+
+ data->irq = gpio_to_irq(data->gpio);
+ err = devm_request_threaded_irq(&dev->dev, data->irq, NULL,
+ hall_interrupt_handler,
+ irq_flags, "hall_sensor", data);
+ if (err < 0)
+ goto free_irq;
+
+ data->hall_wq = create_singlethread_workqueue("hall_wq");
+ if (!data->hall_wq)
+ return -EINVAL;
+
+ INIT_DELAYED_WORK(&data->hall_debounce_work_det,
+ hall_det_debounce_work_func);
+
+ /*
+ * err = sysfs_create_group(&data->dev->kobj, &hall_attr_group);
+ * if (err) {
+ * printk(KERN_ERR "%s sysfs_create_group fail\n", __func__);
+ * return err;
+ * }
+ */
+
+ extbd_ctrl_class.name = "extbd_ctrl";
+ extbd_ctrl_class.class_groups = extbd_ctrl_class_groups;
+ err = class_register(&extbd_ctrl_class);
+ if (err < 0)
+ dev_err(&dev->dev, "Failed to create extbd_ctrl_class rc=%d\n",
+ err);
+
+ p_hall_data = data;
+ device_init_wakeup(&dev->dev, data->wakeup);
+ enable_irq_wake(data->irq);
+
+ dev_info(&dev->dev, "guh hall probe end");
+
+ return 0;
+
+free_irq:
+ disable_irq_wake(data->irq);
+ device_init_wakeup(&dev->dev, 0);
+free_gpio:
+ gpio_free(data->gpio);
+exit:
+ return err;
+}
+
+static void hall_driver_remove(struct platform_device *dev)
+{
+ struct hall_data *data = dev_get_drvdata(&dev->dev);
+
+ disable_irq_wake(data->irq);
+ device_init_wakeup(&dev->dev, 0);
+ if (data->gpio)
+ gpio_free(data->gpio);
+}
+
+static int hall_driver_suspend(struct platform_device *dev,
+ pm_message_t state)
+{
+ /*
+ * struct hall_data *data = dev_get_drvdata(&dev->dev);
+ * gpio_direction_output(data->extbd_power, 0);
+ */
+
+ return 0;
+}
+
+static int hall_driver_resume(struct platform_device *dev)
+{
+ /*
+ * struct hall_data *data = dev_get_drvdata(&dev->dev);
+ * gpio_direction_output(data->extbd_power, 1);
+ */
+
+ return 0;
+}
+
+static struct platform_device_id hall_id[] = {
+ { LID_DEV_NAME, 0 },
+ { },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id hall_match_table[] = {
+ { .compatible = "hall-switch", },
+ { },
+};
+#endif
+
+static struct platform_driver hall_driver = {
+ .driver = {
+ .name = LID_DEV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(hall_match_table),
+ },
+ .probe = hall_driver_probe,
+ .remove = hall_driver_remove,
+ .suspend = hall_driver_suspend,
+ .resume = hall_driver_resume,
+ .id_table = hall_id,
+};
+
+static int __init hall_init(void)
+{
+ return platform_driver_register(&hall_driver);
+}
+
+static void __exit hall_exit(void)
+{
+ platform_driver_unregister(&hall_driver);
+}
+
+module_init(hall_init);
+module_exit(hall_exit);
+
+MODULE_DESCRIPTION("Hall sensor driver");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [PATCH v6 2/2] HID: i2c-hid: Add FocalTech FT8112
From: Jiri Kosina @ 2026-01-21 9:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: daniel_peng, Benjamin Tissoires, linux-input, LKML,
Douglas Anderson, Pin-yen Lin
In-Reply-To: <eb47h436johngo3bz5b5cn6tyvwqoplg55uhk2siftxk6n547n@4rgwokhtrcec>
On Tue, 20 Jan 2026, Dmitry Torokhov wrote:
> On Mon, Nov 17, 2025 at 05:40:41PM +0800, daniel_peng@pegatron.corp-partner.google.com wrote:
> > From: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
> >
> > Information for touchscreen model HKO/RB116AS01-2 as below:
> > - HID :FTSC1000
> > - slave address:0X38
> > - Interface:HID over I2C
> > - Touch control lC:FT8112
> > - I2C ID: PNP0C50
> >
> > Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
>
> Jiri, Benjamin, do you want to take it (and the binding) through the HID
> tree or should I take it through input?
Acked-by: Jiri Kosina <jkosina@suse.com>
feel free to take it through input.git to make it easier.
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: Jiri Kosina @ 2026-01-21 9:08 UTC (permalink / raw)
To: Mark Pearson
Cc: Derek J . Clark, Benjamin Tissoires, Limonciello, Mario,
Zhixin Zhang, Mia Shao, Pierre-Loup A . Griffais, linux-input,
linux-doc, linux-kernel
In-Reply-To: <2910bb2e-6b31-42f3-a3de-463327b16ff1@app.fastmail.com>
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?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] Add common hall sensor drivers
From: 756271518 @ 2026-01-21 9:10 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linusw, brgl, linux-kernel, linux-input, linux-gpio, xuchen
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>
---
drivers/input/keyboard/pogo_switch.c | 323 +++++++++++++++++++++++++++
1 file changed, 323 insertions(+)
create mode 100644 drivers/input/keyboard/pogo_switch.c
diff --git a/drivers/input/keyboard/pogo_switch.c b/drivers/input/keyboard/pogo_switch.c
new file mode 100644
index 000000000000..ea91037caeb3
--- /dev/null
+++ b/drivers/input/keyboard/pogo_switch.c
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Pogo switch/hall sensor driver
+ *
+ * Copyright (c) 2024 faiot.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/sched.h>
+#include <linux/pm.h>
+#include <linux/slab.h>
+#include <linux/sysctl.h>
+#include <linux/proc_fs.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/input.h>
+#include <linux/gpio_keys.h>
+#include <linux/workqueue.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/spinlock.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+
+#define LID_DEV_NAME "hall_sensor"
+#define HALL_INPUT "/dev/input/hall_dev"
+#define KEY_HALL 84
+
+struct hall_data {
+ int gpio; /* device use gpio number */
+ int irq; /* device request irq number */
+ int active_low; /* gpio active high or low for valid value */
+ bool wakeup; /* device can wakeup system or not */
+ struct input_dev *hall_dev;
+ struct device *dev;
+ int detect_irq;
+ struct workqueue_struct *hall_wq;
+ struct delayed_work hall_debounce_work_det;
+};
+
+static struct hall_data *p_hall_data;
+static struct class extbd_ctrl_class;
+static int g_extbd_status;
+
+static void hall_driver_remove(struct platform_device *dev);
+
+static int hall_parse_dt(struct device *dev, struct hall_data *data)
+{
+ struct device_node *np = dev->of_node;
+
+ data->gpio = of_get_named_gpio(np, "faiot,hall-int", 0);
+ if (!gpio_is_valid(data->gpio)) {
+ dev_err(dev, "hall gpio is not valid\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static irqreturn_t hall_interrupt_handler(int irq, void *dev)
+{
+ if (p_hall_data == NULL || p_hall_data->hall_wq == NULL) {
+ pr_err("zy : irq resource not rdy\n");
+ return IRQ_HANDLED;
+ }
+
+ queue_delayed_work(p_hall_data->hall_wq,
+ &p_hall_data->hall_debounce_work_det,
+ msecs_to_jiffies(50));
+ return IRQ_HANDLED;
+}
+
+static void hall_det_debounce_work_func(struct work_struct *work)
+{
+ int value;
+
+ value = (gpio_get_value_cansleep(p_hall_data->gpio) ? 1 : 0) ^
+ p_hall_data->active_low;
+ if (value) {
+ input_report_key(p_hall_data->hall_dev, KEY_HALL, 0);
+ input_sync(p_hall_data->hall_dev);
+ dev_info(&p_hall_data->hall_dev->dev,
+ "hall_interrupt_handler near\n");
+ } else {
+ input_report_key(p_hall_data->hall_dev, KEY_HALL, 1);
+ input_sync(p_hall_data->hall_dev);
+ dev_info(&p_hall_data->hall_dev->dev,
+ "hall_interrupt_handler far\n");
+ }
+}
+
+static int hall_input_init(struct platform_device *pdev,
+ struct hall_data *data)
+{
+ int err;
+
+ data->hall_dev = devm_input_allocate_device(&pdev->dev);
+ if (!data->hall_dev) {
+ dev_err(&pdev->dev, "input device allocation failed\n");
+ return -EINVAL;
+ }
+
+ data->hall_dev->name = LID_DEV_NAME;
+ data->hall_dev->phys = HALL_INPUT;
+ set_bit(EV_KEY, data->hall_dev->evbit);
+ set_bit(KEY_HALL, data->hall_dev->keybit);
+
+ err = input_register_device(data->hall_dev);
+ if (err < 0) {
+ dev_err(&pdev->dev, "unable to register input device %s\n",
+ LID_DEV_NAME);
+ return err;
+ }
+
+ return 0;
+}
+
+static ssize_t extbd_status_store(const struct class *c,
+ const struct class_attribute *attr,
+ const char *buf, size_t count)
+{
+ if (kstrtoint(buf, 0, &g_extbd_status))
+ return -EINVAL;
+
+ return count;
+}
+
+static ssize_t extbd_status_show(const struct class *c,
+ const struct class_attribute *attr,
+ char *buf)
+{
+ g_extbd_status = (gpio_get_value_cansleep(p_hall_data->gpio) ? 1 : 0) ^
+ p_hall_data->active_low;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", g_extbd_status);
+}
+
+static CLASS_ATTR_RW(extbd_status);
+
+static struct attribute *extbd_ctrl_class_attrs[] = {
+ &class_attr_extbd_status.attr,
+ NULL,
+};
+
+ATTRIBUTE_GROUPS(extbd_ctrl_class);
+
+static int hall_driver_probe(struct platform_device *dev)
+{
+ struct hall_data *data;
+ int err;
+ int irq_flags;
+
+ dev_info(&dev->dev, "hall_driver probe\n");
+
+ data = devm_kzalloc(&dev->dev, sizeof(struct hall_data), GFP_KERNEL);
+ if (data == NULL) {
+ err = -ENOMEM;
+ dev_err(&dev->dev, "failed to allocate memory %d\n", err);
+ goto exit;
+ }
+
+ data->dev = &dev->dev;
+ dev_set_drvdata(&dev->dev, data);
+
+ err = hall_parse_dt(&dev->dev, data);
+ if (err < 0) {
+ dev_err(&dev->dev, "Failed to parse device tree\n");
+ goto exit;
+ }
+
+ err = hall_input_init(dev, data);
+ if (err < 0) {
+ dev_err(&dev->dev, "input init failed\n");
+ goto exit;
+ }
+
+ if (!gpio_is_valid(data->gpio)) {
+ dev_err(&dev->dev, "gpio is not valid\n");
+ err = -EINVAL;
+ goto free_gpio;
+ }
+
+ irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
+ err = gpio_request_one(data->gpio, GPIOF_IN, "hall_sensor_irq");
+ if (err) {
+ dev_err(&dev->dev, "unable to request gpio %d\n", data->gpio);
+ goto exit;
+ }
+
+ data->irq = gpio_to_irq(data->gpio);
+ err = devm_request_threaded_irq(&dev->dev, data->irq, NULL,
+ hall_interrupt_handler,
+ irq_flags, "hall_sensor", data);
+ if (err < 0)
+ goto free_irq;
+
+ data->hall_wq = create_singlethread_workqueue("hall_wq");
+ if (!data->hall_wq)
+ return -EINVAL;
+
+ INIT_DELAYED_WORK(&data->hall_debounce_work_det,
+ hall_det_debounce_work_func);
+
+ /*
+ * err = sysfs_create_group(&data->dev->kobj, &hall_attr_group);
+ * if (err) {
+ * printk(KERN_ERR "%s sysfs_create_group fail\n", __func__);
+ * return err;
+ * }
+ */
+
+ extbd_ctrl_class.name = "extbd_ctrl";
+ extbd_ctrl_class.class_groups = extbd_ctrl_class_groups;
+ err = class_register(&extbd_ctrl_class);
+ if (err < 0)
+ dev_err(&dev->dev, "Failed to create extbd_ctrl_class rc=%d\n",
+ err);
+
+ p_hall_data = data;
+ device_init_wakeup(&dev->dev, data->wakeup);
+ enable_irq_wake(data->irq);
+
+ dev_info(&dev->dev, "guh hall probe end");
+
+ return 0;
+
+free_irq:
+ disable_irq_wake(data->irq);
+ device_init_wakeup(&dev->dev, 0);
+free_gpio:
+ gpio_free(data->gpio);
+exit:
+ return err;
+}
+
+static void hall_driver_remove(struct platform_device *dev)
+{
+ struct hall_data *data = dev_get_drvdata(&dev->dev);
+
+ disable_irq_wake(data->irq);
+ device_init_wakeup(&dev->dev, 0);
+ if (data->gpio)
+ gpio_free(data->gpio);
+}
+
+static int hall_driver_suspend(struct platform_device *dev,
+ pm_message_t state)
+{
+ /*
+ * struct hall_data *data = dev_get_drvdata(&dev->dev);
+ * gpio_direction_output(data->extbd_power, 0);
+ */
+
+ return 0;
+}
+
+static int hall_driver_resume(struct platform_device *dev)
+{
+ /*
+ * struct hall_data *data = dev_get_drvdata(&dev->dev);
+ * gpio_direction_output(data->extbd_power, 1);
+ */
+
+ return 0;
+}
+
+static struct platform_device_id hall_id[] = {
+ { LID_DEV_NAME, 0 },
+ { },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id hall_match_table[] = {
+ { .compatible = "hall-switch", },
+ { },
+};
+#endif
+
+static struct platform_driver hall_driver = {
+ .driver = {
+ .name = LID_DEV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(hall_match_table),
+ },
+ .probe = hall_driver_probe,
+ .remove = hall_driver_remove,
+ .suspend = hall_driver_suspend,
+ .resume = hall_driver_resume,
+ .id_table = hall_id,
+};
+
+static int __init hall_init(void)
+{
+ return platform_driver_register(&hall_driver);
+}
+
+static void __exit hall_exit(void)
+{
+ platform_driver_unregister(&hall_driver);
+}
+
+module_init(hall_init);
+module_exit(hall_exit);
+
+MODULE_DESCRIPTION("Hall sensor driver");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [PATCH v5 3/3] Documentation: thinkpad-acpi - Document doubletap_enable attribute
From: Vishnu Sankar @ 2026-01-21 9:19 UTC (permalink / raw)
To: Bagas Sanjaya
Cc: dmitry.torokhov, hmh, hansg, ilpo.jarvinen, corbet,
derekjohn.clark, mpearson-lenovo, linux-doc, linux-input,
linux-kernel, ibm-acpi-devel, platform-driver-x86, vsankar
In-Reply-To: <aW7Gh6WsTjVo5IO_@archie.me>
Hi Bagas,
Thank you so much for the comments.
On Tue, Jan 20, 2026 at 9:04 AM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On Sat, Dec 27, 2025 at 08:51:01AM +0900, Vishnu Sankar wrote:
> > +Values:
> > + * 1 - doubletap events are processed (default)
> > + * 0 - doubletap events are filtered out (ignored)
>
> Please separate the bullet list from "Values:" paragraph.
Acked.
I will update this in my V6.
>
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
--
Regards,
Vishnu Sankar
+817015150407 (Japan)
^ 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
* 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 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 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: 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] 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
* [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 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
* 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 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 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
* [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
* [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 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
* 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
* 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 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 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 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
* [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
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