* [PATCH (repost)] Input: MT - use __GFP_NOWARN allocation at input_mt_init_slots()
From: Tetsuo Handa @ 2023-03-28 11:25 UTC (permalink / raw)
To: Henrik Rydberg, Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
syzbot is reporting too large allocation at input_mt_init_slots(), for
num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
Use __GFP_NOWARN. Also, replace n2 with array_size(), for 32bits variable
n2 will overflow if num_slots >= 65536 and will cause out of bounds
read/write at input_mt_set_matrix()/input_mt_set_slots() on architectures
where PAGE_SIZE > 4096 is available (e.g. PPC64).
Reported-by: syzbot <syzbot+0122fa359a69694395d5@syzkaller.appspotmail.com>
Link: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
Dmitry Torokhov proposed limiting max size to accept. But since it seems
that nobody knows appropriate max size to accept, reposting as-is.
https://lkml.kernel.org/r/03e8c3f0-bbbf-af37-6f52-67547cbd4cde@I-love.SAKURA.ne.jp
drivers/input/input-mt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
index 14b53dac1253..cf74579462ba 100644
--- a/drivers/input/input-mt.c
+++ b/drivers/input/input-mt.c
@@ -47,7 +47,7 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int num_slots,
if (mt)
return mt->num_slots != num_slots ? -EINVAL : 0;
- mt = kzalloc(struct_size(mt, slots, num_slots), GFP_KERNEL);
+ mt = kzalloc(struct_size(mt, slots, num_slots), GFP_KERNEL | __GFP_NOWARN);
if (!mt)
goto err_mem;
@@ -80,8 +80,8 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int num_slots,
if (flags & INPUT_MT_SEMI_MT)
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
if (flags & INPUT_MT_TRACK) {
- unsigned int n2 = num_slots * num_slots;
- mt->red = kcalloc(n2, sizeof(*mt->red), GFP_KERNEL);
+ mt->red = kcalloc(array_size(num_slots, num_slots),
+ sizeof(*mt->red), GFP_KERNEL | __GFP_NOWARN);
if (!mt->red)
goto err_mem;
}
--
2.18.4
^ permalink raw reply related
* RE: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
From: phoenix @ 2023-03-28 8:54 UTC (permalink / raw)
To: 'jingle.wu', linux-kernel, linux-input, dmitry.torokhov
Cc: josh.chen, dave.wang
In-Reply-To: <20230320011456.986321-1-jingle.wu@emc.com.tw>
Hi Dmitry,
No response from you yet,
Can you help review this patch, thanks
Best regards,
Phoenix Huang
-----Original Message-----
From: jingle.wu [mailto:jingle.wu@emc.com.tw]
Sent: Monday, March 20, 2023 9:15 AM
To: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org;
dmitry.torokhov@gmail.com
Cc: phoenix@emc.com.tw; josh.chen@emc.com.tw; dave.wang@emc.com.tw;
jingle.wu <jingle.wu@emc.com.tw>
Subject: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
Add inhibit/uninhibit functions.
Signed-off-by: Jingle.wu <jingle.wu@emc.com.tw>
---
drivers/input/mouse/elan_i2c_core.c | 86 +++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 5f0d75a45c80..b7100945c9cc 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -329,6 +329,89 @@ static int elan_initialize(struct elan_tp_data *data,
bool skip_reset)
return error;
}
+static int elan_reactivate(struct elan_tp_data *data) {
+ struct device *dev = &data->client->dev;
+ int ret;
+
+ ret = elan_set_power(data, true);
+ if (ret)
+ dev_err(dev, "failed to restore power: %d\n", ret);
+
+ ret = data->ops->sleep_control(data->client, false);
+ if (ret) {
+ dev_err(dev,
+ "failed to wake device up: %d\n", ret);
+ return ret;
+ }
+
+ return ret;
+}
+
+static void elan_inhibit(struct input_dev *input_dev) {
+ struct elan_tp_data *data = input_get_drvdata(input_dev);
+ struct i2c_client *client = data->client;
+ int ret;
+
+ if (data->in_fw_update)
+ return;
+
+ dev_dbg(&client->dev, "inhibiting\n");
+ /*
+ * We are taking the mutex to make sure sysfs operations are
+ * complete before we attempt to bring the device into low[er]
+ * power mode.
+ */
+ ret = mutex_lock_interruptible(&data->sysfs_mutex);
+ if (ret)
+ return;
+
+ disable_irq(client->irq);
+
+ ret = elan_set_power(data, false);
+ if (ret)
+ enable_irq(client->irq);
+
+ mutex_unlock(&data->sysfs_mutex);
+
+}
+
+static void elan_close(struct input_dev *input_dev) {
+ if ((input_dev->users) && (!input_dev->inhibited))
+ elan_inhibit(input_dev);
+
+}
+
+static int elan_uninhibit(struct input_dev *input_dev) {
+ struct elan_tp_data *data = input_get_drvdata(input_dev);
+ struct i2c_client *client = data->client;
+ int ret;
+
+ dev_dbg(&client->dev, "uninhibiting\n");
+ ret = mutex_lock_interruptible(&data->sysfs_mutex);
+ if (ret)
+ return ret;
+
+ ret = elan_reactivate(data);
+ if (ret == 0)
+ enable_irq(client->irq);
+
+ mutex_unlock(&data->sysfs_mutex);
+
+ return ret;
+}
+
+static int elan_open(struct input_dev *input_dev) {
+ if ((input_dev->users) && (input_dev->inhibited))
+ return elan_uninhibit(input_dev);
+
+ return 0;
+}
+
static int elan_query_device_info(struct elan_tp_data *data) {
int error;
@@ -1175,6 +1258,9 @@ static int elan_setup_input_device(struct elan_tp_data
*data)
0, ETP_FINGER_WIDTH * min_width, 0, 0);
}
+ input->open = elan_open;
+ input->close = elan_close;
+
data->input = input;
return 0;
base-commit: 38e04b3e4240a6d8fb43129ebad41608db64bc6f
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Input: iqs62x-keys - Suppress duplicated error message in .remove()
From: Uwe Kleine-König @ 2023-03-28 6:08 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: Mattijs Korpershoek, Dmitry Torokhov, kernel, linux-input
In-Reply-To: <ZCImXFuXgh+rsRl5@nixie71>
[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]
Hello Jeff,
On Mon, Mar 27, 2023 at 06:27:24PM -0500, Jeff LaBundy wrote:
> On Sat, Mar 18, 2023 at 11:51:10PM +0100, Uwe Kleine-König wrote:
> > If a platform driver's remove callback returns non-zero the driver core
> > emits an error message. In such a case however iqs62x_keys_remove()
> > already issued a (better) message. So return zero to suppress the
> > generic message.
> >
> > This patch has no other side effects as platform_remove() ignores the
> > return value of .remove() after the warning.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> I was traveling all last week, and therefore unable to voice my opposition
> in time. However, I figured I would still provide my feedback in case this
> change may be proposed for other cases.
It is.
> > ---
> > drivers/input/keyboard/iqs62x-keys.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/keyboard/iqs62x-keys.c b/drivers/input/keyboard/iqs62x-keys.c
> > index db793a550c25..02ceebad7bda 100644
> > --- a/drivers/input/keyboard/iqs62x-keys.c
> > +++ b/drivers/input/keyboard/iqs62x-keys.c
> > @@ -320,7 +320,7 @@ static int iqs62x_keys_remove(struct platform_device *pdev)
> > if (ret)
> > dev_err(&pdev->dev, "Failed to unregister notifier: %d\n", ret);
> >
> > - return ret;
> > + return 0;
>
> In my opinion, we should never silence a function's return value, especially
> in service of what is ultimately innocuous and cosmetic in nature. While this
> specific example is harmless today, the caller can change and hence should be
> the only instance who decides whether the return value is important.
The caller will change. Today the caller (i.e. platform_remove()) looks
as follows:
... if (drv->remove) {
int ret = drv->remove(dev);
if (ret)
dev_warn(_dev, "remove callback returned a non-zero value. This will be ignored.\n");
}
(so ret isn't used later any more). And I eventually will do
struct platform_driver {
...
- int (*remove)(struct platform_device *);
+ void (*remove)(struct platform_device *);
...
}
and change platform_remove() to just:
if (drv->remove)
drv->remove(dev);
The change in question is a preparation for that.
The reason I tackle that is that .remove() returning an int seduces
driver authors to exit early in .remove() in the expectation that there
is error handling in the core (which there isn't).
See
https://lore.kernel.org/linux-spi/20230317084232.142257-3-u.kleine-koenig@pengutronix.de
for such an issue.
> If having both fine and subsequently coarse print statements is unacceptable,
> I would have preferred to drop this driver's print statement and continue to
> return ret. Or at the very least, include a comment as to why we deliberately
> ignore the return value.
I have a patch series in the queue that will convert all drivers in
drivers/input to .remove_new(). (See
https://lore.kernel.org/linux-media/20230326143224.572654-9-u.kleine-koenig@pengutronix.de
for an example of such a conversion.) If we add such a comment now, I
will probably miss to adapt it then.
So I'm still convinced the patch I did is the right thing to do.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] dt-bindings: input: pwm-beeper: convert to dt schema
From: Peng Fan (OSS) @ 2023-03-28 5:48 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, s.hauer
Cc: linux-input, devicetree, linux-kernel, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
Convert the binding doc to dt schema, and also fixed the
example from fixed-regulator to regulator-fixed.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/input/pwm-beeper.txt | 24 ----------
.../devicetree/bindings/input/pwm-beeper.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt
deleted file mode 100644
index 8fc0e48c20db..000000000000
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* PWM beeper device tree bindings
-
-Registers a PWM device as beeper.
-
-Required properties:
-- compatible: should be "pwm-beeper"
-- pwms: phandle to the physical PWM device
-
-Optional properties:
-- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
-- beeper-hz: bell frequency in Hz
-
-Example:
-
-beeper_amp: amplifier {
- compatible = "fixed-regulator";
- gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-};
-
-beeper {
- compatible = "pwm-beeper";
- pwms = <&pwm0>;
- amp-supply = <&beeper_amp>;
-};
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
new file mode 100644
index 000000000000..1d7cd58d2a8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/pwm-beeper.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM beeper
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ items:
+ - const: pwm-beeper
+
+ pwms:
+ description: Phandle to the physical PWM device
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ amp-supply:
+ description: Phandle to a regulator that acts as an amplifier for the beeper
+
+ beeper-hz:
+ description: bell frequency in Hz
+ minimum: 1
+ maximum: 255
+
+required:
+ - compatible
+ - pwms
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ beeper_amp: amplifier {
+ compatible = "regulator-fixed";
+ gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+ regulator-name = "beeper_amp";
+ };
+
+ beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm0>;
+ amp-supply = <&beeper_amp>;
+ };
--
2.37.1
^ permalink raw reply related
* Re: [PATCH] Input: iqs62x-keys - Suppress duplicated error message in .remove()
From: Jeff LaBundy @ 2023-03-27 23:27 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Dmitry Torokhov, Mattijs Korpershoek, linux-input, kernel
In-Reply-To: <20230318225110.261439-1-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On Sat, Mar 18, 2023 at 11:51:10PM +0100, Uwe Kleine-König wrote:
> If a platform driver's remove callback returns non-zero the driver core
> emits an error message. In such a case however iqs62x_keys_remove()
> already issued a (better) message. So return zero to suppress the
> generic message.
>
> This patch has no other side effects as platform_remove() ignores the
> return value of .remove() after the warning.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
I was traveling all last week, and therefore unable to voice my opposition
in time. However, I figured I would still provide my feedback in case this
change may be proposed for other cases.
> ---
> drivers/input/keyboard/iqs62x-keys.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/iqs62x-keys.c b/drivers/input/keyboard/iqs62x-keys.c
> index db793a550c25..02ceebad7bda 100644
> --- a/drivers/input/keyboard/iqs62x-keys.c
> +++ b/drivers/input/keyboard/iqs62x-keys.c
> @@ -320,7 +320,7 @@ static int iqs62x_keys_remove(struct platform_device *pdev)
> if (ret)
> dev_err(&pdev->dev, "Failed to unregister notifier: %d\n", ret);
>
> - return ret;
> + return 0;
In my opinion, we should never silence a function's return value, especially
in service of what is ultimately innocuous and cosmetic in nature. While this
specific example is harmless today, the caller can change and hence should be
the only instance who decides whether the return value is important.
If having both fine and subsequently coarse print statements is unacceptable,
I would have preferred to drop this driver's print statement and continue to
return ret. Or at the very least, include a comment as to why we deliberately
ignore the return value.
However, it's quite common for drivers to print a detailed message from probe
followed by the core printing "failed to probe," so I don't see why the remove
case cannot be the same. At any rate, this is just my $.02.
> }
>
> static struct platform_driver iqs62x_keys_platform_driver = {
>
> base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
> --
> 2.39.2
>
Kind regards,
Jeff LaBundy
^ permalink raw reply
* [PATCH v2] HID: intel-ish-hid: Fix kernel panic during warm reset
From: Tanu Malhotra @ 2023-03-27 18:58 UTC (permalink / raw)
To: srinivas.pandruvada, jikos
Cc: linux-input, linux-kernel, even.xu, Tanu Malhotra, stable,
Shaunak Saha
During warm reset device->fw_client is set to NULL. If a bus driver is
registered after this NULL setting and before new firmware clients are
enumerated by ISHTP, kernel panic will result in the function
ishtp_cl_bus_match(). This is because of reference to
device->fw_client->props.protocol_name.
ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel
module drivers were loaded right after any of the first ISHTP device was
registered, regardless of whether it was a matched or an unmatched
device. This resulted in all drivers getting registered much before the
warm reset notification from ISH.
Starting kernel v5.16, this issue got exposed after the change was
introduced to load only bus drivers for the respective matching devices.
In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are
registered after the warm reset device fw_client NULL setting.
cros_ec_ishtp driver_register() triggers the callback to
ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel
panic in guid_equal() when dereferencing fw_client NULL pointer to get
protocol_name.
Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices")
Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices")
Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices")
Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices")
Cc: <stable@vger.kernel.org> # 5.16+
Signed-off-by: Tanu Malhotra <tanu.malhotra@intel.com>
Tested-by: Shaunak Saha <shaunak.saha@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
v2:
- Cleaned up coding indentation
- Updated commit description
- Added stable mailing list to Cc
---
drivers/hid/intel-ish-hid/ishtp/bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 81385ab37fa9..7fc738a22375 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -241,8 +241,8 @@ static int ishtp_cl_bus_match(struct device *dev, struct device_driver *drv)
struct ishtp_cl_device *device = to_ishtp_cl_device(dev);
struct ishtp_cl_driver *driver = to_ishtp_cl_driver(drv);
- return guid_equal(&driver->id[0].guid,
- &device->fw_client->props.protocol_name);
+ return(device->fw_client ? guid_equal(&driver->id[0].guid,
+ &device->fw_client->props.protocol_name) : 0);
}
/**
base-commit: 1e760fa3596e8c7f08412712c168288b79670d78
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 6/6] Input: cyttsp5: implement proper sleep and wakeup procedures
From: kernel test robot @ 2023-03-27 18:11 UTC (permalink / raw)
To: Maximilian Weigand, Linus Walleij, Dmitry Torokhov, linux-input,
linux-kernel, devicetree
Cc: llvm, oe-kbuild-all, Maximilian Weigand, Alistair Francis
In-Reply-To: <20230323135205.1160879-7-mweigand@mweigand.net>
Hi Maximilian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus linus/master v6.3-rc4 next-20230327]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Maximilian-Weigand/Input-cyttsp5-fix-array-length/20230323-215957
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20230323135205.1160879-7-mweigand%40mweigand.net
patch subject: [PATCH 6/6] Input: cyttsp5: implement proper sleep and wakeup procedures
config: i386-randconfig-a011-20230327 (https://download.01.org/0day-ci/archive/20230328/202303280119.UlD7s4Rk-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/9988f8132aa9a4e8c9f0eb3093b06a9f02d90ec9
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Maximilian-Weigand/Input-cyttsp5-fix-array-length/20230323-215957
git checkout 9988f8132aa9a4e8c9f0eb3093b06a9f02d90ec9
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/input/touchscreen/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303280119.UlD7s4Rk-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/touchscreen/cyttsp5.c:581:6: warning: unused variable 'crc' [-Wunused-variable]
u16 crc;
^
drivers/input/touchscreen/cyttsp5.c:620:6: warning: unused variable 'crc' [-Wunused-variable]
u16 crc;
^
drivers/input/touchscreen/cyttsp5.c:700:5: warning: unused variable 'cmd' [-Wunused-variable]
u8 cmd[2];
^
>> drivers/input/touchscreen/cyttsp5.c:1004:6: warning: unused variable 'error' [-Wunused-variable]
int error;
^
>> drivers/input/touchscreen/cyttsp5.c:1003:21: warning: unused variable 'client' [-Wunused-variable]
struct i2c_client *client = to_i2c_client(dev);
^
5 warnings generated.
vim +/crc +581 drivers/input/touchscreen/cyttsp5.c
576
577 static int cyttsp5_enter_sleep(struct cyttsp5 *ts)
578 {
579 int rc;
580 u8 cmd[2];
> 581 u16 crc;
582
583 memset(cmd, 0, sizeof(cmd));
584
585 SET_CMD_REPORT_TYPE(cmd[0], 0);
586 SET_CMD_REPORT_ID(cmd[0], HID_POWER_SLEEP);
587 SET_CMD_OPCODE(cmd[1], HID_CMD_SET_POWER);
588
589 rc = cyttsp5_write(ts, HID_COMMAND_REG, cmd, 2);
590 if (rc) {
591 dev_err(ts->dev, "Failed to write command %d", rc);
592 return rc;
593 }
594
595 rc = wait_for_completion_interruptible_timeout(&ts->cmd_command_done,
596 msecs_to_jiffies(CY_HID_SET_POWER_TIMEOUT));
597 if (rc <= 0) {
598 dev_err(ts->dev, "HID output cmd execution timed out\n");
599 rc = -ETIMEDOUT;
600 return rc;
601 }
602
603 /* validate */
604 if ((ts->response_buf[2] != HID_RESPONSE_REPORT_ID)
605 || ((ts->response_buf[3] & 0x3) != HID_POWER_SLEEP)
606 || ((ts->response_buf[4] & 0xF) != HID_CMD_SET_POWER)) {
607 rc = -EINVAL;
608 dev_err(ts->dev, "Validation of the sleep response failed\n");
609 return rc;
610 }
611
612 return 0;
613
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH 2/6] Input: cyttsp5: remove unused code
From: kernel test robot @ 2023-03-27 15:17 UTC (permalink / raw)
To: Maximilian Weigand, Linus Walleij, Dmitry Torokhov, linux-input,
linux-kernel, devicetree
Cc: llvm, oe-kbuild-all, Maximilian Weigand, Alistair Francis
In-Reply-To: <20230323135205.1160879-3-mweigand@mweigand.net>
Hi Maximilian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus linus/master v6.3-rc4 next-20230327]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Maximilian-Weigand/Input-cyttsp5-fix-array-length/20230323-215957
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20230323135205.1160879-3-mweigand%40mweigand.net
patch subject: [PATCH 2/6] Input: cyttsp5: remove unused code
config: i386-randconfig-a011-20230327 (https://download.01.org/0day-ci/archive/20230327/202303272323.nRNi9Sso-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/4358a60821eb8149dabed197c09d3c0eab63bf38
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Maximilian-Weigand/Input-cyttsp5-fix-array-length/20230323-215957
git checkout 4358a60821eb8149dabed197c09d3c0eab63bf38
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/input/touchscreen/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303272323.nRNi9Sso-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/touchscreen/cyttsp5.c:604:5: warning: unused variable 'cmd' [-Wunused-variable]
u8 cmd[2];
^
1 warning generated.
vim +/cmd +604 drivers/input/touchscreen/cyttsp5.c
5b0c03e24a061f Alistair Francis 2022-10-31 598
5b0c03e24a061f Alistair Francis 2022-10-31 599 static int cyttsp5_get_hid_descriptor(struct cyttsp5 *ts,
5b0c03e24a061f Alistair Francis 2022-10-31 600 struct cyttsp5_hid_desc *desc)
5b0c03e24a061f Alistair Francis 2022-10-31 601 {
5b0c03e24a061f Alistair Francis 2022-10-31 602 struct device *dev = ts->dev;
5b0c03e24a061f Alistair Francis 2022-10-31 603 int rc;
5b0c03e24a061f Alistair Francis 2022-10-31 @604 u8 cmd[2];
5b0c03e24a061f Alistair Francis 2022-10-31 605
5b0c03e24a061f Alistair Francis 2022-10-31 606 rc = cyttsp5_write(ts, HID_DESC_REG, NULL, 0);
5b0c03e24a061f Alistair Francis 2022-10-31 607 if (rc) {
5b0c03e24a061f Alistair Francis 2022-10-31 608 dev_err(dev, "Failed to get HID descriptor, rc=%d\n", rc);
5b0c03e24a061f Alistair Francis 2022-10-31 609 return rc;
5b0c03e24a061f Alistair Francis 2022-10-31 610 }
5b0c03e24a061f Alistair Francis 2022-10-31 611
5b0c03e24a061f Alistair Francis 2022-10-31 612 rc = wait_for_completion_interruptible_timeout(&ts->cmd_done,
5b0c03e24a061f Alistair Francis 2022-10-31 613 msecs_to_jiffies(CY_HID_GET_HID_DESCRIPTOR_TIMEOUT_MS));
5b0c03e24a061f Alistair Francis 2022-10-31 614 if (rc <= 0) {
5b0c03e24a061f Alistair Francis 2022-10-31 615 dev_err(ts->dev, "HID get descriptor timed out\n");
5b0c03e24a061f Alistair Francis 2022-10-31 616 rc = -ETIMEDOUT;
5b0c03e24a061f Alistair Francis 2022-10-31 617 return rc;
5b0c03e24a061f Alistair Francis 2022-10-31 618 }
5b0c03e24a061f Alistair Francis 2022-10-31 619
5b0c03e24a061f Alistair Francis 2022-10-31 620 memcpy(desc, ts->response_buf, sizeof(*desc));
5b0c03e24a061f Alistair Francis 2022-10-31 621
5b0c03e24a061f Alistair Francis 2022-10-31 622 /* Check HID descriptor length and version */
5b0c03e24a061f Alistair Francis 2022-10-31 623 if (le16_to_cpu(desc->hid_desc_len) != sizeof(*desc) ||
5b0c03e24a061f Alistair Francis 2022-10-31 624 le16_to_cpu(desc->bcd_version) != HID_VERSION) {
5b0c03e24a061f Alistair Francis 2022-10-31 625 dev_err(dev, "Unsupported HID version\n");
5b0c03e24a061f Alistair Francis 2022-10-31 626 return -ENODEV;
5b0c03e24a061f Alistair Francis 2022-10-31 627 }
5b0c03e24a061f Alistair Francis 2022-10-31 628
5b0c03e24a061f Alistair Francis 2022-10-31 629 return 0;
5b0c03e24a061f Alistair Francis 2022-10-31 630 }
5b0c03e24a061f Alistair Francis 2022-10-31 631
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* [PATCH] xpad.c: Change MAP_SELECT_BUTTON to MAP_SHARE_BUTTON
From: Matthias Benkmann @ 2023-03-27 14:33 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Pavel Rojtberg, Nate Yocom
The button affected by the macro MAP_SELECT_BUTTON is called "Share".
Rename the macro to match the name of the button.
Signed-off-by: Matthias Benkmann <matthias.benkmann@gmail.com>
---
drivers/input/joystick/xpad.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 49ae963e5f9d..0235e8b4b943 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -80,7 +80,7 @@
#define MAP_DPAD_TO_BUTTONS (1 << 0)
#define MAP_TRIGGERS_TO_BUTTONS (1 << 1)
#define MAP_STICKS_TO_NULL (1 << 2)
-#define MAP_SELECT_BUTTON (1 << 3)
+#define MAP_SHARE_BUTTON (1 << 3)
#define MAP_PADDLES (1 << 4)
#define MAP_PROFILE_BUTTON (1 << 5)
@@ -150,7 +150,7 @@ static const struct xpad_device {
{ 0x045e, 0x02ea, "Microsoft X-Box One S pad", 0, XTYPE_XBOXONE },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0b0a, "Microsoft X-Box Adaptive Controller", MAP_PROFILE_BUTTON, XTYPE_XBOXONE },
- { 0x045e, 0x0b12, "Microsoft Xbox Series S|X Controller", MAP_SELECT_BUTTON, XTYPE_XBOXONE },
+ { 0x045e, 0x0b12, "Microsoft Xbox Series S|X Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21e, "Logitech Gamepad F510", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
@@ -1003,7 +1003,7 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
/* menu/view buttons */
input_report_key(dev, BTN_START, data[4] & BIT(2));
input_report_key(dev, BTN_SELECT, data[4] & BIT(3));
- if (xpad->mapping & MAP_SELECT_BUTTON)
+ if (xpad->mapping & MAP_SHARE_BUTTON)
input_report_key(dev, KEY_RECORD, data[22] & BIT(0));
/* buttons A,B,X,Y */
@@ -1869,7 +1869,7 @@ static int xpad_init_input(struct usb_xpad *xpad)
xpad->xtype == XTYPE_XBOXONE) {
for (i = 0; xpad360_btn[i] >= 0; i++)
input_set_capability(input_dev, EV_KEY, xpad360_btn[i]);
- if (xpad->mapping & MAP_SELECT_BUTTON)
+ if (xpad->mapping & MAP_SHARE_BUTTON)
input_set_capability(input_dev, EV_KEY, KEY_RECORD);
} else {
for (i = 0; xpad_btn[i] >= 0; i++)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] HID: intel-ish-hid: Fix kernel panic during warm reset
From: srinivas pandruvada @ 2023-03-27 12:10 UTC (permalink / raw)
To: Tanu Malhotra, jikos; +Cc: linux-input, linux-kernel, even.xu, Shaunak Saha
In-Reply-To: <20230327032310.2416272-1-tanu.malhotra@intel.com>
On Sun, 2023-03-26 at 20:23 -0700, Tanu Malhotra wrote:
some minor nits below.
> During warm reset device->fw_client is set to NULL. If a bus driver
> is
> registered after this NULL setting and before new firmware clients
> are
> enumerated by ISHTP, kernel panic will result in the function
> ishtp_cl_bus_match(). This is because of reference to
> device->fw_client->props.protocol_name.
>
> ISH firmware after getting successfully loaded, sends a warm reset
> notification to remove all clients from the bus and sets
> device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP
> kernel
> module drivers were loaded after any of the first ISHTP device was
> registered, regardless of whether it was a matched or an unmatched
> device. This resulted in all drivers getting registered much before
> the
> warm reset notification from ISH. Starting kernel v5.16, this issue
> got
> exposed after the change was introduced to load only bus drivers for
> the
> respective matching devices.
One paragraph break will be better.
> In this scenario, cros_ec_ishtp device and
> cros_ec_ishtp driver are registered after the warm reset
> device_fw_client NULL setting. cros_ec_ishtp driver_register()
> triggers
> the callback to ishtp_cl_bus_match() to match driver to the device
> and
> causes kernel panic in guid_equal() when dereferencing fw_client NULL
> pointer to get protocol_name.
>
> Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for
> matching devices")
> Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for
> matching devices")
> Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for
> matching devices")
> Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for
> matching devices")
>
No need of blank line.
> Signed-off-by: Tanu Malhotra <tanu.malhotra@intel.com>
> Tested-by: Shaunak Saha <shaunak.saha@intel.com>
You can also add
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Also add
Cc: <stable@vger.kernel.org> # 5.16+
> ---
When you submit "PATCH v2", Add change log here. (That is below "---").
Something like this:
v2
- Updated commit description
- Added CC to stable
> drivers/hid/intel-ish-hid/ishtp/bus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c
> b/drivers/hid/intel-ish-hid/ishtp/bus.c
> index 81385ab37fa9..4f540906268f 100644
> --- a/drivers/hid/intel-ish-hid/ishtp/bus.c
> +++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
> @@ -241,8 +241,8 @@ static int ishtp_cl_bus_match(struct device *dev,
> struct device_driver *drv)
> struct ishtp_cl_device *device = to_ishtp_cl_device(dev);
> struct ishtp_cl_driver *driver = to_ishtp_cl_driver(drv);
>
> - return guid_equal(&driver->id[0].guid,
> - &device->fw_client->props.protocol_name);
> + return(device->fw_client ? guid_equal(&driver->id[0].guid,
> + &device->fw_client-
> >props.protocol_name) : 0);
Align the second line to char "d" after "(".
Thanks,
Srinivas
> }
>
> /**
^ permalink raw reply
* Słowa kluczowe do wypozycjonowania
From: Adam Charachuta @ 2023-03-27 7:50 UTC (permalink / raw)
To: linux-input
Dzień dobry,
zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów.
Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci.
Możemy porozmawiać w najbliższym czasie?
Pozdrawiam
Adam Charachuta
^ permalink raw reply
* [PATCH] HID: intel-ish-hid: Fix kernel panic during warm reset
From: Tanu Malhotra @ 2023-03-27 3:23 UTC (permalink / raw)
To: srinivas.pandruvada, jikos
Cc: linux-input, linux-kernel, even.xu, Tanu Malhotra, Shaunak Saha
During warm reset device->fw_client is set to NULL. If a bus driver is
registered after this NULL setting and before new firmware clients are
enumerated by ISHTP, kernel panic will result in the function
ishtp_cl_bus_match(). This is because of reference to
device->fw_client->props.protocol_name.
ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel
module drivers were loaded after any of the first ISHTP device was
registered, regardless of whether it was a matched or an unmatched
device. This resulted in all drivers getting registered much before the
warm reset notification from ISH. Starting kernel v5.16, this issue got
exposed after the change was introduced to load only bus drivers for the
respective matching devices. In this scenario, cros_ec_ishtp device and
cros_ec_ishtp driver are registered after the warm reset
device_fw_client NULL setting. cros_ec_ishtp driver_register() triggers
the callback to ishtp_cl_bus_match() to match driver to the device and
causes kernel panic in guid_equal() when dereferencing fw_client NULL
pointer to get protocol_name.
Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices")
Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices")
Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices")
Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices")
Signed-off-by: Tanu Malhotra <tanu.malhotra@intel.com>
Tested-by: Shaunak Saha <shaunak.saha@intel.com>
---
drivers/hid/intel-ish-hid/ishtp/bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 81385ab37fa9..4f540906268f 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -241,8 +241,8 @@ static int ishtp_cl_bus_match(struct device *dev, struct device_driver *drv)
struct ishtp_cl_device *device = to_ishtp_cl_device(dev);
struct ishtp_cl_driver *driver = to_ishtp_cl_driver(drv);
- return guid_equal(&driver->id[0].guid,
- &device->fw_client->props.protocol_name);
+ return(device->fw_client ? guid_equal(&driver->id[0].guid,
+ &device->fw_client->props.protocol_name) : 0);
}
/**
--
2.34.1
^ permalink raw reply related
* [PATCH v2] Input: touchscreen - Add new Novatek NVT-ts driver
From: Hans de Goede @ 2023-03-26 21:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, Jeff LaBundy, linux-input
Add a new driver for the Novatek i2c touchscreen controller as found
on the Acer Iconia One 7 B1-750 tablet. Unfortunately the touchscreen
controller model-number is unknown. Even with the tablet opened up it
is impossible to read the model-number.
Android calls this a "NVT-ts" touchscreen, but that may apply to other
Novatek controller models too.
This appears to be the same controller as the one supported by
https://github.com/advx9600/android/blob/master/touchscreen/NVTtouch_Android4.0/NVTtouch.c
but unfortunately that does not give us a model-number either.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
MAINTAINERS | 6 +
drivers/input/touchscreen/Kconfig | 10 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/novatek-nvt-ts.c | 289 +++++++++++++++++++++
4 files changed, 306 insertions(+)
create mode 100644 drivers/input/touchscreen/novatek-nvt-ts.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 08b7178d645b..30b57a4afe9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14788,6 +14788,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git
F: tools/include/nolibc/
F: tools/testing/selftests/nolibc/
+NOVATEK NVT-TS I2C TOUCHSCREEN DRIVER
+M: Hans de Goede <hdegoede@redhat.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/input/touchscreen/novatek-nvt-ts.c
+
NSDEPS
M: Matthias Maennich <maennich@google.com>
S: Maintained
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 1a2049b336a6..1feecd7ed3cb 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -654,6 +654,16 @@ config TOUCHSCREEN_MTOUCH
To compile this driver as a module, choose M here: the
module will be called mtouch.
+config TOUCHSCREEN_NOVATEK_NVT_TS
+ tristate "Novatek NVT-ts touchscreen support"
+ depends on I2C
+ help
+ Say Y here if you have a Novatek NVT-ts touchscreen.
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called novatek-nvt-ts.
+
config TOUCHSCREEN_IMAGIS
tristate "Imagis touchscreen support"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index f2fd28cc34a6..159cd5136fdb 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TOUCHSCREEN_MMS114) += mms114.o
obj-$(CONFIG_TOUCHSCREEN_MSG2638) += msg2638.o
obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
obj-$(CONFIG_TOUCHSCREEN_MK712) += mk712.o
+obj-$(CONFIG_TOUCHSCREEN_NOVATEK_NVT_TS) += novatek-nvt-ts.o
obj-$(CONFIG_TOUCHSCREEN_HP600) += hp680_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_HP7XX) += jornada720_ts.o
obj-$(CONFIG_TOUCHSCREEN_IPAQ_MICRO) += ipaq-micro-ts.o
diff --git a/drivers/input/touchscreen/novatek-nvt-ts.c b/drivers/input/touchscreen/novatek-nvt-ts.c
new file mode 100644
index 000000000000..f959e7b14ad6
--- /dev/null
+++ b/drivers/input/touchscreen/novatek-nvt-ts.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Driver for Novatek i2c touchscreen controller as found on
+ * the Acer Iconia One 7 B1-750 tablet. The Touchscreen controller
+ * model-number is unknown. Android calls this a "NVT-ts" touchscreen,
+ * but that may apply to other Novatek controller models too.
+ *
+ * Copyright (c) 2023 Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
+#include <linux/module.h>
+
+#include <asm/unaligned.h>
+
+#define NVT_TS_TOUCH_START 0x00
+#define NVT_TS_TOUCH_SIZE 6
+
+#define NVT_TS_PARAMETERS_START 0x78
+/* These are offsets from NVT_TS_PARAMETERS_START */
+#define NVT_TS_PARAMS_WIDTH 0x04
+#define NVT_TS_PARAMS_HEIGHT 0x06
+#define NVT_TS_PARAMS_MAX_TOUCH 0x09
+#define NVT_TS_PARAMS_MAX_BUTTONS 0x0a
+#define NVT_TS_PARAMS_IRQ_TYPE 0x0b
+#define NVT_TS_PARAMS_WAKE_TYPE 0x0c
+#define NVT_TS_PARAMS_CHIP_ID 0x0e
+#define NVT_TS_PARAMS_SIZE 0x0f
+
+#define NVT_TS_SUPPORTED_WAKE_TYPE 0x05
+#define NVT_TS_SUPPORTED_CHIP_ID 0x05
+
+#define NVT_TS_MAX_TOUCHES 10
+#define NVT_TS_MAX_SIZE 4096
+
+#define NVT_TS_TOUCH_INVALID 0xff
+#define NVT_TS_TOUCH_SLOT_SHIFT 3
+#define NVT_TS_TOUCH_TYPE_MASK GENMASK(2, 0)
+#define NVT_TS_TOUCH_NEW 1
+#define NVT_TS_TOUCH_UPDATE 2
+#define NVT_TS_TOUCH_RELEASE 3
+
+static const int nvt_ts_irq_type[4] = {
+ IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_LOW,
+ IRQF_TRIGGER_HIGH
+};
+
+struct nvt_ts_data {
+ struct i2c_client *client;
+ struct input_dev *input;
+ struct gpio_desc *reset_gpio;
+ struct touchscreen_properties prop;
+ int max_touches;
+ u8 buf[NVT_TS_TOUCH_SIZE * NVT_TS_MAX_TOUCHES];
+};
+
+static int nvt_ts_read_data(struct i2c_client *client, u8 reg, u8 *data, int count)
+{
+ struct i2c_msg msg[2] = {
+ {
+ .addr = client->addr,
+ .len = 1,
+ .buf = ®,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len = count,
+ .buf = data,
+ }
+ };
+ int ret;
+
+ ret = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
+ if (ret != ARRAY_SIZE(msg)) {
+ dev_err(&client->dev, "Error reading from 0x%02x: %d\n", reg, ret);
+ return (ret < 0) ? ret : -EIO;
+ }
+
+ return 0;
+}
+
+static irqreturn_t nvt_ts_irq(int irq, void *dev_id)
+{
+ struct nvt_ts_data *data = dev_id;
+ struct device *dev = &data->client->dev;
+ int i, error, slot, x, y;
+ bool active;
+ u8 *touch;
+
+ error = nvt_ts_read_data(data->client, NVT_TS_TOUCH_START, data->buf,
+ data->max_touches * NVT_TS_TOUCH_SIZE);
+ if (error)
+ return IRQ_HANDLED;
+
+ for (i = 0; i < data->max_touches; i++) {
+ touch = &data->buf[i * NVT_TS_TOUCH_SIZE];
+
+ if (touch[0] == NVT_TS_TOUCH_INVALID)
+ continue;
+
+ slot = touch[0] >> NVT_TS_TOUCH_SLOT_SHIFT;
+ if (slot < 1 || slot > data->max_touches) {
+ dev_warn(dev, "slot %d out of range, ignoring\n", slot);
+ continue;
+ }
+
+ switch (touch[0] & NVT_TS_TOUCH_TYPE_MASK) {
+ case NVT_TS_TOUCH_NEW:
+ case NVT_TS_TOUCH_UPDATE:
+ active = true;
+ break;
+ case NVT_TS_TOUCH_RELEASE:
+ active = false;
+ break;
+ default:
+ dev_warn(dev, "slot %d unknown state %d\n", slot, touch[0] & 7);
+ continue;
+ }
+
+ slot--;
+ x = (touch[1] << 4) | (touch[3] >> 4);
+ y = (touch[2] << 4) | (touch[3] & 0x0f);
+
+ input_mt_slot(data->input, slot);
+ input_mt_report_slot_state(data->input, MT_TOOL_FINGER, active);
+ touchscreen_report_pos(data->input, &data->prop, x, y, true);
+ }
+
+ input_mt_sync_frame(data->input);
+ input_sync(data->input);
+
+ return IRQ_HANDLED;
+}
+
+static int nvt_ts_start(struct input_dev *dev)
+{
+ struct nvt_ts_data *data = input_get_drvdata(dev);
+
+ enable_irq(data->client->irq);
+ gpiod_set_value_cansleep(data->reset_gpio, 0);
+
+ return 0;
+}
+
+static void nvt_ts_stop(struct input_dev *dev)
+{
+ struct nvt_ts_data *data = input_get_drvdata(dev);
+
+ disable_irq(data->client->irq);
+ gpiod_set_value_cansleep(data->reset_gpio, 1);
+}
+
+static int nvt_ts_suspend(struct device *dev)
+{
+ struct nvt_ts_data *data = i2c_get_clientdata(to_i2c_client(dev));
+
+ mutex_lock(&data->input->mutex);
+ if (input_device_enabled(data->input))
+ nvt_ts_stop(data->input);
+ mutex_unlock(&data->input->mutex);
+
+ return 0;
+}
+
+static int nvt_ts_resume(struct device *dev)
+{
+ struct nvt_ts_data *data = i2c_get_clientdata(to_i2c_client(dev));
+
+ mutex_lock(&data->input->mutex);
+ if (input_device_enabled(data->input))
+ nvt_ts_start(data->input);
+ mutex_unlock(&data->input->mutex);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(nvt_ts_pm_ops, nvt_ts_suspend, nvt_ts_resume);
+
+static int nvt_ts_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ int error, width, height, irq_type;
+ struct nvt_ts_data *data;
+ struct input_dev *input;
+
+ if (!client->irq) {
+ dev_err(dev, "Error no irq specified\n");
+ return -EINVAL;
+ }
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->client = client;
+ i2c_set_clientdata(client, data);
+
+ data->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(data->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(data->reset_gpio), "requesting reset GPIO\n");
+
+ /* Wait for controller to come out of reset before params read */
+ msleep(100);
+ error = nvt_ts_read_data(data->client, NVT_TS_PARAMETERS_START, data->buf,
+ NVT_TS_PARAMS_SIZE);
+ gpiod_set_value_cansleep(data->reset_gpio, 1); /* Put back in reset */
+ if (error)
+ return error;
+
+ width = get_unaligned_be16(&data->buf[NVT_TS_PARAMS_WIDTH]);
+ height = get_unaligned_be16(&data->buf[NVT_TS_PARAMS_HEIGHT]);
+ data->max_touches = data->buf[NVT_TS_PARAMS_MAX_TOUCH];
+ irq_type = data->buf[NVT_TS_PARAMS_IRQ_TYPE];
+
+ if (width > NVT_TS_MAX_SIZE || height >= NVT_TS_MAX_SIZE ||
+ data->max_touches > NVT_TS_MAX_TOUCHES ||
+ irq_type >= ARRAY_SIZE(nvt_ts_irq_type) ||
+ data->buf[NVT_TS_PARAMS_WAKE_TYPE] != NVT_TS_SUPPORTED_WAKE_TYPE ||
+ data->buf[NVT_TS_PARAMS_CHIP_ID] != NVT_TS_SUPPORTED_CHIP_ID) {
+ dev_err(dev, "Unsupported touchscreen parameters: %*ph\n",
+ NVT_TS_PARAMS_SIZE, data->buf);
+ return -EIO;
+ }
+
+ dev_dbg(dev, "Detected %dx%d touchscreen with %d max touches\n",
+ width, height, data->max_touches);
+
+ if (data->buf[NVT_TS_PARAMS_MAX_BUTTONS])
+ dev_warn(dev, "Touchscreen buttons are not supported\n");
+
+ input = devm_input_allocate_device(dev);
+ if (!input)
+ return -ENOMEM;
+
+ input->name = client->name;
+ input->id.bustype = BUS_I2C;
+ input->open = nvt_ts_start;
+ input->close = nvt_ts_stop;
+
+ input_set_abs_params(input, ABS_MT_POSITION_X, 0, width - 1, 0, 0);
+ input_set_abs_params(input, ABS_MT_POSITION_Y, 0, height - 1, 0, 0);
+ touchscreen_parse_properties(input, true, &data->prop);
+
+ error = input_mt_init_slots(input, data->max_touches,
+ INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
+ if (error)
+ return error;
+
+ data->input = input;
+ input_set_drvdata(input, data);
+
+ error = devm_request_threaded_irq(dev, client->irq, NULL, nvt_ts_irq,
+ IRQF_ONESHOT | IRQF_NO_AUTOEN | nvt_ts_irq_type[irq_type],
+ client->name, data);
+ if (error)
+ return dev_err_probe(dev, error, "requesting irq\n");
+
+ return input_register_device(input);
+}
+
+static const struct i2c_device_id nvt_ts_i2c_id[] = {
+ { "NVT-ts" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, nvt_ts_i2c_id);
+
+static struct i2c_driver nvt_ts_driver = {
+ .driver = {
+ .name = "novatek-nvt-ts",
+ .pm = pm_sleep_ptr(&nvt_ts_pm_ops),
+ },
+ .probe_new = nvt_ts_probe,
+ .id_table = nvt_ts_i2c_id,
+};
+
+module_i2c_driver(nvt_ts_driver);
+
+MODULE_DESCRIPTION("Novatek NVT-ts touchscreen driver");
+MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
+MODULE_LICENSE("GPL");
--
2.39.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] platform/x86: Add driver for Yoga Tablet Mode switch
From: Hans de Goede @ 2023-03-26 11:16 UTC (permalink / raw)
To: Armin Wolf, Andrew Kallmeyer
Cc: platform-driver-x86, Gergo Koteles, Ike Panhc, linux-input,
Barnabás Pőcze
In-Reply-To: <c0a74480-52f9-3e4d-f4b5-5c39611e8965@gmx.de>
Hi,
On 3/25/23 22:49, Armin Wolf wrote:
> Am 25.03.23 um 16:16 schrieb Andrew Kallmeyer:
>
>> On Sat, Mar 25, 2023 at 12:10 AM Armin Wolf <W_Armin@gmx.de> wrote:
>>> Hi,
>>>
>>> is it really necessary to allow userspace to read/write ec_trigger? The ACPI device
>>> used for triggering the EC is only initialized during probing, so changing the value
>>> of ec_trigger will make no difference in such cases.
>>>
>>> Maybe you could change module_param(ec_trigger, bool, 0644) to module_param(ec_trigger, bool, 0)?
>>>
>>> Armin Wolf
>> Great point, this is actually a regression from Gergo's original patch
>> that I didn't realize I caused. I believe the intention was that if
>> the quirk detection code doesn't have full coverage users can set the
>> parameter themselves. In Gergo's code it used the acpi_device from
>> ideapad-laptop.c which is always loaded if it exists. Now I only load
>> it if ec_trigger is true at probe time, I think I should update it to
>> load the acpi device always if it exists so that the user can set this
>> parameter at any time. I suppose I would just remove the if
>> (ec_trigger) (and the debug print) in the probe code when I load it.
>>
>> That is, unless you think it is best to just patch in more models to
>> the quirk detection later and not provide a parameter. Barnabás
>> actually suggested removing the ec_trigger flag completely because
>> right now the code isn't relying on it, but I think that is a bug.
>
> I think it is best to still provide this module param for people who need
> it, but only allow enabling it when loading the module. This way userspace
> should not be able to read/write ec_trigger after the module has been loaded.
>
> Because of this, i believe the ACPI device should only be initialized when
> the DMI table says its necessary or ec_trigger was set. So the current solution
> is fine for me, except for ec_trigger being accessible to userspace after
> the module was loaded.
Right, ack.
For the next version please use 0444 and not 0 for the sysfs file rights on the file, this way users can still read the parameters under /sys/modules/.../parameters/ec_trigger to e.g. check if the parameter was set, which is useful to e.g. see if an /etc/modprobe.d/foo.conf dropin file is working as expected.
Also please address Barnabás' remarks. I have not taken a really close look myself yet, but given the close look others have already given this drivers I don't expect to find any issues.
So please prepare a v3 (when you have time) and then I'll try to merge that right away.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 2/2] platform/x86: Add driver for Yoga Tablet Mode switch
From: Armin Wolf @ 2023-03-25 21:49 UTC (permalink / raw)
To: Andrew Kallmeyer
Cc: platform-driver-x86, Gergo Koteles, Ike Panhc, linux-input,
Hans de Goede, Barnabás Pőcze
In-Reply-To: <CAG4kvq9apmScR2Y8VO4Xb=4QPVw3XE19m2fR+L_xgER2ka+BvQ@mail.gmail.com>
Am 25.03.23 um 16:16 schrieb Andrew Kallmeyer:
> On Sat, Mar 25, 2023 at 12:10 AM Armin Wolf <W_Armin@gmx.de> wrote:
>> Hi,
>>
>> is it really necessary to allow userspace to read/write ec_trigger? The ACPI device
>> used for triggering the EC is only initialized during probing, so changing the value
>> of ec_trigger will make no difference in such cases.
>>
>> Maybe you could change module_param(ec_trigger, bool, 0644) to module_param(ec_trigger, bool, 0)?
>>
>> Armin Wolf
> Great point, this is actually a regression from Gergo's original patch
> that I didn't realize I caused. I believe the intention was that if
> the quirk detection code doesn't have full coverage users can set the
> parameter themselves. In Gergo's code it used the acpi_device from
> ideapad-laptop.c which is always loaded if it exists. Now I only load
> it if ec_trigger is true at probe time, I think I should update it to
> load the acpi device always if it exists so that the user can set this
> parameter at any time. I suppose I would just remove the if
> (ec_trigger) (and the debug print) in the probe code when I load it.
>
> That is, unless you think it is best to just patch in more models to
> the quirk detection later and not provide a parameter. Barnabás
> actually suggested removing the ec_trigger flag completely because
> right now the code isn't relying on it, but I think that is a bug.
I think it is best to still provide this module param for people who need
it, but only allow enabling it when loading the module. This way userspace
should not be able to read/write ec_trigger after the module has been loaded.
Because of this, i believe the ACPI device should only be initialized when
the DMI table says its necessary or ec_trigger was set. So the current solution
is fine for me, except for ec_trigger being accessible to userspace after
the module was loaded.
Armin Wolf
^ permalink raw reply
* Re: [RESEND PATCH 1/2] HID: Add driver for RC Simulator Controllers
From: Pavel Machek @ 2023-03-25 16:08 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Marcus Folkesson, Jonathan Corbet, Jiri Kosina,
Linux Doc Mailing List, lkml, open list:HID CORE LAYER
In-Reply-To: <CAO-hwJ+3Yrr--cr=r5+jvs4A=A-cmDtrKQETo=YOYDC3nXTMBg@mail.gmail.com>
Hi!
> > +Many RC controllers is able to configure which stick goes to which channel.
> > +This is also configurable in most simulators, so a matching is not necessary.
While it is configurable, we should try to do the good job "by default". Configuring controllers
can take hours, and it is not fun.
> > +The driver is generating the following input event for on channels:
> > +
> > ++---------+----------------+
> > +| Channel | Event |
> > ++=========+================+
> > +| 1 | ABS_Y |
> > ++---------+----------------+
> > +| 2 | ABS_X |
> > ++---------+----------------+
> > +| 3 | ABS_RY |
> > ++---------+----------------+
> > +| 4 | ABS_RX |
> > ++---------+----------------+
> > +| 5 | BTN_A |
> > ++---------+----------------+
> > +| 6 | BTN_B |
> > ++---------+----------------+
If one of these is normally used as throttle and rudder, it should be marked as such...
User can then remap it if he does not like the mapping.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2 2/2] platform/x86: Add driver for Yoga Tablet Mode switch
From: Andrew Kallmeyer @ 2023-03-25 15:16 UTC (permalink / raw)
To: Armin Wolf
Cc: platform-driver-x86, Gergo Koteles, Ike Panhc, linux-input,
Hans de Goede, Barnabás Pőcze
In-Reply-To: <7584e398-202a-dcee-ef5d-47a3989b06ab@gmx.de>
On Sat, Mar 25, 2023 at 12:10 AM Armin Wolf <W_Armin@gmx.de> wrote:
>
> Hi,
>
> is it really necessary to allow userspace to read/write ec_trigger? The ACPI device
> used for triggering the EC is only initialized during probing, so changing the value
> of ec_trigger will make no difference in such cases.
>
> Maybe you could change module_param(ec_trigger, bool, 0644) to module_param(ec_trigger, bool, 0)?
>
> Armin Wolf
Great point, this is actually a regression from Gergo's original patch
that I didn't realize I caused. I believe the intention was that if
the quirk detection code doesn't have full coverage users can set the
parameter themselves. In Gergo's code it used the acpi_device from
ideapad-laptop.c which is always loaded if it exists. Now I only load
it if ec_trigger is true at probe time, I think I should update it to
load the acpi device always if it exists so that the user can set this
parameter at any time. I suppose I would just remove the if
(ec_trigger) (and the debug print) in the probe code when I load it.
That is, unless you think it is best to just patch in more models to
the quirk detection later and not provide a parameter. Barnabás
actually suggested removing the ec_trigger flag completely because
right now the code isn't relying on it, but I think that is a bug.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: atmel,maxtouch: add linux,keycodes
From: André Apitzsch @ 2023-03-25 10:37 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Linus Walleij, linux-input,
devicetree, linux-arm-kernel, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20230227205035.18551-1-git@apitzsch.eu>
Am Montag, dem 27.02.2023 um 21:50 +0100 schrieb André Apitzsch:
> In some configurations the touch controller can support the touch keys.
> Document the linux,keycodes property that enables those keys and
> specifies the keycodes that should be used to report the key events.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
> ---
> .../devicetree/bindings/input/atmel,maxtouch.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> index 3ec579d63570..c40799355ed7 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> @@ -14,6 +14,9 @@ description: |
> Atmel maXTouch touchscreen or touchpads such as the mXT244
> and similar devices.
>
> +allOf:
> + - $ref: input.yaml#
> +
> properties:
> compatible:
> const: atmel,maxtouch
> @@ -60,6 +63,10 @@ properties:
> or experiment to determine which bit corresponds to which input. Use
> KEY_RESERVED for unused padding values.
>
> + linux,keycodes:
> + minItems: 1
> + maxItems: 8
> +
> atmel,wakeup-method:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: |
>
> base-commit: 982818426a0ffaf93b0621826ed39a84be3d7d62
Hi Nick, hi Dmitry,
Friendly ping.
What is missing to get this up-streamed?
Best regards,
André
^ permalink raw reply
* Re: [PATCH v2 2/2] platform/x86: Add driver for Yoga Tablet Mode switch
From: Armin Wolf @ 2023-03-25 7:10 UTC (permalink / raw)
To: Andrew Kallmeyer, platform-driver-x86
Cc: Gergo Koteles, Ike Panhc, linux-input, Hans de Goede,
Barnabás Pőcze
In-Reply-To: <20230323025200.5462-3-kallmeyeras@gmail.com>
Am 23.03.23 um 03:52 schrieb Andrew Kallmeyer:
> From: Gergo Koteles <soyer@irl.hu>
>
> This WMI driver for the tablet mode control switch for Lenovo Yoga
> notebooks was originally written by Gergo Koteles. The mode is mapped to
> a SW_TABLET_MODE switch capable input device.
>
> Andrew followed the suggestions that were posted in reply to Gergo's RFC
> patch, and on the v1 version of this patch to follow-up and get it
> merged.
>
> Changes from Gergo's RFC:
>
> - Refactored obtaining a reference to the EC ACPI device needed for the
> quirk implementation as suggested by Hans de Goede
> - Applied small fixes and switched to devm_input_allocate_device() and
> removing input_unregister_device() as suggested by Barnabás Pőcze.
> - Merged the lenovo_ymc_trigger_ec function with the
> ideapad_trigger_ymc_next_read function since it was no longer
> external.
> - Added the word "Tablet" to the driver description to hopefully make
> it more clear.
> - Fixed the LENOVO_YMC_QUERY_METHOD ID and the name string for the EC
> APCI device trigged for the quirk
> - Triggered the input event on probe so that the initial tablet mode
> state when the driver is loaded is reported to userspace as suggested
> by Armin Wolf.
>
> We have tested this on the Yoga 7 14AIL7 for the non-quirk path and on
> the Yoga 7 14ARB7 which has the firmware bug that requires triggering
> the embedded controller to send the mode change events. This workaround
> is also used by the Windows drivers.
>
> According to reports at https://github.com/lukas-w/yoga-usage-mode,
> which uses the same WMI devices, the following models should also work:
> Yoga C940, Ideapad flex 14API, Yoga 9 14IAP7, Yoga 7 14ARB7, etc.
>
> Signed-off-by: Gergo Koteles <soyer@irl.hu>
> Co-developed-by: Andrew Kallmeyer <kallmeyeras@gmail.com>
> Signed-off-by: Andrew Kallmeyer <kallmeyeras@gmail.com>
> Link: https://lore.kernel.org/r/20221004214332.35934-1-soyer@irl.hu/
> Link: https://lore.kernel.org/platform-driver-x86/20230310041726.217447-1-kallmeyeras@gmail.com/
> ---
> drivers/platform/x86/Kconfig | 10 ++
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/ideapad-laptop.h | 1 +
> drivers/platform/x86/lenovo-ymc.c | 187 ++++++++++++++++++++++++++
> 4 files changed, 199 insertions(+)
> create mode 100644 drivers/platform/x86/lenovo-ymc.c
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 5692385e2..858be0c65 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -470,6 +470,16 @@ config IDEAPAD_LAPTOP
> This is a driver for Lenovo IdeaPad netbooks contains drivers for
> rfkill switch, hotkey, fan control and backlight control.
>
> +config LENOVO_YMC
> + tristate "Lenovo Yoga Tablet Mode Control"
> + depends on ACPI_WMI
> + depends on INPUT
> + depends on IDEAPAD_LAPTOP
> + select INPUT_SPARSEKMAP
> + help
> + This driver maps the Tablet Mode Control switch to SW_TABLET_MODE input
> + events for Lenovo Yoga notebooks.
> +
> config SENSORS_HDAPS
> tristate "Thinkpad Hard Drive Active Protection System (hdaps)"
> depends on INPUT
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 1d3d1b025..10054cdea 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_UV_SYSFS) += uv_sysfs.o
> # IBM Thinkpad and Lenovo
> obj-$(CONFIG_IBM_RTL) += ibm_rtl.o
> obj-$(CONFIG_IDEAPAD_LAPTOP) += ideapad-laptop.o
> +obj-$(CONFIG_LENOVO_YMC) += lenovo-ymc.o
> obj-$(CONFIG_SENSORS_HDAPS) += hdaps.o
> obj-$(CONFIG_THINKPAD_ACPI) += thinkpad_acpi.o
> obj-$(CONFIG_THINKPAD_LMI) += think-lmi.o
> diff --git a/drivers/platform/x86/ideapad-laptop.h b/drivers/platform/x86/ideapad-laptop.h
> index 7dd8ce027..2564cb1cd 100644
> --- a/drivers/platform/x86/ideapad-laptop.h
> +++ b/drivers/platform/x86/ideapad-laptop.h
> @@ -35,6 +35,7 @@ enum {
> VPCCMD_W_FAN,
> VPCCMD_R_RF,
> VPCCMD_W_RF,
> + VPCCMD_W_YMC = 0x2A,
> VPCCMD_R_FAN = 0x2B,
> VPCCMD_R_SPECIAL_BUTTONS = 0x31,
> VPCCMD_W_BL_POWER = 0x33,
> diff --git a/drivers/platform/x86/lenovo-ymc.c b/drivers/platform/x86/lenovo-ymc.c
> new file mode 100644
> index 000000000..c64f7ec85
> --- /dev/null
> +++ b/drivers/platform/x86/lenovo-ymc.c
> @@ -0,0 +1,187 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * lenovo-ymc.c - Lenovo Yoga Mode Control driver
> + *
> + * Copyright © 2022 Gergo Koteles <soyer@irl.hu>
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/dmi.h>
> +#include <linux/input.h>
> +#include <linux/input/sparse-keymap.h>
> +#include <linux/wmi.h>
> +#include "ideapad-laptop.h"
> +
> +#define LENOVO_YMC_EVENT_GUID "06129D99-6083-4164-81AD-F092F9D773A6"
> +#define LENOVO_YMC_QUERY_GUID "09B0EE6E-C3FD-4243-8DA1-7911FF80BB8C"
> +
> +#define LENOVO_YMC_QUERY_INSTANCE 0
> +#define LENOVO_YMC_QUERY_METHOD 0x01
> +
> +static bool ec_trigger __read_mostly;
> +module_param(ec_trigger, bool, 0644);
> +MODULE_PARM_DESC(ec_trigger, "Enable EC triggering to emit YMC events");
Hi,
is it really necessary to allow userspace to read/write ec_trigger? The ACPI device
used for triggering the EC is only initialized during probing, so changing the value
of ec_trigger will make no difference in such cases.
Maybe you could change module_param(ec_trigger, bool, 0644) to module_param(ec_trigger, bool, 0)?
Armin Wolf
> +
> +static const struct dmi_system_id ec_trigger_quirk_dmi_table[] = {
> + {
> + // Lenovo Yoga 7 14ARB7
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "82QF"),
> + },
> + },
> + { },
> +};
> +
> +struct lenovo_ymc_private {
> + struct input_dev *input_dev;
> + struct acpi_device *ec_acpi_dev;
> +};
> +
> +static void lenovo_ymc_trigger_ec(struct wmi_device *wdev, struct lenovo_ymc_private *priv)
> +{
> + int err;
> +
> + if (!ec_trigger || !priv || !priv->ec_acpi_dev)
> + return;
> + err = write_ec_cmd(priv->ec_acpi_dev->handle, VPCCMD_W_YMC, 1);
> + if (err)
> + dev_warn(&wdev->dev, "Could not write YMC: %d\n", err);
> +}
> +
> +static const struct key_entry lenovo_ymc_keymap[] = {
> + // Laptop
> + { KE_SW, 0x01, { .sw = { SW_TABLET_MODE, 0 } } },
> + // Tablet
> + { KE_SW, 0x02, { .sw = { SW_TABLET_MODE, 1 } } },
> + // Drawing Board
> + { KE_SW, 0x03, { .sw = { SW_TABLET_MODE, 1 } } },
> + // Tent
> + { KE_SW, 0x04, { .sw = { SW_TABLET_MODE, 1 } } },
> + { KE_END },
> +};
> +
> +static void lenovo_ymc_notify(struct wmi_device *wdev, union acpi_object *data)
> +{
> + struct lenovo_ymc_private *priv = dev_get_drvdata(&wdev->dev);
> +
> + u32 input_val = 0;
> + struct acpi_buffer input = {sizeof(input_val), &input_val};
> + struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
> + acpi_status status;
> + union acpi_object *obj;
> + int code;
> +
> + status = wmi_evaluate_method(LENOVO_YMC_QUERY_GUID,
> + LENOVO_YMC_QUERY_INSTANCE,
> + LENOVO_YMC_QUERY_METHOD,
> + &input, &output);
> +
> + if (ACPI_FAILURE(status)) {
> + dev_warn(&wdev->dev,
> + "Failed to evaluate query method: %s\n",
> + acpi_format_exception(status));
> + return;
> + }
> +
> + obj = output.pointer;
> +
> + if (obj->type != ACPI_TYPE_INTEGER) {
> + dev_warn(&wdev->dev,
> + "WMI event data is not an integer\n");
> + goto free_obj;
> + }
> + code = obj->integer.value;
> +
> + if (!sparse_keymap_report_event(priv->input_dev, code, 1, true))
> + dev_warn(&wdev->dev, "Unknown key %d pressed\n", code);
> +
> +free_obj:
> + kfree(obj);
> + lenovo_ymc_trigger_ec(wdev, priv);
> +}
> +
> +static void lenovo_ymc_remove(struct wmi_device *wdev)
> +{
> + struct lenovo_ymc_private *priv = dev_get_drvdata(&wdev->dev);
> + acpi_dev_put(priv->ec_acpi_dev);
> +}
> +
> +static int lenovo_ymc_probe(struct wmi_device *wdev, const void *ctx)
> +{
> + struct input_dev *input_dev;
> + struct lenovo_ymc_private *priv;
> + int err;
> +
> + ec_trigger |= dmi_check_system(ec_trigger_quirk_dmi_table);
> +
> + priv = devm_kzalloc(&wdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + if (ec_trigger) {
> + pr_debug("Lenovo YMC enable EC triggering.\n");
> + priv->ec_acpi_dev = acpi_dev_get_first_match_dev("VPC2004", NULL, -1);
> + if (!priv->ec_acpi_dev) {
> + dev_err(&wdev->dev, "Could not find EC ACPI device.\n");
> + return -ENODEV;
> + }
> + }
> +
> + input_dev = devm_input_allocate_device(&wdev->dev);
> + if (!input_dev)
> + return -ENOMEM;
> +
> + input_dev->name = "Lenovo Yoga Tablet Mode Control switch";
> + input_dev->phys = LENOVO_YMC_EVENT_GUID "/input0";
> + input_dev->id.bustype = BUS_HOST;
> + input_dev->dev.parent = &wdev->dev;
> +
> + input_set_capability(input_dev, EV_SW, SW_TABLET_MODE);
> +
> + err = sparse_keymap_setup(input_dev, lenovo_ymc_keymap, NULL);
> + if (err) {
> + dev_err(&wdev->dev,
> + "Could not set up input device keymap: %d\n", err);
> + return err;
> + }
> +
> + err = input_register_device(input_dev);
> + if (err) {
> + dev_err(&wdev->dev,
> + "Could not register input device: %d\n", err);
> + return err;
> + }
> +
> + priv->input_dev = input_dev;
> + dev_set_drvdata(&wdev->dev, priv);
> +
> + // Report the state for the first time on probe
> + lenovo_ymc_trigger_ec(wdev, priv);
> + lenovo_ymc_notify(wdev, NULL);
> + return 0;
> +}
> +
> +static const struct wmi_device_id lenovo_ymc_wmi_id_table[] = {
> + { .guid_string = LENOVO_YMC_EVENT_GUID },
> + { }
> +};
> +MODULE_DEVICE_TABLE(wmi, lenovo_ymc_wmi_id_table);
> +
> +static struct wmi_driver lenovo_ymc_driver = {
> + .driver = {
> + .name = "lenovo-ymc",
> + },
> + .id_table = lenovo_ymc_wmi_id_table,
> + .probe = lenovo_ymc_probe,
> + .notify = lenovo_ymc_notify,
> + .remove = lenovo_ymc_remove,
> +};
> +
> +module_wmi_driver(lenovo_ymc_driver);
> +
> +MODULE_AUTHOR("Gergo Koteles <soyer@irl.hu>");
> +MODULE_DESCRIPTION("Lenovo Yoga Mode Control driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v2 0/2] platform/x86: Add driver for Yoga Tablet mode switch
From: André Apitzsch @ 2023-03-24 19:37 UTC (permalink / raw)
To: Andrew Kallmeyer, platform-driver-x86
Cc: Gergo Koteles, Ike Panhc, linux-input, Hans de Goede, Armin Wolf,
Barnabás Pőcze
In-Reply-To: <20230323025200.5462-1-kallmeyeras@gmail.com>
Am Mittwoch, dem 22.03.2023 um 19:51 -0700 schrieb Andrew Kallmeyer:
> This driver maps the Lenovo Yoga tablet mode switch to a SW_TABLET_MODE input
> device. This will make the tablet status available to desktop environments.
>
> This patch series is the result of the discussion at
> https://lore.kernel.org/r/CAG4kvq9US=-NjyXFMzJYu2zCJryJWtOc7FGZbrewpgCDjdAkbg@mail.gmail.com/
>
> I decided to follow-up on the patch Gergo wrote and respond to the review
> comments to get it merged and available for everyone.
>
> Gergo and I have tested this on the Yoga 7 14ARB7, and the Yoga 7 14AIL7
> respectively. Additionally, according to reports at
> https://github.com/lukas-w/yoga-usage-mode, which uses the same WMI devices,
> this driver should work with:
> Yoga C940, Ideapad flex 14API, Yoga 9 14IAP7, Yoga 7 14ARB7, etc.
>
> [..]
>
> Andrew Kallmeyer (1):
> platform/x86: Move ideapad ACPI helpers to a new header
>
> Gergo Koteles (1):
> platform/x86: Add driver for Yoga Tablet Mode switch
>
> drivers/platform/x86/Kconfig | 10 ++
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/ideapad-laptop.c | 135 +------------------
> drivers/platform/x86/ideapad-laptop.h | 152 +++++++++++++++++++++
> drivers/platform/x86/lenovo-ymc.c | 187 ++++++++++++++++++++++++++
> 5 files changed, 351 insertions(+), 134 deletions(-)
> create mode 100644 drivers/platform/x86/ideapad-laptop.h
> create mode 100644 drivers/platform/x86/lenovo-ymc.c
>
Hi Andrew,
thank you for working on this.
Tested on Lenovo ThinkBook 14s Yoga ITL.
Tested-by: André Apitzsch <git@apitzsch.eu>
Best regards,
André
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: xpad - Treat Qanba controllers as Xbox360 controllers
From: Dmitry Torokhov @ 2023-03-24 17:40 UTC (permalink / raw)
To: Vicki Pfau
Cc: Lyude Paul, Benjamin Tissoires, linux-input,
Pierre-Loup A. Griffais
In-Reply-To: <20230324040446.3487725-2-vi@endrift.com>
On Thu, Mar 23, 2023 at 09:04:45PM -0700, Vicki Pfau wrote:
> From: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
>
> They act that way in PC mode.
>
> Reviewed-by: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS cbedf1a33970c9b825ae75b81fbd3e88e224a418
From: kernel test robot @ 2023-03-24 14:47 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: cbedf1a33970c9b825ae75b81fbd3e88e224a418 Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix
elapsed time: 726m
configs tested: 117
configs skipped: 9
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r021-20230322 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r021-20230322 gcc
arc randconfig-r043-20230322 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r023-20230322 clang
arm randconfig-r046-20230322 clang
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r023-20230322 gcc
arm64 randconfig-r025-20230322 gcc
csky defconfig gcc
csky randconfig-r011-20230322 gcc
csky randconfig-r012-20230322 gcc
csky randconfig-r016-20230322 gcc
csky randconfig-r024-20230322 gcc
hexagon randconfig-r014-20230322 clang
hexagon randconfig-r026-20230322 clang
hexagon randconfig-r041-20230322 clang
hexagon randconfig-r045-20230322 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001 gcc
i386 randconfig-a002 clang
i386 randconfig-a003 gcc
i386 randconfig-a004 clang
i386 randconfig-a005 gcc
i386 randconfig-a006 clang
i386 randconfig-a011 clang
i386 randconfig-a012 gcc
i386 randconfig-a013 clang
i386 randconfig-a014 gcc
i386 randconfig-a015 clang
i386 randconfig-a016 gcc
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r005-20230322 gcc
ia64 defconfig gcc
ia64 randconfig-r001-20230322 gcc
ia64 randconfig-r004-20230322 gcc
ia64 randconfig-r025-20230322 gcc
ia64 randconfig-r031-20230322 gcc
ia64 randconfig-r032-20230322 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r002-20230322 gcc
loongarch defconfig gcc
loongarch randconfig-r032-20230322 gcc
m68k allmodconfig gcc
m68k defconfig gcc
microblaze buildonly-randconfig-r002-20230322 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips maltasmvp_defconfig gcc
mips randconfig-r021-20230322 clang
mips randconfig-r034-20230322 gcc
nios2 defconfig gcc
nios2 randconfig-r002-20230322 gcc
nios2 randconfig-r036-20230322 gcc
openrisc defconfig gcc
openrisc randconfig-r015-20230322 gcc
openrisc randconfig-r033-20230322 gcc
parisc buildonly-randconfig-r006-20230322 gcc
parisc defconfig gcc
parisc randconfig-r003-20230322 gcc
parisc randconfig-r034-20230322 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r005-20230322 gcc
powerpc randconfig-r013-20230322 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r006-20230322 gcc
riscv defconfig gcc
riscv randconfig-r022-20230322 gcc
riscv randconfig-r042-20230322 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r044-20230322 gcc
sh allmodconfig gcc
sh buildonly-randconfig-r003-20230322 gcc
sh randconfig-r005-20230322 gcc
sh randconfig-r036-20230322 gcc
sparc buildonly-randconfig-r001-20230322 gcc
sparc defconfig gcc
sparc randconfig-r035-20230322 gcc
sparc64 randconfig-r024-20230322 gcc
sparc64 randconfig-r031-20230322 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001 clang
x86_64 randconfig-a002 gcc
x86_64 randconfig-a003 clang
x86_64 randconfig-a004 gcc
x86_64 randconfig-a005 clang
x86_64 randconfig-a006 gcc
x86_64 randconfig-a011 gcc
x86_64 randconfig-a012 clang
x86_64 randconfig-a013 gcc
x86_64 randconfig-a014 clang
x86_64 randconfig-a015 gcc
x86_64 randconfig-a016 clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r022-20230322 gcc
xtensa randconfig-r035-20230322 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 77987b872fcfeaf36b4760fe5d77a0cf9ac7fdbe
From: kernel test robot @ 2023-03-24 14:47 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: 77987b872fcfeaf36b4760fe5d77a0cf9ac7fdbe dt-bindings: input: Drop unneeded quotes
elapsed time: 726m
configs tested: 152
configs skipped: 9
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r001-20230322 gcc
alpha defconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r002-20230322 gcc
arc randconfig-r021-20230322 gcc
arc randconfig-r043-20230322 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r002-20230322 gcc
arm randconfig-r011-20230322 clang
arm randconfig-r014-20230323 gcc
arm randconfig-r023-20230322 clang
arm randconfig-r025-20230322 clang
arm randconfig-r032-20230322 gcc
arm randconfig-r036-20230324 gcc
arm randconfig-r046-20230322 clang
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r023-20230322 gcc
csky defconfig gcc
csky randconfig-r024-20230322 gcc
csky randconfig-r026-20230322 gcc
hexagon randconfig-r003-20230322 clang
hexagon randconfig-r031-20230322 clang
hexagon randconfig-r033-20230324 clang
hexagon randconfig-r041-20230322 clang
hexagon randconfig-r045-20230322 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001 gcc
i386 randconfig-a002 clang
i386 randconfig-a003 gcc
i386 randconfig-a004 clang
i386 randconfig-a005 gcc
i386 randconfig-a006 clang
i386 randconfig-a011 clang
i386 randconfig-a012 gcc
i386 randconfig-a013 clang
i386 randconfig-a014 gcc
i386 randconfig-a015 clang
i386 randconfig-a016 gcc
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r005-20230322 gcc
ia64 defconfig gcc
ia64 randconfig-r015-20230322 gcc
ia64 randconfig-r025-20230322 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r002-20230322 gcc
loongarch buildonly-randconfig-r003-20230322 gcc
loongarch defconfig gcc
loongarch randconfig-r032-20230322 gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r001-20230322 gcc
m68k buildonly-randconfig-r002-20230322 gcc
m68k buildonly-randconfig-r006-20230322 gcc
m68k defconfig gcc
m68k randconfig-r012-20230322 gcc
m68k randconfig-r026-20230322 gcc
m68k randconfig-r034-20230322 gcc
microblaze buildonly-randconfig-r004-20230322 gcc
microblaze buildonly-randconfig-r006-20230322 gcc
microblaze randconfig-r021-20230322 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips maltasmvp_defconfig gcc
mips randconfig-r004-20230322 gcc
mips randconfig-r005-20230322 gcc
mips randconfig-r012-20230323 gcc
mips randconfig-r021-20230322 clang
nios2 buildonly-randconfig-r005-20230322 gcc
nios2 defconfig gcc
nios2 randconfig-r005-20230322 gcc
nios2 randconfig-r016-20230322 gcc
nios2 randconfig-r016-20230323 gcc
nios2 randconfig-r033-20230322 gcc
nios2 randconfig-r036-20230322 gcc
openrisc defconfig gcc
openrisc randconfig-r014-20230322 gcc
openrisc randconfig-r023-20230322 gcc
parisc buildonly-randconfig-r005-20230322 gcc
parisc defconfig gcc
parisc randconfig-r013-20230323 gcc
parisc randconfig-r024-20230322 gcc
parisc randconfig-r025-20230322 gcc
parisc randconfig-r034-20230322 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r003-20230322 gcc
powerpc randconfig-r011-20230323 clang
powerpc randconfig-r013-20230322 gcc
powerpc randconfig-r015-20230322 gcc
powerpc randconfig-r015-20230323 clang
powerpc randconfig-r035-20230322 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r006-20230322 gcc
riscv defconfig gcc
riscv randconfig-r001-20230322 clang
riscv randconfig-r003-20230322 clang
riscv randconfig-r021-20230322 gcc
riscv randconfig-r022-20230322 gcc
riscv randconfig-r034-20230324 clang
riscv randconfig-r042-20230322 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r014-20230322 gcc
s390 randconfig-r022-20230322 gcc
s390 randconfig-r044-20230322 gcc
sh allmodconfig gcc
sh buildonly-randconfig-r003-20230322 gcc
sparc buildonly-randconfig-r001-20230322 gcc
sparc defconfig gcc
sparc randconfig-r011-20230322 gcc
sparc randconfig-r016-20230322 gcc
sparc64 buildonly-randconfig-r002-20230322 gcc
sparc64 randconfig-r001-20230322 gcc
sparc64 randconfig-r022-20230322 gcc
sparc64 randconfig-r031-20230322 gcc
sparc64 randconfig-r035-20230324 gcc
sparc64 randconfig-r036-20230322 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001 clang
x86_64 randconfig-a002 gcc
x86_64 randconfig-a003 clang
x86_64 randconfig-a004 gcc
x86_64 randconfig-a005 clang
x86_64 randconfig-a006 gcc
x86_64 randconfig-a011 gcc
x86_64 randconfig-a012 clang
x86_64 randconfig-a013 gcc
x86_64 randconfig-a014 clang
x86_64 randconfig-a015 gcc
x86_64 randconfig-a016 clang
x86_64 rhel-8.3 gcc
xtensa buildonly-randconfig-r004-20230322 gcc
xtensa randconfig-r012-20230322 gcc
xtensa randconfig-r013-20230322 gcc
xtensa randconfig-r032-20230324 gcc
xtensa randconfig-r035-20230322 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH v4] HID:hid-sensor-custom: Fix buffer overrun in device name
From: Jiri Kosina @ 2023-03-24 13:10 UTC (permalink / raw)
To: Todd Brandt
Cc: linux-input, linux-iio, linux-kernel, todd.e.brandt,
srinivas.pandruvada, jic23, p.jungkamp, stable
In-Reply-To: <20230314181256.15283-1-todd.e.brandt@intel.com>
On Tue, 14 Mar 2023, Todd Brandt wrote:
> On some platforms there are some platform devices created with
> invalid names. For example: "HID-SENSOR-INT-020b?.39.auto" instead
> of "HID-SENSOR-INT-020b.39.auto"
>
> This string include some invalid characters, hence it will fail to
> properly load the driver which will handle this custom sensor. Also
> it is a problem for some user space tools, which parses the device
> names from ftrace and dmesg.
>
> This is because the string, real_usage, is not NULL terminated and
> printed with %s to form device name.
>
> To address this, initialize the real_usage string with 0s.
>
> Reported-and-tested-by: Todd Brandt <todd.e.brandt@linux.intel.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217169
> Fixes: 98c062e82451 ("HID: hid-sensor-custom: Allow more custom iio sensors")
> Cc: stable@vger.kernel.org
> Suggested-by: Philipp Jungkamp <p.jungkamp@gmx.net>
> Signed-off-by: Philipp Jungkamp <p.jungkamp@gmx.net>
> Signed-off-by: Todd Brandt <todd.e.brandt@intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> Changes in v4:
> - add the Fixes line
> - add patch version change list
> Changes in v3:
> - update the changelog
> - add proper reviewed/signed/suggested links
> Changes in v2:
> - update the changelog
Applied to for-6.3/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/4] HID: kye: Add support for all kye tablets
From: Jiri Kosina @ 2023-03-24 13:00 UTC (permalink / raw)
To: Yangfl; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <CAAXyoMPMbYCV7br9DJn_KCq68RLnimockqU0uvsO8maT3ROxTA@mail.gmail.com>
On Sat, 11 Mar 2023, Yangfl wrote:
> > > This series refactor kye tablet descriptor fixup routine, by using a
> > > template and filling parameters on the fly, and add support for all
> > > possible kye tablets.
> > > ---
> > > v2: fix missing rsize assignment
> > > v3: fix geometry
> > > v4: split patches
> > >
> > > David Yang (4):
> > > HID: kye: Rewrite tablet descriptor fixup routine
> > > HID: kye: Generate tablet fixup descriptors on the fly
> > > HID: kye: Sort kye devices
> > > HID: kye: Add support for all kye tablets
> > >
> > > drivers/hid/hid-ids.h | 9 +-
> > > drivers/hid/hid-kye.c | 917 +++++++++++++++++----------------------
> > > drivers/hid/hid-quirks.c | 14 +-
> > > 3 files changed, 414 insertions(+), 526 deletions(-)
> >
> > Now queued in hid.git#for-6.4/kye, thanks David.
> >
> > --
> > Jiri Kosina
> > SUSE Labs
> >
>
> Thanks. But seems you missed the last patch.
Weird. Right you are. I have now fixed that. Thanks for catching it,
--
Jiri Kosina
SUSE Labs
^ 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