* [PATCH] dt-bindings: mfd: twl: Convert trivial subdevices to json-schema
From: Andreas Kemnade @ 2024-03-18 12:40 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt, lee,
alexandre.belloni, wim, linux, andreas, linux-input, devicetree,
linux-kernel, linux-rtc, linux-watchdog, linux-omap, sre
Convert subdevices with just an interrupt and compatbile to
json-schema and wire up already converted subdevices.
RTC is available in all variants, so allow it unconditionally
GPADC binding for TWL603X uses two different compatibles, so
specify just the compatible and not include it.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
Well, my name is in that yaml file, so I should take care of my sheep,
in case a step-by-step approach is acceptable this is at least a
checkpoint for me that I understand multi file binding mechanics
properly.
.../bindings/input/twl4030-pwrbutton.txt | 21 ------
.../devicetree/bindings/mfd/ti,twl.yaml | 68 +++++++++++++++++++
.../devicetree/bindings/rtc/twl-rtc.txt | 11 ---
.../bindings/watchdog/twl4030-wdt.txt | 10 ---
4 files changed, 68 insertions(+), 42 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
delete mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
delete mode 100644 Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
deleted file mode 100644
index 6c201a2ba8acf..0000000000000
--- a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Texas Instruments TWL family (twl4030) pwrbutton module
-
-This module is part of the TWL4030. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/ti,twl.yaml.
-
-This module provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be one of the following
- - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
-- interrupts: should be one of the following
- - <8>: For controllers compatible with twl4030
-
-Example:
-
-&twl {
- twl_pwrbutton: pwrbutton {
- compatible = "ti,twl4030-pwrbutton";
- interrupts = <8>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
index 52ed228fb1e7e..03d725d5294db 100644
--- a/Documentation/devicetree/bindings/mfd/ti,twl.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
@@ -15,6 +15,65 @@ description: |
USB transceiver or Audio amplifier.
These chips are connected to an i2c bus.
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl4030
+ then:
+ properties:
+ madc:
+ type: object
+ $ref: ../iio/adc/ti,twl4030-madc.yaml
+
+ unevaluatedProperties: false
+ bci:
+ type: object
+ $ref: ../power/supply/twl4030-charger.yaml
+
+ unevaluatedProperties: false
+ pwrbutton:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl4030-pwrbutton
+ interrupts:
+ const: 8
+
+ additionalProperties: false
+ watchdog:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl4030-wdt
+
+ additionalProperties: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6030
+ then:
+ properties:
+ gpadc:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl6030-gpadc
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6032
+ then:
+ properties:
+ gpadc:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl6032-gpadc
+
properties:
compatible:
description:
@@ -42,6 +101,15 @@ properties:
"#clock-cells":
const: 1
+ rtc:
+ type: object
+ properties:
+ compatible:
+ const: ti,twl4030-rtc
+ interrupts:
+ maxItems: 1
+ additionalProperties: false
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
deleted file mode 100644
index 8f9a94f2f8969..0000000000000
--- a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* Texas Instruments TWL4030/6030 RTC
-
-Required properties:
-- compatible : Should be "ti,twl4030-rtc"
-- interrupts : Should be the interrupt number.
-
-Example:
- rtc {
- compatible = "ti,twl4030-rtc";
- interrupts = <11>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
deleted file mode 100644
index 80a37193c0b86..0000000000000
--- a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Device tree bindings for twl4030-wdt driver (TWL4030 watchdog)
-
-Required properties:
- compatible = "ti,twl4030-wdt";
-
-Example:
-
-watchdog {
- compatible = "ti,twl4030-wdt";
-};
--
2.39.2
^ permalink raw reply related
* Re: [PATCH] dt-bindings: mfd: twl: Convert trivial subdevices to json-schema
From: Rob Herring @ 2024-03-18 15:07 UTC (permalink / raw)
To: Andreas Kemnade
Cc: dmitry.torokhov, krzysztof.kozlowski+dt, conor+dt, lee,
alexandre.belloni, wim, linux, linux-input, devicetree,
linux-kernel, linux-rtc, linux-watchdog, linux-omap, sre
In-Reply-To: <20240318124051.4166253-1-andreas@kemnade.info>
On Mon, Mar 18, 2024 at 01:40:50PM +0100, Andreas Kemnade wrote:
> Convert subdevices with just an interrupt and compatbile to
> json-schema and wire up already converted subdevices.
> RTC is available in all variants, so allow it unconditionally
> GPADC binding for TWL603X uses two different compatibles, so
> specify just the compatible and not include it.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> Well, my name is in that yaml file, so I should take care of my sheep,
> in case a step-by-step approach is acceptable this is at least a
> checkpoint for me that I understand multi file binding mechanics
> properly.
>
> .../bindings/input/twl4030-pwrbutton.txt | 21 ------
> .../devicetree/bindings/mfd/ti,twl.yaml | 68 +++++++++++++++++++
> .../devicetree/bindings/rtc/twl-rtc.txt | 11 ---
> .../bindings/watchdog/twl4030-wdt.txt | 10 ---
> 4 files changed, 68 insertions(+), 42 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> delete mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
> delete mode 100644 Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> deleted file mode 100644
> index 6c201a2ba8acf..0000000000000
> --- a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -Texas Instruments TWL family (twl4030) pwrbutton module
> -
> -This module is part of the TWL4030. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/ti,twl.yaml.
> -
> -This module provides a simple power button event via an Interrupt.
> -
> -Required properties:
> -- compatible: should be one of the following
> - - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
> -- interrupts: should be one of the following
> - - <8>: For controllers compatible with twl4030
> -
> -Example:
> -
> -&twl {
> - twl_pwrbutton: pwrbutton {
> - compatible = "ti,twl4030-pwrbutton";
> - interrupts = <8>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
> index 52ed228fb1e7e..03d725d5294db 100644
> --- a/Documentation/devicetree/bindings/mfd/ti,twl.yaml
> +++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
> @@ -15,6 +15,65 @@ description: |
> USB transceiver or Audio amplifier.
> These chips are connected to an i2c bus.
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,twl4030
> + then:
> + properties:
> + madc:
> + type: object
> + $ref: ../iio/adc/ti,twl4030-madc.yaml
Use 'absolute' paths: /schemas/iio/...
> +
Drop blank line
> + unevaluatedProperties: false
blank line between DT properties
> + bci:
> + type: object
> + $ref: ../power/supply/twl4030-charger.yaml
> +
> + unevaluatedProperties: false
> + pwrbutton:
> + type: object
> + properties:
> + compatible:
> + const: ti,twl4030-pwrbutton
> + interrupts:
> + const: 8
As 'interrupts' is a matrix, this needs to be:
interrupts:
items:
- items:
- const: 8
> +
> + additionalProperties: false
In the indented cases, it is preferred to put this before 'properties'.
> + watchdog:
> + type: object
> + properties:
> + compatible:
> + const: ti,twl4030-wdt
> +
> + additionalProperties: false
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,twl6030
> + then:
> + properties:
> + gpadc:
> + type: object
> + properties:
> + compatible:
> + const: ti,twl6030-gpadc
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,twl6032
> + then:
> + properties:
> + gpadc:
> + type: object
> + properties:
> + compatible:
> + const: ti,twl6032-gpadc
> +
> properties:
> compatible:
> description:
> @@ -42,6 +101,15 @@ properties:
> "#clock-cells":
> const: 1
>
> + rtc:
> + type: object
> + properties:
> + compatible:
> + const: ti,twl4030-rtc
> + interrupts:
> + maxItems: 1
> + additionalProperties: false
> +
> additionalProperties: false
>
> required:
^ permalink raw reply
* Re: [PATCH v3 1/4] HID: hid-picolcd*: Convert sprintf/scnprintf to sysfs_emit/sysfs_emit_at
From: Christophe JAILLET @ 2024-03-18 18:17 UTC (permalink / raw)
To: Li Zhijian, linux-kernel
Cc: Bruno Prémont, Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20240318012819.1405003-1-lizhijian@fujitsu.com>
Le 18/03/2024 à 02:28, Li Zhijian a écrit :
> Per filesystems/sysfs.rst, show() should only use sysfs_emit()
> or sysfs_emit_at() when formatting the value to be returned to user space.
>
> coccinelle complains that there are still a couple of functions that use
> snprintf(). Convert them to sysfs_emit().
>
> scnprintf() will be converted as weel if they have.
>
> Generally, this patch is generated by
> make coccicheck M=<path/to/file> MODE=patch \
> COCCI=scripts/coccinelle/api/device_attr_show.cocci
>
> No functional change intended
>
> CC: "Bruno Prémont" <bonbons@linux-vserver.org>
> CC: Jiri Kosina <jikos@kernel.org>
> CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> CC: linux-input@vger.kernel.org
> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
> ---
> V3:
> Covert more file(drivers/hid/hid-picolcd_fb.c) as suggested by Bruno
>
> This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
> Split them per subsystem so that the maintainer can review it easily
> [1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
> ---
> drivers/hid/hid-picolcd_core.c | 6 +++---
> drivers/hid/hid-picolcd_fb.c | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> index bbda231a7ce3..fa46fb6eab3f 100644
> --- a/drivers/hid/hid-picolcd_core.c
> +++ b/drivers/hid/hid-picolcd_core.c
> @@ -256,9 +256,9 @@ static ssize_t picolcd_operation_mode_show(struct device *dev,
> struct picolcd_data *data = dev_get_drvdata(dev);
>
> if (data->status & PICOLCD_BOOTLOADER)
> - return snprintf(buf, PAGE_SIZE, "[bootloader] lcd\n");
> + return sysfs_emit(buf, "[bootloader] lcd\n");
> else
> - return snprintf(buf, PAGE_SIZE, "bootloader [lcd]\n");
> + return sysfs_emit(buf, "bootloader [lcd]\n");
> }
>
> static ssize_t picolcd_operation_mode_store(struct device *dev,
> @@ -301,7 +301,7 @@ static ssize_t picolcd_operation_mode_delay_show(struct device *dev,
> {
> struct picolcd_data *data = dev_get_drvdata(dev);
>
> - return snprintf(buf, PAGE_SIZE, "%hu\n", data->opmode_delay);
> + return sysfs_emit(buf, "%hu\n", data->opmode_delay);
> }
>
> static ssize_t picolcd_operation_mode_delay_store(struct device *dev,
> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
> index d7dddd99d325..369c78d70e66 100644
> --- a/drivers/hid/hid-picolcd_fb.c
> +++ b/drivers/hid/hid-picolcd_fb.c
> @@ -424,9 +424,9 @@ static ssize_t picolcd_fb_update_rate_show(struct device *dev,
Hi,
just above we have:
for (i = 1; i <= PICOLCDFB_UPDATE_RATE_LIMIT; i++)
> if (ret >= PAGE_SIZE)
> break;
and PICOLCDFB_UPDATE_RATE_LIMIT is 10, so it is not possible to have ret
>= PAGE_SIZE. Should it happen, sysfs_emit_at() handles it.
So, this test can also be removed, IMHO.
CJ
> else if (i == fb_update_rate)
> - ret += scnprintf(buf+ret, PAGE_SIZE-ret, "[%u] ", i);
> + ret += sysfs_emit_at(buf, ret, "[%u] ", i);
> else
> - ret += scnprintf(buf+ret, PAGE_SIZE-ret, "%u ", i);
> + ret += sysfs_emit_at(buf, ret, "%u ", i);
> if (ret > 0)
> buf[min(ret, (size_t)PAGE_SIZE)-1] = '\n';
> return ret;
^ permalink raw reply
* Re: [PATCH v3 1/4] HID: hid-picolcd*: Convert sprintf/scnprintf to sysfs_emit/sysfs_emit_at
From: Zhijian Li (Fujitsu) @ 2024-03-19 1:21 UTC (permalink / raw)
To: Christophe JAILLET, linux-kernel@vger.kernel.org
Cc: Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
linux-input@vger.kernel.org
In-Reply-To: <588c9ba0-fcec-4700-a577-b604511f22a1@wanadoo.fr>
On 19/03/2024 02:17, Christophe JAILLET wrote:
> Le 18/03/2024 à 02:28, Li Zhijian a écrit :
>> Per filesystems/sysfs.rst, show() should only use sysfs_emit()
>> or sysfs_emit_at() when formatting the value to be returned to user space.
>>
>> coccinelle complains that there are still a couple of functions that use
>> snprintf(). Convert them to sysfs_emit().
>>
>> scnprintf() will be converted as weel if they have.
>>
>> Generally, this patch is generated by
>> make coccicheck M=<path/to/file> MODE=patch \
>> COCCI=scripts/coccinelle/api/device_attr_show.cocci
>>
>> No functional change intended
>>
>> CC: "Bruno Prémont" <bonbons@linux-vserver.org>
>> CC: Jiri Kosina <jikos@kernel.org>
>> CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> CC: linux-input@vger.kernel.org
>> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
>> ---
>> V3:
>> Covert more file(drivers/hid/hid-picolcd_fb.c) as suggested by Bruno
>>
>> This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
>> Split them per subsystem so that the maintainer can review it easily
>> [1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
>> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
>> ---
>> drivers/hid/hid-picolcd_core.c | 6 +++---
>> drivers/hid/hid-picolcd_fb.c | 4 ++--
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
>> index bbda231a7ce3..fa46fb6eab3f 100644
>> --- a/drivers/hid/hid-picolcd_core.c
>> +++ b/drivers/hid/hid-picolcd_core.c
>> @@ -256,9 +256,9 @@ static ssize_t picolcd_operation_mode_show(struct device *dev,
>> struct picolcd_data *data = dev_get_drvdata(dev);
>> if (data->status & PICOLCD_BOOTLOADER)
>> - return snprintf(buf, PAGE_SIZE, "[bootloader] lcd\n");
>> + return sysfs_emit(buf, "[bootloader] lcd\n");
>> else
>> - return snprintf(buf, PAGE_SIZE, "bootloader [lcd]\n");
>> + return sysfs_emit(buf, "bootloader [lcd]\n");
>> }
>> static ssize_t picolcd_operation_mode_store(struct device *dev,
>> @@ -301,7 +301,7 @@ static ssize_t picolcd_operation_mode_delay_show(struct device *dev,
>> {
>> struct picolcd_data *data = dev_get_drvdata(dev);
>> - return snprintf(buf, PAGE_SIZE, "%hu\n", data->opmode_delay);
>> + return sysfs_emit(buf, "%hu\n", data->opmode_delay);
>> }
>> static ssize_t picolcd_operation_mode_delay_store(struct device *dev,
>> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
>> index d7dddd99d325..369c78d70e66 100644
>> --- a/drivers/hid/hid-picolcd_fb.c
>> +++ b/drivers/hid/hid-picolcd_fb.c
>> @@ -424,9 +424,9 @@ static ssize_t picolcd_fb_update_rate_show(struct device *dev,
>
> Hi,
>
> just above we have:
> for (i = 1; i <= PICOLCDFB_UPDATE_RATE_LIMIT; i++)
>
>> if (ret >= PAGE_SIZE)
>> break;
>
> and PICOLCDFB_UPDATE_RATE_LIMIT is 10, so it is not possible to have ret >= PAGE_SIZE. Should it happen, sysfs_emit_at() handles it.
> So, this test can also be removed, IMHO.
Good catch, i will update it.
Thanks
Zhijian
>
> CJ
>
>> else if (i == fb_update_rate)
>> - ret += scnprintf(buf+ret, PAGE_SIZE-ret, "[%u] ", i);
>> + ret += sysfs_emit_at(buf, ret, "[%u] ", i);
>> else
>> - ret += scnprintf(buf+ret, PAGE_SIZE-ret, "%u ", i);
>> + ret += sysfs_emit_at(buf, ret, "%u ", i);
>> if (ret > 0)
>> buf[min(ret, (size_t)PAGE_SIZE)-1] = '\n';
>> return ret;
>
^ permalink raw reply
* [PATCH v4 1/4] HID: hid-picolcd*: Convert sprintf() family to sysfs_emit() family
From: Li Zhijian @ 2024-03-19 5:45 UTC (permalink / raw)
To: linux-kernel
Cc: Li Zhijian, Christophe JAILLET, Bruno Prémont, Jiri Kosina,
Benjamin Tissoires, linux-input
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() and scnprintf() will be converted as well if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
CC: "Bruno Prémont" <bonbons@linux-vserver.org>
CC: Jiri Kosina <jikos@kernel.org>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
V4:
Kill 'if (ret >= PAGE_SIZE)' which is always false in this context and sysfs_emit_at() is able to handle this case. # CJ
V3:
Convert more file(drivers/hid/hid-picolcd_fb.c) as suggested by Bruno
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-picolcd_core.c | 6 +++---
drivers/hid/hid-picolcd_fb.c | 8 +++-----
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index bbda231a7ce3..fa46fb6eab3f 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -256,9 +256,9 @@ static ssize_t picolcd_operation_mode_show(struct device *dev,
struct picolcd_data *data = dev_get_drvdata(dev);
if (data->status & PICOLCD_BOOTLOADER)
- return snprintf(buf, PAGE_SIZE, "[bootloader] lcd\n");
+ return sysfs_emit(buf, "[bootloader] lcd\n");
else
- return snprintf(buf, PAGE_SIZE, "bootloader [lcd]\n");
+ return sysfs_emit(buf, "bootloader [lcd]\n");
}
static ssize_t picolcd_operation_mode_store(struct device *dev,
@@ -301,7 +301,7 @@ static ssize_t picolcd_operation_mode_delay_show(struct device *dev,
{
struct picolcd_data *data = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%hu\n", data->opmode_delay);
+ return sysfs_emit(buf, "%hu\n", data->opmode_delay);
}
static ssize_t picolcd_operation_mode_delay_store(struct device *dev,
diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
index d7dddd99d325..063f9c01d2f7 100644
--- a/drivers/hid/hid-picolcd_fb.c
+++ b/drivers/hid/hid-picolcd_fb.c
@@ -421,12 +421,10 @@ static ssize_t picolcd_fb_update_rate_show(struct device *dev,
size_t ret = 0;
for (i = 1; i <= PICOLCDFB_UPDATE_RATE_LIMIT; i++)
- if (ret >= PAGE_SIZE)
- break;
- else if (i == fb_update_rate)
- ret += scnprintf(buf+ret, PAGE_SIZE-ret, "[%u] ", i);
+ if (i == fb_update_rate)
+ ret += sysfs_emit_at(buf, ret, "[%u] ", i);
else
- ret += scnprintf(buf+ret, PAGE_SIZE-ret, "%u ", i);
+ ret += sysfs_emit_at(buf, ret, "%u ", i);
if (ret > 0)
buf[min(ret, (size_t)PAGE_SIZE)-1] = '\n';
return ret;
--
2.29.2
^ permalink raw reply related
* [PATCH v4 2/4] HID: hid-sensor-custom: Convert sprintf() family to sysfs_emit() family
From: Li Zhijian @ 2024-03-19 5:45 UTC (permalink / raw)
To: linux-kernel
Cc: Li Zhijian, Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada,
Benjamin Tissoires, linux-input, linux-iio, Jonathan Cameron
In-Reply-To: <20240319054527.1581299-1-lizhijian@fujitsu.com>
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() and scnprintf() will be converted as well if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: Jiri Kosina <jikos@kernel.org>
CC: Jonathan Cameron <jic23@kernel.org>
CC: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
CC: linux-iio@vger.kernel.org
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
V3:
rewrap the line as will be under 80 chars and add Reviewed-by # Jonathan
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-sensor-custom.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
index d85398721659..ac214777d7d9 100644
--- a/drivers/hid/hid-sensor-custom.c
+++ b/drivers/hid/hid-sensor-custom.c
@@ -155,7 +155,7 @@ static ssize_t enable_sensor_show(struct device *dev,
{
struct hid_sensor_custom *sensor_inst = dev_get_drvdata(dev);
- return sprintf(buf, "%d\n", sensor_inst->enable);
+ return sysfs_emit(buf, "%d\n", sensor_inst->enable);
}
static int set_power_report_state(struct hid_sensor_custom *sensor_inst,
@@ -372,14 +372,13 @@ static ssize_t show_value(struct device *dev, struct device_attribute *attr,
sizeof(struct hid_custom_usage_desc),
usage_id_cmp);
if (usage_desc)
- return snprintf(buf, PAGE_SIZE, "%s\n",
- usage_desc->desc);
+ return sysfs_emit(buf, "%s\n", usage_desc->desc);
else
- return sprintf(buf, "not-specified\n");
+ return sysfs_emit(buf, "not-specified\n");
} else
return -EINVAL;
- return sprintf(buf, "%d\n", value);
+ return sysfs_emit(buf, "%d\n", value);
}
static ssize_t store_value(struct device *dev, struct device_attribute *attr,
--
2.29.2
^ permalink raw reply related
* [PATCH v4 4/4] HID: corsair,lenovo: Convert sprintf() family to sysfs_emit() family
From: Li Zhijian @ 2024-03-19 5:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhijian, Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20240319054527.1581299-1-lizhijian@fujitsu.com>
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() and scnprintf() will be converted as well if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: Jiri Kosina <jikos@kernel.org>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-corsair.c | 4 ++--
drivers/hid/hid-lenovo.c | 23 ++++++++++-------------
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/hid-corsair.c b/drivers/hid/hid-corsair.c
index 8c895c820b67..702f50e9841d 100644
--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -298,7 +298,7 @@ static ssize_t k90_show_macro_mode(struct device *dev,
goto out;
}
- ret = snprintf(buf, PAGE_SIZE, "%s\n", macro_mode);
+ ret = sysfs_emit(buf, "%s\n", macro_mode);
out:
kfree(data);
@@ -367,7 +367,7 @@ static ssize_t k90_show_current_profile(struct device *dev,
goto out;
}
- ret = snprintf(buf, PAGE_SIZE, "%d\n", current_profile);
+ ret = sysfs_emit(buf, "%d\n", current_profile);
out:
kfree(data);
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index f86c1ea83a03..e6b2ae68b8fb 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -555,7 +555,7 @@ static ssize_t attr_fn_lock_show(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data->fn_lock);
+ return sysfs_emit(buf, "%u\n", data->fn_lock);
}
static ssize_t attr_fn_lock_store(struct device *dev,
@@ -599,8 +599,7 @@ static ssize_t attr_sensitivity_show_cptkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *cptkbd_data = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- cptkbd_data->sensitivity);
+ return sysfs_emit(buf, "%u\n", cptkbd_data->sensitivity);
}
static ssize_t attr_sensitivity_store_cptkbd(struct device *dev,
@@ -628,8 +627,8 @@ static ssize_t attr_middleclick_workaround_show_cptkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *cptkbd_data = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- cptkbd_data->middleclick_workaround_cptkbd);
+ return sysfs_emit(buf, "%u\n",
+ cptkbd_data->middleclick_workaround_cptkbd);
}
static ssize_t attr_middleclick_workaround_store_cptkbd(struct device *dev,
@@ -809,7 +808,7 @@ static ssize_t attr_press_to_select_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->press_to_select);
+ return sysfs_emit(buf, "%u\n", data_pointer->press_to_select);
}
static ssize_t attr_press_to_select_store_tpkbd(struct device *dev,
@@ -839,7 +838,7 @@ static ssize_t attr_dragging_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->dragging);
+ return sysfs_emit(buf, "%u\n", data_pointer->dragging);
}
static ssize_t attr_dragging_store_tpkbd(struct device *dev,
@@ -869,7 +868,7 @@ static ssize_t attr_release_to_select_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->release_to_select);
+ return sysfs_emit(buf, "%u\n", data_pointer->release_to_select);
}
static ssize_t attr_release_to_select_store_tpkbd(struct device *dev,
@@ -899,7 +898,7 @@ static ssize_t attr_select_right_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", data_pointer->select_right);
+ return sysfs_emit(buf, "%u\n", data_pointer->select_right);
}
static ssize_t attr_select_right_store_tpkbd(struct device *dev,
@@ -929,8 +928,7 @@ static ssize_t attr_sensitivity_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- data_pointer->sensitivity);
+ return sysfs_emit(buf, "%u\n", data_pointer->sensitivity);
}
static ssize_t attr_sensitivity_store_tpkbd(struct device *dev,
@@ -958,8 +956,7 @@ static ssize_t attr_press_speed_show_tpkbd(struct device *dev,
struct hid_device *hdev = to_hid_device(dev);
struct lenovo_drvdata *data_pointer = hid_get_drvdata(hdev);
- return snprintf(buf, PAGE_SIZE, "%u\n",
- data_pointer->press_speed);
+ return sysfs_emit(buf, "%u\n", data_pointer->press_speed);
}
static ssize_t attr_press_speed_store_tpkbd(struct device *dev,
--
2.29.2
^ permalink raw reply related
* [PATCH v4 3/4] HID: roccat: Convert sprintf() family to sysfs_emit() family
From: Li Zhijian @ 2024-03-19 5:45 UTC (permalink / raw)
To: linux-kernel
Cc: Li Zhijian, Stefan Achatz, Jiri Kosina, Benjamin Tissoires,
linux-input
In-Reply-To: <20240319054527.1581299-1-lizhijian@fujitsu.com>
Per filesystems/sysfs.rst, show() should only use sysfs_emit()
or sysfs_emit_at() when formatting the value to be returned to user space.
coccinelle complains that there are still a couple of functions that use
snprintf(). Convert them to sysfs_emit().
sprintf() and scnprintf() will be converted as well if they have.
Generally, this patch is generated by
make coccicheck M=<path/to/file> MODE=patch \
COCCI=scripts/coccinelle/api/device_attr_show.cocci
No functional change intended
CC: Stefan Achatz <erazor_de@users.sourceforge.net>
CC: Jiri Kosina <jikos@kernel.org>
CC: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: linux-input@vger.kernel.org
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
This is a part of the work "Fix coccicheck device_attr_show warnings"[1]
Split them per subsystem so that the maintainer can review it easily
[1] https://lore.kernel.org/lkml/20240116041129.3937800-1-lizhijian@fujitsu.com/
---
drivers/hid/hid-roccat-isku.c | 2 +-
drivers/hid/hid-roccat-kone.c | 12 ++++++------
drivers/hid/hid-roccat-koneplus.c | 4 ++--
drivers/hid/hid-roccat-kovaplus.c | 10 +++++-----
drivers/hid/hid-roccat-pyra.c | 6 +++---
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/hid/hid-roccat-isku.c b/drivers/hid/hid-roccat-isku.c
index 458060403397..0cd6208fb371 100644
--- a/drivers/hid/hid-roccat-isku.c
+++ b/drivers/hid/hid-roccat-isku.c
@@ -61,7 +61,7 @@ static ssize_t isku_sysfs_show_actual_profile(struct device *dev,
{
struct isku_device *isku =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", isku->actual_profile);
+ return sysfs_emit(buf, "%d\n", isku->actual_profile);
}
static ssize_t isku_sysfs_set_actual_profile(struct device *dev,
diff --git a/drivers/hid/hid-roccat-kone.c b/drivers/hid/hid-roccat-kone.c
index 00a1abc7e839..3f8f459edcf3 100644
--- a/drivers/hid/hid-roccat-kone.c
+++ b/drivers/hid/hid-roccat-kone.c
@@ -400,7 +400,7 @@ static ssize_t kone_sysfs_show_actual_profile(struct device *dev,
{
struct kone_device *kone =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kone->actual_profile);
+ return sysfs_emit(buf, "%d\n", kone->actual_profile);
}
static DEVICE_ATTR(actual_profile, 0440, kone_sysfs_show_actual_profile, NULL);
@@ -409,7 +409,7 @@ static ssize_t kone_sysfs_show_actual_dpi(struct device *dev,
{
struct kone_device *kone =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kone->actual_dpi);
+ return sysfs_emit(buf, "%d\n", kone->actual_dpi);
}
static DEVICE_ATTR(actual_dpi, 0440, kone_sysfs_show_actual_dpi, NULL);
@@ -432,7 +432,7 @@ static ssize_t kone_sysfs_show_weight(struct device *dev,
if (retval)
return retval;
- return snprintf(buf, PAGE_SIZE, "%d\n", weight);
+ return sysfs_emit(buf, "%d\n", weight);
}
static DEVICE_ATTR(weight, 0440, kone_sysfs_show_weight, NULL);
@@ -441,7 +441,7 @@ static ssize_t kone_sysfs_show_firmware_version(struct device *dev,
{
struct kone_device *kone =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kone->firmware_version);
+ return sysfs_emit(buf, "%d\n", kone->firmware_version);
}
static DEVICE_ATTR(firmware_version, 0440, kone_sysfs_show_firmware_version,
NULL);
@@ -451,7 +451,7 @@ static ssize_t kone_sysfs_show_tcu(struct device *dev,
{
struct kone_device *kone =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kone->settings.tcu);
+ return sysfs_emit(buf, "%d\n", kone->settings.tcu);
}
static int kone_tcu_command(struct usb_device *usb_dev, int number)
@@ -553,7 +553,7 @@ static ssize_t kone_sysfs_show_startup_profile(struct device *dev,
{
struct kone_device *kone =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kone->settings.startup_profile);
+ return sysfs_emit(buf, "%d\n", kone->settings.startup_profile);
}
static ssize_t kone_sysfs_set_startup_profile(struct device *dev,
diff --git a/drivers/hid/hid-roccat-koneplus.c b/drivers/hid/hid-roccat-koneplus.c
index 22b895436a7c..8ccb3b14a1a9 100644
--- a/drivers/hid/hid-roccat-koneplus.c
+++ b/drivers/hid/hid-roccat-koneplus.c
@@ -242,7 +242,7 @@ static ssize_t koneplus_sysfs_show_actual_profile(struct device *dev,
{
struct koneplus_device *koneplus =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", koneplus->actual_profile);
+ return sysfs_emit(buf, "%d\n", koneplus->actual_profile);
}
static ssize_t koneplus_sysfs_set_actual_profile(struct device *dev,
@@ -309,7 +309,7 @@ static ssize_t koneplus_sysfs_show_firmware_version(struct device *dev,
&info, KONEPLUS_SIZE_INFO);
mutex_unlock(&koneplus->koneplus_lock);
- return snprintf(buf, PAGE_SIZE, "%d\n", info.firmware_version);
+ return sysfs_emit(buf, "%d\n", info.firmware_version);
}
static DEVICE_ATTR(firmware_version, 0440,
koneplus_sysfs_show_firmware_version, NULL);
diff --git a/drivers/hid/hid-roccat-kovaplus.c b/drivers/hid/hid-roccat-kovaplus.c
index 86af538c10d6..748d4d7cb2fc 100644
--- a/drivers/hid/hid-roccat-kovaplus.c
+++ b/drivers/hid/hid-roccat-kovaplus.c
@@ -272,7 +272,7 @@ static ssize_t kovaplus_sysfs_show_actual_profile(struct device *dev,
{
struct kovaplus_device *kovaplus =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kovaplus->actual_profile);
+ return sysfs_emit(buf, "%d\n", kovaplus->actual_profile);
}
static ssize_t kovaplus_sysfs_set_actual_profile(struct device *dev,
@@ -325,7 +325,7 @@ static ssize_t kovaplus_sysfs_show_actual_cpi(struct device *dev,
{
struct kovaplus_device *kovaplus =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kovaplus->actual_cpi);
+ return sysfs_emit(buf, "%d\n", kovaplus->actual_cpi);
}
static DEVICE_ATTR(actual_cpi, 0440, kovaplus_sysfs_show_actual_cpi, NULL);
@@ -334,7 +334,7 @@ static ssize_t kovaplus_sysfs_show_actual_sensitivity_x(struct device *dev,
{
struct kovaplus_device *kovaplus =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kovaplus->actual_x_sensitivity);
+ return sysfs_emit(buf, "%d\n", kovaplus->actual_x_sensitivity);
}
static DEVICE_ATTR(actual_sensitivity_x, 0440,
kovaplus_sysfs_show_actual_sensitivity_x, NULL);
@@ -344,7 +344,7 @@ static ssize_t kovaplus_sysfs_show_actual_sensitivity_y(struct device *dev,
{
struct kovaplus_device *kovaplus =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", kovaplus->actual_y_sensitivity);
+ return sysfs_emit(buf, "%d\n", kovaplus->actual_y_sensitivity);
}
static DEVICE_ATTR(actual_sensitivity_y, 0440,
kovaplus_sysfs_show_actual_sensitivity_y, NULL);
@@ -365,7 +365,7 @@ static ssize_t kovaplus_sysfs_show_firmware_version(struct device *dev,
&info, KOVAPLUS_SIZE_INFO);
mutex_unlock(&kovaplus->kovaplus_lock);
- return snprintf(buf, PAGE_SIZE, "%d\n", info.firmware_version);
+ return sysfs_emit(buf, "%d\n", info.firmware_version);
}
static DEVICE_ATTR(firmware_version, 0440,
kovaplus_sysfs_show_firmware_version, NULL);
diff --git a/drivers/hid/hid-roccat-pyra.c b/drivers/hid/hid-roccat-pyra.c
index 5663b9cd9c69..eeb3d38cd805 100644
--- a/drivers/hid/hid-roccat-pyra.c
+++ b/drivers/hid/hid-roccat-pyra.c
@@ -283,7 +283,7 @@ static ssize_t pyra_sysfs_show_actual_cpi(struct device *dev,
{
struct pyra_device *pyra =
hid_get_drvdata(dev_get_drvdata(dev->parent->parent));
- return snprintf(buf, PAGE_SIZE, "%d\n", pyra->actual_cpi);
+ return sysfs_emit(buf, "%d\n", pyra->actual_cpi);
}
static DEVICE_ATTR(actual_cpi, 0440, pyra_sysfs_show_actual_cpi, NULL);
@@ -300,7 +300,7 @@ static ssize_t pyra_sysfs_show_actual_profile(struct device *dev,
&settings, PYRA_SIZE_SETTINGS);
mutex_unlock(&pyra->pyra_lock);
- return snprintf(buf, PAGE_SIZE, "%d\n", settings.startup_profile);
+ return sysfs_emit(buf, "%d\n", settings.startup_profile);
}
static DEVICE_ATTR(actual_profile, 0440, pyra_sysfs_show_actual_profile, NULL);
static DEVICE_ATTR(startup_profile, 0440, pyra_sysfs_show_actual_profile, NULL);
@@ -321,7 +321,7 @@ static ssize_t pyra_sysfs_show_firmware_version(struct device *dev,
&info, PYRA_SIZE_INFO);
mutex_unlock(&pyra->pyra_lock);
- return snprintf(buf, PAGE_SIZE, "%d\n", info.firmware_version);
+ return sysfs_emit(buf, "%d\n", info.firmware_version);
}
static DEVICE_ATTR(firmware_version, 0440, pyra_sysfs_show_firmware_version,
NULL);
--
2.29.2
^ permalink raw reply related
* Re: [PATCH v7 1/4] dt-bindings: touchscreen: add touch-overlay property
From: Javier Carrasco @ 2024-03-19 11:13 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch, Jeff LaBundy
Cc: linux-kernel, linux-input, devicetree, Rob Herring
In-Reply-To: <20240119-feature-ts_virtobj_patch-v7-1-eda70985808f@wolfvision.net>
On 1/19/24 08:43, Javier Carrasco wrote:
> The touch-overlay encompasses a number of touch areas that define a
> clipped touchscreen area and/or buttons with a specific functionality.
>
> A clipped touchscreen area avoids getting events from regions that are
> physically hidden by overlay frames.
>
> For touchscreens with printed overlay buttons, sub-nodes with a suitable
> key code can be defined to report key events instead of the original
> touch events.
>
> Reviewed-by: Jeff LaBundy <jeff@labundy.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
> ---
> .../bindings/input/touchscreen/touchscreen.yaml | 119 +++++++++++++++++++++
> 1 file changed, 119 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> index 431c13335c40..eb1e86fa86c6 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> @@ -87,6 +87,125 @@ properties:
> touchscreen-y-plate-ohms:
> description: Resistance of the Y-plate in Ohms
>
> + touch-overlay:
Even though it has already been reviewed, just in case before it gets
applied. Should it not be:
description: |
List of nodes...
instead, to keep formatting?
> + description: list of nodes defining segments (touch areas) on the
> + touchscreen.
> +
> + This object can be used to describe a series of segments to
> + restrict the region within touch events are reported or buttons
> + with a specific functionality.
> +
> + This is of special interest if the touchscreen is shipped with a physical
> + overlay on top of it with a frame that hides some part of the original
> + touchscreen area. Printed buttons on that overlay are also a typical
> + use case.
> +
> + A new touchscreen area is defined as a sub-node without a key code. If a
> + key code is defined in the sub-node, it will be interpreted as a button.
> +
> + The x-origin and y-origin properties of a touchscreen area define the
> + offset of a new origin from where the touchscreen events are referenced.
> + This offset is applied to the events accordingly. The x-size and y-size
> + properties define the size of the touchscreen effective area.
> +
> + The following example shows a new touchscreen area with the new origin
> + (0',0') for the touch events generated by the device.
> +
> + Touchscreen (full area)
> + ┌────────────────────────────────────────┐
> + │ ┌───────────────────────────────┐ │
> + │ │ │ │
> + │ ├ y-size │ │
> + │ │ │ │
> + │ │ touchscreen area │ │
> + │ │ (no key code) │ │
> + │ │ │ │
> + │ │ x-size │ │
> + │ ┌└──────────────┴────────────────┘ │
> + │(0',0') │
> + ┌└────────────────────────────────────────┘
> + (0,0)
> +
When at it, the following line could be aligned to match the rest of the
description.
> + where (0',0') = (0+x-origin,0+y-origin)
> +
> + Sub-nodes with key codes report the touch events on their surface as key
> + events instead.
> +
> + The following example shows a touchscreen with a single button on it.
> +
> + Touchscreen (full area)
> + ┌───────────────────────────────────┐
> + │ │
> + │ │
> + │ ┌─────────┐ │
> + │ │button 0 │ │
> + │ │KEY_POWER│ │
> + │ └─────────┘ │
> + │ │
> + │ │
> + ┌└───────────────────────────────────┘
> + (0,0)
> +
And the origin above too.
> + Segments defining buttons and clipped toushcreen areas can be combined
> + as shown in the following example.
> + In that case only the events within the touchscreen area are reported
> + as touch events. Events within the button areas report their associated
> + key code. Any events outside the defined areas are ignored.
> +
> + Touchscreen (full area)
> + ┌─────────┬──────────────────────────────┐
> + │ │ │
> + │ │ ┌───────────────────────┐ │
> + │ button 0│ │ │ │
> + │KEY_POWER│ │ │ │
> + │ │ │ │ │
> + ├─────────┤ │ touchscreen area │ │
> + │ │ │ (no key code) │ │
> + │ │ │ │ │
> + │ button 1│ │ │ │
> + │ KEY_INFO│ ┌└───────────────────────┘ │
> + │ │(0',0') │
> + ┌└─────────┴──────────────────────────────┘
> + (0,0)
> +
Same with this one.
> + type: object
> +
Best regards,
Javier Carrasco
^ permalink raw reply
* [syzbot] Monthly input report (Mar 2024)
From: syzbot @ 2024-03-19 12:48 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 2 new issues were detected and 0 were fixed.
In total, 16 issues are still open and 52 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 4654 Yes WARNING in input_mt_init_slots
https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
<2> 454 No possible deadlock in evdev_pass_values (2)
https://syzkaller.appspot.com/bug?extid=13d3cb2a3dc61e6092f5
<3> 312 Yes INFO: task hung in uhid_char_release
https://syzkaller.appspot.com/bug?extid=8fe2d362af0e1cba8735
<4> 163 Yes WARNING in cm109_urb_irq_callback/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
<5> 156 Yes KASAN: stack-out-of-bounds Read in sched_show_task
https://syzkaller.appspot.com/bug?extid=8d2757d62d403b2d9275
<6> 4 Yes WARNING in __input_unregister_device
https://syzkaller.appspot.com/bug?extid=b03b0fc32e288051502d
<7> 4 Yes WARNING in input_unregister_device (2)
https://syzkaller.appspot.com/bug?extid=617f4ccb03b9869f6494
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: Future handling of complex RGB devices on Linux v3
From: Werner Sembach @ 2024-03-19 15:18 UTC (permalink / raw)
To: Hans de Goede
Cc: Lee Jones, jikos, linux-kernel, Jelle van der Waa, Miguel Ojeda,
dri-devel@lists.freedesktop.org, linux-input, ojeda, linux-leds,
Pavel Machek, Gregor Riepl
In-Reply-To: <281f9b71-a565-4ff3-8343-ca36d604584d@redhat.com>
Hi Hans,
Am 18.03.24 um 12:11 schrieb Hans de Goede:
> Hi Werner,
>
> Sorry for the late reply.
np
>
> On 2/22/24 2:14 PM, Werner Sembach wrote:
>> Hi,
>>
>> Thanks everyone for the exhaustive feedback. And at least this thread is a good comprehesive reference for the future ^^.
>>
>> To recap the hopefully final UAPI for complex RGB lighting devices:
>>
>> - By default there is a singular /sys/class/leds/* entry that treats the device as if it was a single zone RGB keyboard backlight with no special effects.
> Ack this sounds good.
>
>> - There is an accompanying misc device with the sysfs attributes "name", "device_type", "firmware_version_string", "serial_number" for device identification and "use_leds_uapi" that defaults to 1.
> You don't need a char misc device here, you can just make this sysfs attributes on the LED class device's parent device by using device_driver.dev_groups. Please don't use a char misc device just to attach sysfs attributes to it.
>
> Also I'm a bit unsure about most of these attributes, "use_leds_uapi" was discussed before
> and makes sense. But at least for HID devices the rest of this info is already available
> in sysfs attributes on the HID devices (things like vendor and product id) and since the
> userspace code needs per device code to drive the kbd anyways it can also have device
> specific code to retrieve all this info, so the other sysfs attributes just feel like
> duplicating information. Also there already are a ton of existing hidraw userspace rgbkbd
> drivers which already get this info from other places.
The parent device can be a hid device, a wmi device, a platform device etc. so I
thought it would be nice to have some unified way for identification.
>
>> - If set to 0 the /sys/class/leds/* entry disappears. The driver should keep the last state the backlight was in active if possible.
>>
>> - If set 1 it appears again. The driver should bring it back to a static 1 zone setting while avoiding flicker if possible.
> Ack, if this finds it way into some documentation (which it should) please make it
> clear that this is about the "use_leds_uapi" sysfs attribute.
Ack
>
>> - If the device is not controllable by for example hidraw, the misc device might also implement additional ioctls or sysfs attributes to allow a more complex low level control for the keyboard backlight. This is will be a highly vendor specific UAPI.
> IMHO this is the only case where actually using a misc device makes sense, so that
> you have a chardev to do the ioctls on. misc-device-s should really only be used
> when you need a chardev under /dev . Since you don't need the chardev for the e.g.
> hidraw case you should not use a miscdev there IMHO.
My train of thought was that it would be nice to have the use_leds_uapi at a
somewhat unified location in sysfs. The parent device can be of any kind, like I
mentioned above, and while for deactivating it can easily be found via
/sys/class/leds/*/device/. For reactivating, the leds entry doesn't exist.
>
>> - The actual logic interacting with this low level UAPI is implemented by a userspace driver
>>
>> Implementation wise: For the creation of the misc device with the use_leds_uapi switch a helper function/macro might be useful? Wonder if it should go into leds.h, led-class-multicolor.h, or a new header file?
> See above, I don't think we want the misc device for the hidraw case, at which
> point I think the helper becomes unnecessary since just a single sysfs write
> callback is necessary.
>
> Also for adding new sysfs attributes it is strongly encouraged to use
> device_driver.dev_groups so that the device core handled registering /
> unregistering the sysfs attributes which fixes a bunch of races; and
> using device_driver.dev_groups does not mix well with a helper as you've
> suggested.
Ok, I will see when I start implementing.
>
>> - Out of my head it would look something like this:
>>
>> led_classdev_add_optional_misc_control(
>> struct led_classdev *led_cdev,
>> char* name,
>> char* device_type,
>> char* firmware_version_string,
>> char* serial_number,
>> void (*deregister_led)(struct led_classdev *led_cdev),
>> void (*reregister_led)(struct led_classdev *led_cdev))
>>
>> Let me know your thoughts and hopefully I can start implementing it soon for one of our devices.
> I think overall the plan sounds good, with my main suggested change
> being to not use an unnecessary misc device for the hid-raw case.
>
> Regards,
>
> Hans
>
>
Thanks for the feedback,
Werner
^ permalink raw reply
* Re: [PATCH v7 1/4] dt-bindings: touchscreen: add touch-overlay property
From: Conor Dooley @ 2024-03-19 17:06 UTC (permalink / raw)
To: Javier Carrasco
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch, Jeff LaBundy,
linux-kernel, linux-input, devicetree, Rob Herring
In-Reply-To: <e373c2c7-0cd9-40d6-a19b-3b9a1a81feb2@wolfvision.net>
[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]
On Tue, Mar 19, 2024 at 12:13:08PM +0100, Javier Carrasco wrote:
> On 1/19/24 08:43, Javier Carrasco wrote:
> > The touch-overlay encompasses a number of touch areas that define a
> > clipped touchscreen area and/or buttons with a specific functionality.
> >
> > A clipped touchscreen area avoids getting events from regions that are
> > physically hidden by overlay frames.
> >
> > For touchscreens with printed overlay buttons, sub-nodes with a suitable
> > key code can be defined to report key events instead of the original
> > touch events.
> >
> > Reviewed-by: Jeff LaBundy <jeff@labundy.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
> > ---
> > .../bindings/input/touchscreen/touchscreen.yaml | 119 +++++++++++++++++++++
> > 1 file changed, 119 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > index 431c13335c40..eb1e86fa86c6 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > @@ -87,6 +87,125 @@ properties:
> > touchscreen-y-plate-ohms:
> > description: Resistance of the Y-plate in Ohms
> >
> > + touch-overlay:
>
> Even though it has already been reviewed, just in case before it gets
> applied. Should it not be:
>
> description: |
> List of nodes...
>
> instead, to keep formatting?
Yes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] HID: hid-pidff: stop all effects before enabling actuators
From: Jules Noirant @ 2024-03-19 18:24 UTC (permalink / raw)
To: jkosina
Cc: bentiss, jkosina, Jules Noirant, Jiri Kosina, Benjamin Tissoires,
linux-usb, linux-input, linux-kernel
Some PID compliant devices automatically play effects after boot (i.e.
autocenter spring) that prevent the rendering of other effects since
it is done outside of the kernel driver.
This makes sure all the effects currently played are stopped after
resetting the device.
It brings compatibility to the Brunner CLS-P joystick.
Signed-off-by: Jules Noirant <jules.noirant@orange.fr>
---
drivers/hid/usbhid/hid-pidff.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index 3b4ee21cd..aade18f9e 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -109,8 +109,9 @@ static const u8 pidff_pool[] = { 0x80, 0x83, 0xa9 };
/* Special field key tables used to put special field keys into arrays */
#define PID_ENABLE_ACTUATORS 0
-#define PID_RESET 1
-static const u8 pidff_device_control[] = { 0x97, 0x9a };
+#define PID_STOP_ALL_EFFECTS 1
+#define PID_RESET 2
+static const u8 pidff_device_control[] = { 0x97, 0x99, 0x9a };
#define PID_CONSTANT 0
#define PID_RAMP 1
@@ -1157,6 +1158,10 @@ static void pidff_reset(struct pidff_device *pidff)
hid_hw_request(hid, pidff->reports[PID_DEVICE_CONTROL], HID_REQ_SET_REPORT);
hid_hw_wait(hid);
+ pidff->device_control->value[0] = pidff->control_id[PID_STOP_ALL_EFFECTS];
+ hid_hw_request(hid, pidff->reports[PID_DEVICE_CONTROL], HID_REQ_SET_REPORT);
+ hid_hw_wait(hid);
+
pidff->device_control->value[0] =
pidff->control_id[PID_ENABLE_ACTUATORS];
hid_hw_request(hid, pidff->reports[PID_DEVICE_CONTROL], HID_REQ_SET_REPORT);
--
2.40.1
^ permalink raw reply related
* [PATCH] HID: hid-debug: add missing evdev and usage codes
From: Thomas Kuehne @ 2024-03-19 22:23 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel
Hid-debug's rdesc output for a game controller contained a few question
marks and numeric IDs instead of the expected descriptive names.
This happens because hid-debug's mapping data is missing a few HID
usages supported by hid-input.
Add missing codes for LEDs, simulator axis and gamepad buttons.
Signed-off-by: Thomas Kuehne <thomas.kuehne@gmx.li>
---
drivers/hid/hid-debug.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 7dd83ec74f8..67216a52fd2 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -103,6 +103,9 @@ static const struct hid_usage_entry hid_usage_table[] = {
{0, 0xbd, "FlareRelease"},
{0, 0xbe, "LandingGear"},
{0, 0xbf, "ToeBrake"},
+ {0, 0xc4, "Accelerator"},
+ {0, 0xc5, "Brake"},
+ {0, 0xc8, "Steering"},
{ 6, 0, "GenericDeviceControls" },
{0, 0x20, "BatteryStrength" },
{0, 0x21, "WirelessChannel" },
@@ -118,7 +121,12 @@ static const struct hid_usage_entry hid_usage_table[] = {
{0, 0x03, "ScrollLock"},
{0, 0x04, "Compose"},
{0, 0x05, "Kana"},
+ {0, 0x09, "Mute"},
+ {0, 0x19, "MessageWaiting"},
+ {0, 0x27, "StandBy"},
{0, 0x4b, "GenericIndicator"},
+ {0, 0x4c, "SystemSuspend"},
+ {0, 0x4d, "ExternalPowerConnected"},
{ 9, 0, "Button" },
{ 10, 0, "Ordinal" },
{ 12, 0, "Consumer" },
@@ -995,6 +1003,26 @@ static const char *keys[KEY_MAX + 1] = {
[KEY_MACRO22] = "Macro22", [KEY_MACRO23] = "Macro23", [KEY_MACRO24] = "Macro24",
[KEY_MACRO25] = "Macro25", [KEY_MACRO26] = "Macro26", [KEY_MACRO27] = "Macro27",
[KEY_MACRO28] = "Macro28", [KEY_MACRO29] = "Macro29", [KEY_MACRO30] = "Macro30",
+ [BTN_TRIGGER_HAPPY1] = "TriggerHappy1", [BTN_TRIGGER_HAPPY2] = "TriggerHappy2",
+ [BTN_TRIGGER_HAPPY3] = "TriggerHappy3", [BTN_TRIGGER_HAPPY4] = "TriggerHappy4",
+ [BTN_TRIGGER_HAPPY5] = "TriggerHappy5", [BTN_TRIGGER_HAPPY6] = "TriggerHappy6",
+ [BTN_TRIGGER_HAPPY7] = "TriggerHappy7", [BTN_TRIGGER_HAPPY8] = "TriggerHappy8",
+ [BTN_TRIGGER_HAPPY9] = "TriggerHappy9", [BTN_TRIGGER_HAPPY10] = "TriggerHappy10",
+ [BTN_TRIGGER_HAPPY11] = "TriggerHappy11", [BTN_TRIGGER_HAPPY12] = "TriggerHappy12",
+ [BTN_TRIGGER_HAPPY13] = "TriggerHappy13", [BTN_TRIGGER_HAPPY14] = "TriggerHappy14",
+ [BTN_TRIGGER_HAPPY15] = "TriggerHappy15", [BTN_TRIGGER_HAPPY16] = "TriggerHappy16",
+ [BTN_TRIGGER_HAPPY17] = "TriggerHappy17", [BTN_TRIGGER_HAPPY18] = "TriggerHappy18",
+ [BTN_TRIGGER_HAPPY19] = "TriggerHappy19", [BTN_TRIGGER_HAPPY20] = "TriggerHappy20",
+ [BTN_TRIGGER_HAPPY21] = "TriggerHappy21", [BTN_TRIGGER_HAPPY22] = "TriggerHappy22",
+ [BTN_TRIGGER_HAPPY23] = "TriggerHappy23", [BTN_TRIGGER_HAPPY24] = "TriggerHappy24",
+ [BTN_TRIGGER_HAPPY25] = "TriggerHappy25", [BTN_TRIGGER_HAPPY26] = "TriggerHappy26",
+ [BTN_TRIGGER_HAPPY27] = "TriggerHappy27", [BTN_TRIGGER_HAPPY28] = "TriggerHappy28",
+ [BTN_TRIGGER_HAPPY29] = "TriggerHappy29", [BTN_TRIGGER_HAPPY30] = "TriggerHappy30",
+ [BTN_TRIGGER_HAPPY31] = "TriggerHappy31", [BTN_TRIGGER_HAPPY32] = "TriggerHappy32",
+ [BTN_TRIGGER_HAPPY33] = "TriggerHappy33", [BTN_TRIGGER_HAPPY34] = "TriggerHappy34",
+ [BTN_TRIGGER_HAPPY35] = "TriggerHappy35", [BTN_TRIGGER_HAPPY36] = "TriggerHappy36",
+ [BTN_TRIGGER_HAPPY37] = "TriggerHappy37", [BTN_TRIGGER_HAPPY38] = "TriggerHappy38",
+ [BTN_TRIGGER_HAPPY39] = "TriggerHappy39", [BTN_TRIGGER_HAPPY40] = "TriggerHappy40",
};
static const char *relatives[REL_MAX + 1] = {
@@ -1041,7 +1069,8 @@ static const char *leds[LED_MAX + 1] = {
[LED_SCROLLL] = "ScrollLock", [LED_COMPOSE] = "Compose",
[LED_KANA] = "Kana", [LED_SLEEP] = "Sleep",
[LED_SUSPEND] = "Suspend", [LED_MUTE] = "Mute",
- [LED_MISC] = "Misc",
+ [LED_MISC] = "Misc", [LED_MAIL] = "Mail",
+ [LED_CHARGING] = "Charging",
};
static const char *repeats[REP_MAX + 1] = {
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v9 5/5] ASoC: cs40l50: Support I2S streaming to CS40L50
From: James Ogletree @ 2024-03-20 0:41 UTC (permalink / raw)
To: Jeff LaBundy
Cc: James Ogletree, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, lee@kernel.org, broonie@kernel.org,
patches@opensource.cirrus.com, linux-sound@vger.kernel.org,
linux-input@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <ZfMgLc16lOTK62wa@nixie71>
> On Mar 14, 2024, at 11:05 AM, Jeff LaBundy <jeff@labundy.com> wrote:
>
> On Fri, Mar 08, 2024 at 10:24:21PM +0000, James Ogletree wrote:
>>
>> +static int cs40l50_clk_en(struct snd_soc_dapm_widget *w,
>> + struct snd_kcontrol *kcontrol,
>> + int event)
>> +{
>> + struct snd_soc_component *comp = snd_soc_dapm_to_component(w->dapm);
>> + struct cs40l50_codec *codec = snd_soc_component_get_drvdata(comp);
>> + int ret;
>> +
>> + switch (event) {
>> + case SND_SOC_DAPM_POST_PMU:
>> + ret = cs40l50_dsp_write(codec->dev, codec->regmap, CS40L50_STOP_PLAYBACK);
>> + if (ret)
>> + return ret;
>> +
>> + ret = cs40l50_dsp_write(codec->dev, codec->regmap, CS40L50_START_I2S);
>> + if (ret)
>> + return ret;
>> +
>> + ret = cs40l50_swap_ext_clk(codec, CS40L50_PLL_REFCLK_BCLK);
>> + if (ret)
>> + return ret;
>> + break;
>> + case SND_SOC_DAPM_PRE_PMD:
>> + ret = cs40l50_swap_ext_clk(codec, CS40L50_PLL_REFCLK_MCLK);
>> + if (ret)
>> + return ret;
>> + break;
>
> Just for my own understanding, does the HALO core need to be told that I2S
> streaming is about to stop? Or does the L50 gracefully park the class D
> outputs when the PLL source is suddenly switched?
The only time we enter this pre-power down DAPM event code path is if the
stream ends on its own, or if a stop has already been sent to the DSP. So the
former, but there is no need to tell the DSP anything here.
Best,
James
^ permalink raw reply
* [PATCH] Input: ads7846 - add dummy command register clearing cycle
From: Marek Vasut @ 2024-03-20 7:23 UTC (permalink / raw)
To: linux-input
Cc: Marek Vasut, Arnd Bergmann, Dmitry Torokhov, Greg Kroah-Hartman,
Linus Walleij, kernel
On STM32MP135F with XPT2046 touch controller attached to SPI bus, it has
been observed that the touch controller locks up after Linux kernel has
finished booting. Adding a dummy cycle on the SPI bus seems to mitigate
the lock up.
The XPTEK XPT2046 controller seems to be an identical clone of TI TSC2046,
the datasheet seems to be a clone of the TI part as well, text seem to be
word to word identical, except all the pictures have been drawn again.
This touch controller is present e.g. on WaveShare 3.2inch RPi LCD (B)
panel, the DTO provided by WaveShare uses 50 kHz SPI clock for this
touch controller, which is unusually low and possibly might have been
used as some sort of workaround for an issue. The SPI LCD on the same
bus uses 16 MHz clock.
SPI bus DT properties spi-cs-setup-delay-ns, spi-cs-hold-delay-ns,
spi-cs-inactive-delay-ns, spi-rx-delay-us, spi-tx-delay-us set to
range of 500ns..5us seem to have no impact on the behavior of the
touch controller, the lock up always occurs. The STM32MP13xx SPI
controller users GPIO control for the nCS pins.
Since the dummy cycle happens after the controller has been put into
power down mode and both ADC and REF regulators have been disabled,
the cycle should have no impact on the configuration of the controller,
i.e. it should be a NOP.
It is unclear whether this problem is specific to this cloned XPT2046
controller, or whether this is also present on TSC2046. A test on
either TSC2046 or ADS7846 would be very welcome.
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: kernel@dh-electronics.com
Cc: linux-input@vger.kernel.org
---
drivers/input/touchscreen/ads7846.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index d2bbb436a77df..90b5251797963 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -404,9 +404,19 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
req->xfer[5].rx_buf = &req->scratch;
req->xfer[5].len = 2;
- CS_CHANGE(req->xfer[5]);
spi_message_add_tail(&req->xfer[5], &req->msg);
+ /* clear the command register */
+ req->scratch = 0;
+ req->xfer[6].tx_buf = &req->scratch;
+ req->xfer[6].len = 1;
+ spi_message_add_tail(&req->xfer[6], &req->msg);
+
+ req->xfer[7].rx_buf = &req->scratch;
+ req->xfer[7].len = 2;
+ CS_CHANGE(req->xfer[7]);
+ spi_message_add_tail(&req->xfer[7], &req->msg);
+
mutex_lock(&ts->lock);
ads7846_stop(ts);
status = spi_sync(spi, &req->msg);
--
2.43.0
^ permalink raw reply related
* [PATCH v8 0/4] Input: support overlay objects on touchscreens
From: Javier Carrasco @ 2024-03-20 7:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastian Hecht, Michael Riesch
Cc: linux-input, devicetree, linux-kernel, Javier Carrasco,
Jeff LaBundy
Some touchscreens are shipped with a physical layer on top of them where
a number of buttons and a resized touchscreen surface might be available.
In order to generate proper key events by overlay buttons and adjust the
touch events to a clipped surface, this series offers a documented,
device-tree-based solution by means of helper functions.
An implementation for a specific touchscreen driver is also included.
The functions in touch-overlay provide a simple workflow to acquire
physical objects from the device tree, map them into a list and generate
events according to the object descriptions.
This feature has been tested with a JT240MHQS-E3 display, which consists
of an st1624 as the base touchscreen and an overlay with two buttons and
a frame that clips its effective surface mounted on it.
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Bastian Hecht <hechtb@gmail.com>
To: Michael Riesch <michael.riesch@wolfvision.net>
Cc: linux-input@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Changes in v8:
- touchscreen bindings: fix description formatting.
- Link to v7: https://lore.kernel.org/r/20240119-feature-ts_virtobj_patch-v7-0-eda70985808f@wolfvision.net
Changes in v7:
- General: return to a single input device implementation.
- touchscreen bindings: segment instead of button in the label
description.
- touch-overlay.c: define button-specific data inside segment struct.
- touch-overlay.c: remove fwnode_property_present() and check return
value of fwnode_property_read_u32() in touch_overlay_get_segment().
- touch-overlay.c: simplify return path in touch_overlay_map().
- Link to v6: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v6-0-d8a605975153@wolfvision.net
Changes in v6:
- General: use a single list to manage a single type of object.
- General: swap patches to have bindings preceding the code.
- touch-overlay.c: minor code-sytle fixes.
- Link to v5: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v5-0-ff6b5c4db693@wolfvision.net
Changes in v5:
- touchscreen bindings: move overlay common properties to a $def entry (Rob Herring)
- st1232 bindings: move overlays to the existing example instead of
making a new one (Rob Herring)
- Link to v4: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v4-0-5c6c0fc1eed6@wolfvision.net
Changes in v4:
- General: rename "touchscreen" to "touch" to include other consumers.
- PATCH 1/4: move touch-overlay feature to input core.
- PATCH 1/4, 3/4: set key caps and report key events without consumer's
intervention.
- PATCH 2/4: add missing 'required' field with the required properties.
- Link to v3: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v3-0-b4fb7fc4bab7@wolfvision.net
Changes in v3:
- General: rename "virtobj" and "virtual" to "overlay"
- PATCH 1/4: Make feature bool instead of tristate (selected by
supported touchscreens)
- Link to v2: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v2-0-f68a6bfe7a0f@wolfvision.net
Changes in v2:
- PATCH 1/4: remove preprocessor directives (the module is selected by
the drivers that support the feature). Typo in the commit message.
- PATCH 2/4: more detailed documentation. Images and examples were added.
- PATCH 3/4: select ts-virtobj automatically.
- Link to v1: https://lore.kernel.org/r/20230510-feature-ts_virtobj_patch-v1-0-5ae5e81bc264@wolfvision.net
---
Javier Carrasco (4):
dt-bindings: touchscreen: add touch-overlay property
Input: touch-overlay - Add touchscreen overlay handling
dt-bindings: input: touchscreen: st1232: add touch-overlay example
Input: st1232 - add touch overlays handling
.../input/touchscreen/sitronix,st1232.yaml | 29 +++
.../bindings/input/touchscreen/touchscreen.yaml | 119 ++++++++++
MAINTAINERS | 7 +
drivers/input/Makefile | 2 +-
drivers/input/touch-overlay.c | 250 +++++++++++++++++++++
drivers/input/touchscreen/st1232.c | 48 ++--
include/linux/input/touch-overlay.h | 22 ++
7 files changed, 462 insertions(+), 15 deletions(-)
---
base-commit: b3603fcb79b1036acae10602bffc4855a4b9af80
change-id: 20230510-feature-ts_virtobj_patch-e267540aae74
Best regards,
--
Javier Carrasco <javier.carrasco@wolfvision.net>
^ permalink raw reply
* [PATCH v8 1/4] dt-bindings: touchscreen: add touch-overlay property
From: Javier Carrasco @ 2024-03-20 7:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastian Hecht, Michael Riesch
Cc: linux-input, devicetree, linux-kernel, Javier Carrasco,
Jeff LaBundy
In-Reply-To: <20240320-feature-ts_virtobj_patch-v8-0-cab6e7dcb1f6@wolfvision.net>
The touch-overlay encompasses a number of touch areas that define a
clipped touchscreen area and/or buttons with a specific functionality.
A clipped touchscreen area avoids getting events from regions that are
physically hidden by overlay frames.
For touchscreens with printed overlay buttons, sub-nodes with a suitable
key code can be defined to report key events instead of the original
touch events.
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../bindings/input/touchscreen/touchscreen.yaml | 119 +++++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
index 431c13335c40..3e3572aa483a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
@@ -87,6 +87,125 @@ properties:
touchscreen-y-plate-ohms:
description: Resistance of the Y-plate in Ohms
+ touch-overlay:
+ description: |
+ List of nodes defining segments (touch areas) on the touchscreen.
+
+ This object can be used to describe a series of segments to restrict
+ the region within touch events are reported or buttons with a specific
+ functionality.
+
+ This is of special interest if the touchscreen is shipped with a physical
+ overlay on top of it with a frame that hides some part of the original
+ touchscreen area. Printed buttons on that overlay are also a typical
+ use case.
+
+ A new touchscreen area is defined as a sub-node without a key code. If a
+ key code is defined in the sub-node, it will be interpreted as a button.
+
+ The x-origin and y-origin properties of a touchscreen area define the
+ offset of a new origin from where the touchscreen events are referenced.
+ This offset is applied to the events accordingly. The x-size and y-size
+ properties define the size of the touchscreen effective area.
+
+ The following example shows a new touchscreen area with the new origin
+ (0',0') for the touch events generated by the device.
+
+ Touchscreen (full area)
+ ┌────────────────────────────────────────┐
+ │ ┌───────────────────────────────┐ │
+ │ │ │ │
+ │ ├ y-size │ │
+ │ │ │ │
+ │ │ touchscreen area │ │
+ │ │ (no key code) │ │
+ │ │ │ │
+ │ │ x-size │ │
+ │ ┌└──────────────┴────────────────┘ │
+ │(0',0') │
+ ┌└────────────────────────────────────────┘
+ (0,0)
+
+ where (0',0') = (0+x-origin,0+y-origin)
+
+ Sub-nodes with key codes report the touch events on their surface as key
+ events instead.
+
+ The following example shows a touchscreen with a single button on it.
+
+ Touchscreen (full area)
+ ┌───────────────────────────────────┐
+ │ │
+ │ │
+ │ ┌─────────┐ │
+ │ │button 0 │ │
+ │ │KEY_POWER│ │
+ │ └─────────┘ │
+ │ │
+ │ │
+ ┌└───────────────────────────────────┘
+ (0,0)
+
+ Segments defining buttons and clipped toushcreen areas can be combined
+ as shown in the following example.
+ In that case only the events within the touchscreen area are reported
+ as touch events. Events within the button areas report their associated
+ key code. Any events outside the defined areas are ignored.
+
+ Touchscreen (full area)
+ ┌─────────┬──────────────────────────────┐
+ │ │ │
+ │ │ ┌───────────────────────┐ │
+ │ button 0│ │ │ │
+ │KEY_POWER│ │ │ │
+ │ │ │ │ │
+ ├─────────┤ │ touchscreen area │ │
+ │ │ │ (no key code) │ │
+ │ │ │ │ │
+ │ button 1│ │ │ │
+ │ KEY_INFO│ ┌└───────────────────────┘ │
+ │ │(0',0') │
+ ┌└─────────┴──────────────────────────────┘
+ (0,0)
+
+ type: object
+
+ patternProperties:
+ '^segment-':
+ type: object
+ description:
+ Each segment is represented as a sub-node.
+ properties:
+ x-origin:
+ description: horizontal origin of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-origin:
+ description: vertical origin of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ x-size:
+ description: horizontal resolution of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-size:
+ description: vertical resolution of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ label:
+ description: descriptive name of the segment
+ $ref: /schemas/types.yaml#/definitions/string
+
+ linux,code: true
+
+ required:
+ - x-origin
+ - y-origin
+ - x-size
+ - y-size
+
+ unevaluatedProperties: false
+
dependencies:
touchscreen-size-x: [ touchscreen-size-y ]
touchscreen-size-y: [ touchscreen-size-x ]
--
2.40.1
^ permalink raw reply related
* [PATCH v8 2/4] Input: touch-overlay - Add touchscreen overlay handling
From: Javier Carrasco @ 2024-03-20 7:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastian Hecht, Michael Riesch
Cc: linux-input, devicetree, linux-kernel, Javier Carrasco,
Jeff LaBundy
In-Reply-To: <20240320-feature-ts_virtobj_patch-v8-0-cab6e7dcb1f6@wolfvision.net>
Some touch devices provide mechanical overlays with different objects
like buttons or clipped touchscreen surfaces.
In order to support these objects, add a series of helper functions
to the input subsystem to transform them into overlay objects via
device tree nodes.
These overlay objects consume the raw touch events and report the
expected input events depending on the object properties.
Note that the current implementation allows for multiple definitions
of touchscreen areas (regions that report touch events), but only the
first one will be used for the touchscreen device that the consumers
typically provide.
Should the need for multiple touchscreen areas arise, additional
touchscreen devices would be required at the consumer side.
There is no limitation in the number of touch areas defined as buttons.
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
MAINTAINERS | 7 +
drivers/input/Makefile | 2 +-
drivers/input/touch-overlay.c | 250 ++++++++++++++++++++++++++++++++++++
include/linux/input/touch-overlay.h | 22 ++++
4 files changed, 280 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1339918df52a..94426c470a2d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22338,6 +22338,13 @@ L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/toshiba-wmi.c
+TOUCH OVERLAY
+M: Javier Carrasco <javier.carrasco@wolfvision.net>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/input/touch-overlay.c
+F: include/linux/input/touch-overlay.h
+
TPM DEVICE DRIVER
M: Peter Huewe <peterhuewe@gmx.de>
M: Jarkko Sakkinen <jarkko@kernel.org>
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index c78753274921..393e9f4d00dc 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -7,7 +7,7 @@
obj-$(CONFIG_INPUT) += input-core.o
input-core-y := input.o input-compat.o input-mt.o input-poller.o ff-core.o
-input-core-y += touchscreen.o
+input-core-y += touchscreen.o touch-overlay.o
obj-$(CONFIG_INPUT_FF_MEMLESS) += ff-memless.o
obj-$(CONFIG_INPUT_SPARSEKMAP) += sparse-keymap.o
diff --git a/drivers/input/touch-overlay.c b/drivers/input/touch-overlay.c
new file mode 100644
index 000000000000..42b6ad753a00
--- /dev/null
+++ b/drivers/input/touch-overlay.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Helper functions for overlay objects on touchscreens
+ *
+ * Copyright (c) 2023 Javier Carrasco <javier.carrasco@wolfvision.net>
+ */
+
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touch-overlay.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/property.h>
+
+struct touch_overlay_segment {
+ struct list_head list;
+ u32 x_origin;
+ u32 y_origin;
+ u32 x_size;
+ u32 y_size;
+ u32 key;
+ bool pressed;
+ int slot;
+};
+
+static int touch_overlay_get_segment(struct fwnode_handle *segment_node,
+ struct touch_overlay_segment *segment,
+ struct input_dev *input)
+{
+ int error;
+
+ error = fwnode_property_read_u32(segment_node, "x-origin",
+ &segment->x_origin);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "y-origin",
+ &segment->y_origin);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "x-size",
+ &segment->x_size);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "y-size",
+ &segment->y_size);
+ if (error)
+ return error;
+
+ error = fwnode_property_read_u32(segment_node, "linux,code",
+ &segment->key);
+ if (!error)
+ input_set_capability(input, EV_KEY, segment->key);
+ else if (error != -EINVAL)
+ return error;
+
+ return 0;
+}
+
+/**
+ * touch_overlay_map - map overlay objects from the device tree and set
+ * key capabilities if buttons are defined.
+ * @list: pointer to the list that will hold the segments
+ * @input: pointer to the already allocated input_dev
+ *
+ * Returns 0 on success and error number otherwise.
+ *
+ * If buttons are defined, key capabilities are set accordingly.
+ */
+int touch_overlay_map(struct list_head *list, struct input_dev *input)
+{
+ struct fwnode_handle *overlay, *fw_segment;
+ struct device *dev = input->dev.parent;
+ struct touch_overlay_segment *segment;
+ int error;
+
+ overlay = device_get_named_child_node(dev, "touch-overlay");
+ if (!overlay)
+ return 0;
+
+ fwnode_for_each_child_node(overlay, fw_segment) {
+ segment = devm_kzalloc(dev, sizeof(*segment), GFP_KERNEL);
+ if (!segment) {
+ error = -ENOMEM;
+ fwnode_handle_put(overlay);
+ break;
+ }
+ error = touch_overlay_get_segment(fw_segment, segment, input);
+ if (error) {
+ fwnode_handle_put(overlay);
+ break;
+ }
+ list_add_tail(&segment->list, list);
+ }
+
+ return error;
+}
+EXPORT_SYMBOL(touch_overlay_map);
+
+/**
+ * touch_overlay_get_touchscreen_abs - get abs size from the touchscreen area.
+ * @list: pointer to the list that holds the segments
+ * @x: horizontal abs
+ * @y: vertical abs
+ */
+void touch_overlay_get_touchscreen_abs(struct list_head *list, u16 *x, u16 *y)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (!segment->key) {
+ *x = segment->x_size - 1;
+ *y = segment->y_size - 1;
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(touch_overlay_get_touchscreen_abs);
+
+static bool touch_overlay_segment_event(struct touch_overlay_segment *seg,
+ u32 x, u32 y)
+{
+ if (!seg)
+ return false;
+
+ if (x >= seg->x_origin && x < (seg->x_origin + seg->x_size) &&
+ y >= seg->y_origin && y < (seg->y_origin + seg->y_size))
+ return true;
+
+ return false;
+}
+
+/**
+ * touch_overlay_mapped_touchscreen - check if a touchscreen area is mapped
+ * @list: pointer to the list that holds the segments
+ *
+ * Returns true if a touchscreen area is mapped or false otherwise.
+ */
+bool touch_overlay_mapped_touchscreen(struct list_head *list)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (!segment->key)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(touch_overlay_mapped_touchscreen);
+
+static bool touch_overlay_event_on_ts(struct list_head *list, u32 *x, u32 *y)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+ bool valid_touch = true;
+
+ if (!x || !y)
+ return false;
+
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (segment->key)
+ continue;
+
+ if (touch_overlay_segment_event(segment, *x, *y)) {
+ *x -= segment->x_origin;
+ *y -= segment->y_origin;
+ return true;
+ }
+ /* ignore touch events outside the defined area */
+ valid_touch = false;
+ }
+
+ return valid_touch;
+}
+
+static bool touch_overlay_button_event(struct input_dev *input,
+ struct touch_overlay_segment *segment,
+ const u32 *x, const u32 *y, u32 slot)
+{
+ bool contact = x && y;
+
+ if (!contact && segment->pressed && segment->slot == slot) {
+ segment->pressed = false;
+ input_report_key(input, segment->key, false);
+ input_sync(input);
+ return true;
+ } else if (contact && touch_overlay_segment_event(segment, *x, *y)) {
+ segment->pressed = true;
+ segment->slot = slot;
+ input_report_key(input, segment->key, true);
+ input_sync(input);
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * touch_overlay_process_event - process input events according to the overlay
+ * mapping. This function acts as a filter to release the calling driver from
+ * the events that are either related to overlay buttons or out of the overlay
+ * touchscreen area, if defined.
+ * @list: pointer to the list that holds the segments
+ * @input: pointer to the input device associated to the event
+ * @x: pointer to the x coordinate (NULL if not available - no contact)
+ * @y: pointer to the y coordinate (NULL if not available - no contact)
+ * @slot: slot associated to the event
+ *
+ * Returns true if the event was processed (reported for valid key events
+ * and dropped for events outside the overlay touchscreen area) or false
+ * if the event must be processed by the caller. In that case this function
+ * shifts the (x,y) coordinates to the overlay touchscreen axis if required.
+ */
+bool touch_overlay_process_event(struct list_head *list,
+ struct input_dev *input,
+ u32 *x, u32 *y, u32 slot)
+{
+ struct touch_overlay_segment *segment;
+ struct list_head *ptr;
+
+ /*
+ * buttons must be prioritized over overlay touchscreens to account for
+ * overlappings e.g. a button inside the touchscreen area.
+ */
+ list_for_each(ptr, list) {
+ segment = list_entry(ptr, struct touch_overlay_segment, list);
+ if (segment->key &&
+ touch_overlay_button_event(input, segment, x, y, slot)) {
+ return true;
+ }
+ }
+
+ /*
+ * valid touch events on the overlay touchscreen are left for the client
+ * to be processed/reported according to its (possibly) unique features.
+ */
+ return !touch_overlay_event_on_ts(list, x, y);
+}
+EXPORT_SYMBOL(touch_overlay_process_event);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Helper functions for overlay objects on touch devices");
diff --git a/include/linux/input/touch-overlay.h b/include/linux/input/touch-overlay.h
new file mode 100644
index 000000000000..cef05c46000d
--- /dev/null
+++ b/include/linux/input/touch-overlay.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Javier Carrasco <javier.carrasco@wolfvision.net>
+ */
+
+#ifndef _TOUCH_OVERLAY
+#define _TOUCH_OVERLAY
+
+#include <linux/types.h>
+
+struct input_dev;
+
+int touch_overlay_map(struct list_head *list, struct input_dev *input);
+
+void touch_overlay_get_touchscreen_abs(struct list_head *list, u16 *x, u16 *y);
+
+bool touch_overlay_mapped_touchscreen(struct list_head *list);
+
+bool touch_overlay_process_event(struct list_head *list, struct input_dev *input,
+ u32 *x, u32 *y, u32 slot);
+
+#endif
--
2.40.1
^ permalink raw reply related
* [PATCH v8 3/4] dt-bindings: input: touchscreen: st1232: add touch-overlay example
From: Javier Carrasco @ 2024-03-20 7:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastian Hecht, Michael Riesch
Cc: linux-input, devicetree, linux-kernel, Javier Carrasco
In-Reply-To: <20240320-feature-ts_virtobj_patch-v8-0-cab6e7dcb1f6@wolfvision.net>
The touch-overaly feature adds support for segments (touch areas) on the
touchscreen surface that represent overlays with clipped touchscreen
areas and printed buttons.
Add nodes for a clipped touchscreen and overlay buttons to the existing
example.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../input/touchscreen/sitronix,st1232.yaml | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
index 1d8ca19fd37a..e7ee7a0d74c4 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
@@ -37,6 +37,7 @@ unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/input/linux-event-codes.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -46,5 +47,33 @@ examples:
reg = <0x55>;
interrupts = <2 0>;
gpios = <&gpio1 166 0>;
+
+ touch-overlay {
+ segment-0 {
+ label = "Touchscreen";
+ x-origin = <0>;
+ x-size = <240>;
+ y-origin = <40>;
+ y-size = <280>;
+ };
+
+ segment-1a {
+ label = "Camera light";
+ linux,code = <KEY_LIGHTS_TOGGLE>;
+ x-origin = <40>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+
+ segment-2a {
+ label = "Power";
+ linux,code = <KEY_POWER>;
+ x-origin = <160>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+ };
};
};
--
2.40.1
^ permalink raw reply related
* [PATCH v8 4/4] Input: st1232 - add touch overlays handling
From: Javier Carrasco @ 2024-03-20 7:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bastian Hecht, Michael Riesch
Cc: linux-input, devicetree, linux-kernel, Javier Carrasco,
Jeff LaBundy
In-Reply-To: <20240320-feature-ts_virtobj_patch-v8-0-cab6e7dcb1f6@wolfvision.net>
Use touch-overlay to support overlay objects such as buttons and a resized
frame defined in the device tree.
If buttons are provided, register an additional device to report key
events separately. A key event will be generated if the coordinates
of a touch event are within the area defined by the button properties.
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
drivers/input/touchscreen/st1232.c | 48 +++++++++++++++++++++++++++-----------
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/input/touchscreen/st1232.c b/drivers/input/touchscreen/st1232.c
index 6475084aee1b..4fa31447dbc1 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -22,6 +22,7 @@
#include <linux/pm_qos.h>
#include <linux/slab.h>
#include <linux/types.h>
+#include <linux/input/touch-overlay.h>
#define ST1232_TS_NAME "st1232-ts"
#define ST1633_TS_NAME "st1633-ts"
@@ -57,6 +58,7 @@ struct st1232_ts_data {
struct dev_pm_qos_request low_latency_req;
struct gpio_desc *reset_gpio;
const struct st_chip_info *chip_info;
+ struct list_head touch_overlay_list;
int read_buf_len;
u8 *read_buf;
};
@@ -138,14 +140,20 @@ static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
for (i = 0; i < ts->chip_info->max_fingers; i++) {
u8 *buf = &ts->read_buf[i * 4];
+ bool contact = buf[0] & BIT(7);
+ unsigned int x, y;
- if (buf[0] & BIT(7)) {
- unsigned int x = ((buf[0] & 0x70) << 4) | buf[1];
- unsigned int y = ((buf[0] & 0x07) << 8) | buf[2];
-
- touchscreen_set_mt_pos(&pos[n_contacts],
- &ts->prop, x, y);
+ if (contact) {
+ x = ((buf[0] & 0x70) << 4) | buf[1];
+ y = ((buf[0] & 0x07) << 8) | buf[2];
+ }
+ if (touch_overlay_process_event(&ts->touch_overlay_list, input,
+ contact ? &x : NULL,
+ contact ? &y : NULL, i))
+ continue;
+ if (contact) {
+ touchscreen_set_mt_pos(&pos[n_contacts], &ts->prop, x, y);
/* st1232 includes a z-axis / touch strength */
if (ts->chip_info->have_z)
z[n_contacts] = ts->read_buf[i + 6];
@@ -292,18 +300,30 @@ static int st1232_ts_probe(struct i2c_client *client)
if (error)
return error;
- /* Read resolution from the chip */
- error = st1232_ts_read_resolution(ts, &max_x, &max_y);
- if (error) {
- dev_err(&client->dev,
- "Failed to read resolution: %d\n", error);
- return error;
- }
-
if (ts->chip_info->have_z)
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
ts->chip_info->max_area, 0, 0);
+ /* map overlay objects if defined in the device tree */
+ INIT_LIST_HEAD(&ts->touch_overlay_list);
+ error = touch_overlay_map(&ts->touch_overlay_list, input_dev);
+ if (error)
+ return error;
+
+ if (touch_overlay_mapped_touchscreen(&ts->touch_overlay_list)) {
+ /* Read resolution from the overlay touchscreen if defined */
+ touch_overlay_get_touchscreen_abs(&ts->touch_overlay_list,
+ &max_x, &max_y);
+ } else {
+ /* Read resolution from the chip */
+ error = st1232_ts_read_resolution(ts, &max_x, &max_y);
+ if (error) {
+ dev_err(&client->dev,
+ "Failed to read resolution: %d\n", error);
+ return error;
+ }
+ }
+
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, max_x, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
--
2.40.1
^ permalink raw reply related
* [PATCH V1] Input: synaptics-rmi4 - Supports to query DPM value.
From: Marge Yang @ 2024-03-20 11:10 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel, marge.yang
Cc: david.chiu, derek.cheng, sam.tsai, vincent.huang, Vincent Huang
RMI4 F12 will support to query DPM value on Touchpad.
When TP firmware doesn't support to report logical and
physical value within the Touchpad's HID report,
We can directly query the DPM value through RMI.
Signed-off-by: Marge Yang <marge.yang@tw.synaptics.com>
Signed-off-by: Vincent Huang <Vincent.Huang@tw.synaptics.com>
---
drivers/input/rmi4/rmi_f12.c | 41 +++++++++++++++++++++++++++++++----------
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 7e97944..6a7a17d 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -24,6 +24,7 @@ enum rmi_f12_object_type {
};
#define F12_DATA1_BYTES_PER_OBJ 8
+#define RMI_QUERY_DPM_IN_PRESENSE_BIT 29
struct f12_data {
struct rmi_2d_sensor sensor;
@@ -73,6 +74,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
int pitch_y = 0;
int rx_receivers = 0;
int tx_receivers = 0;
+ u16 query_dpm_addr = 0;
+ int dpm_resolution = 0;
item = rmi_get_register_desc_item(&f12->control_reg_desc, 8);
if (!item) {
@@ -122,18 +125,36 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
offset += 4;
}
- if (rmi_register_desc_has_subpacket(item, 3)) {
- rx_receivers = buf[offset];
- tx_receivers = buf[offset + 1];
- offset += 2;
- }
+ // Only supports to query DPM value on RMI F12.
+ item = rmi_get_register_desc_item(&f12->query_reg_desc, RMI_QUERY_DPM_IN_PRESENSE_BIT);
+ if (item) {
+ offset = rmi_register_desc_calc_reg_offset(&f12->query_reg_desc,
+ RMI_QUERY_DPM_IN_PRESENSE_BIT);
+ query_dpm_addr = fn->fd.query_base_addr + offset;
+ ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf);
+ if (ret < 0) {
+ dev_err(&fn->dev, "Failed to read DPM value: %d\n", ret);
+ return -ENODEV;
+ }
+ dpm_resolution = buf[0];
+
+ sensor->x_mm = sensor->max_x / dpm_resolution;
+ sensor->y_mm = sensor->max_y / dpm_resolution;
+ } else {
+ if (rmi_register_desc_has_subpacket(item, 3)) {
+ rx_receivers = buf[offset];
+ tx_receivers = buf[offset + 1];
+ offset += 2;
+ }
- /* Skip over sensor flags */
- if (rmi_register_desc_has_subpacket(item, 4))
- offset += 1;
+ /* Skip over sensor flags */
+ if (rmi_register_desc_has_subpacket(item, 4))
+ offset += 1;
+
+ sensor->x_mm = (pitch_x * rx_receivers) >> 12;
+ sensor->y_mm = (pitch_y * tx_receivers) >> 12;
+ }
- sensor->x_mm = (pitch_x * rx_receivers) >> 12;
- sensor->y_mm = (pitch_y * tx_receivers) >> 12;
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: x_mm: %d y_mm: %d\n", __func__,
sensor->x_mm, sensor->y_mm);
--
2.7.4
^ permalink raw reply related
* Re: Future handling of complex RGB devices on Linux v3
From: Werner Sembach @ 2024-03-20 11:16 UTC (permalink / raw)
To: Hans de Goede
Cc: Lee Jones, jikos, linux-kernel, Jelle van der Waa, Miguel Ojeda,
dri-devel@lists.freedesktop.org, linux-input, ojeda, linux-leds,
Pavel Machek, Gregor Riepl
In-Reply-To: <adbfdf6c-fb59-4fae-a472-17b04dd8a3f6@tuxedocomputers.com>
Hi Hans and the others,
Am 22.02.24 um 14:14 schrieb Werner Sembach:
> Hi,
>
> Thanks everyone for the exhaustive feedback. And at least this thread is a
> good comprehesive reference for the future ^^.
>
> To recap the hopefully final UAPI for complex RGB lighting devices:
>
> - By default there is a singular /sys/class/leds/* entry that treats the
> device as if it was a single zone RGB keyboard backlight with no special effects.
>
> - There is an accompanying misc device with the sysfs attributes "name",
> "device_type", "firmware_version_string", "serial_number" for device
> identification and "use_leds_uapi" that defaults to 1.
>
> - If set to 0 the /sys/class/leds/* entry disappears. The driver should
> keep the last state the backlight was in active if possible.
>
> - If set 1 it appears again. The driver should bring it back to a static 1
> zone setting while avoiding flicker if possible.
>
> - If the device is not controllable by for example hidraw, the misc device
> might also implement additional ioctls or sysfs attributes to allow a more
> complex low level control for the keyboard backlight. This is will be a highly
> vendor specific UAPI.
So in the OpenRGB issue thread
https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/dynamic-lighting-devices
aka HID LampArray was mentioned. I did dismiss it because I thought that is only
relevant for firmware, but I now stumbled upon the Virtual HID Framework (VHF)
https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-
and now I wonder if an equivalent exists for Linux? A quick search did not yield
any results for me.
If a virtual HID device is possible and the WMI interface can reasonably be
mapped to the LampArray API this might be the best starting point:
- Implement a Virtual HID device with LampArray
- Implement LampArray in OpenRGB
- (Optional) Implement a generic LampArray leds subsystem driver that maps to
the single zone control and ads the use_leds_uapi sysfs switch to the virtual
HID device
- (Optional) Implement vendor specific controls for
AutonomousMode/built-in-firmware-effects via custom HID commands
- (Optional) Implement Virtual HID devices for actual HID devices that don't
support LampArray in firmware (Open question: How to prevent userspace/OpenRGB
from interacting with original HID when the virtual HID device is not in
AutonomousMode? How to associate the original and virtual HID device to each
other that userspace can easily recognize this relation? Or is it possible to
add virtual HID commands on top of a real HID device, making it look exactly
like the pure virtual devices for userspace?)
The LampArray API hereby is made with the intention to be used for multi leds
devices, like per-key-backlight keyboards, unlike the leds UAPI. And it is
coming anyway with new RGB devices soon. So it would not conflict with a "don't
introduce unnecessary UAPI interfaces" principle. Are there any plans already of
Wrapping LampArray in some kind ioctl/sysfs API? Or just have it used via
hidraw? Or was there no discussion about it till now?
Regards,
Werner
>
> - The actual logic interacting with this low level UAPI is implemented by
> a userspace driver
>
> Implementation wise: For the creation of the misc device with the
> use_leds_uapi switch a helper function/macro might be useful? Wonder if it
> should go into leds.h, led-class-multicolor.h, or a new header file?
>
> - Out of my head it would look something like this:
>
> led_classdev_add_optional_misc_control(
> struct led_classdev *led_cdev,
> char* name,
> char* device_type,
> char* firmware_version_string,
> char* serial_number,
> void (*deregister_led)(struct led_classdev *led_cdev),
> void (*reregister_led)(struct led_classdev *led_cdev))
>
> Let me know your thoughts and hopefully I can start implementing it soon for
> one of our devices.
>
> Kind regards,
>
> Werner Sembach
>
^ permalink raw reply
* Re: Future handling of complex RGB devices on Linux v3
From: Werner Sembach @ 2024-03-20 11:33 UTC (permalink / raw)
To: Hans de Goede
Cc: Lee Jones, jikos, linux-kernel, Jelle van der Waa, Miguel Ojeda,
dri-devel@lists.freedesktop.org, linux-input, ojeda, linux-leds,
Pavel Machek, Gregor Riepl
In-Reply-To: <1fb08a74-62c7-4d0c-ba5d-648e23082dcb@tuxedocomputers.com>
Am 20.03.24 um 12:16 schrieb Werner Sembach:
> Hi Hans and the others,
>
> Am 22.02.24 um 14:14 schrieb Werner Sembach:
>> Hi,
>>
>> Thanks everyone for the exhaustive feedback. And at least this thread is a
>> good comprehesive reference for the future ^^.
>>
>> To recap the hopefully final UAPI for complex RGB lighting devices:
>>
>> - By default there is a singular /sys/class/leds/* entry that treats the
>> device as if it was a single zone RGB keyboard backlight with no special
>> effects.
>>
>> - There is an accompanying misc device with the sysfs attributes "name",
>> "device_type", "firmware_version_string", "serial_number" for device
>> identification and "use_leds_uapi" that defaults to 1.
>>
>> - If set to 0 the /sys/class/leds/* entry disappears. The driver should
>> keep the last state the backlight was in active if possible.
>>
>> - If set 1 it appears again. The driver should bring it back to a static
>> 1 zone setting while avoiding flicker if possible.
>>
>> - If the device is not controllable by for example hidraw, the misc device
>> might also implement additional ioctls or sysfs attributes to allow a more
>> complex low level control for the keyboard backlight. This is will be a
>> highly vendor specific UAPI.
> So in the OpenRGB issue thread
> https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/dynamic-lighting-devices
> aka HID LampArray was mentioned. I did dismiss it because I thought that is
> only relevant for firmware, but I now stumbled upon the Virtual HID Framework
> (VHF)
> https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-
> and now I wonder if an equivalent exists for Linux? A quick search did not
> yield any results for me.
Is this what I have been searching for? https://docs.kernel.org/usb/gadget_hid.html
>
> If a virtual HID device is possible and the WMI interface can reasonably be
> mapped to the LampArray API this might be the best starting point:
>
> - Implement a Virtual HID device with LampArray
>
> - Implement LampArray in OpenRGB
>
> - (Optional) Implement a generic LampArray leds subsystem driver that maps to
> the single zone control and ads the use_leds_uapi sysfs switch to the virtual
> HID device
>
> - (Optional) Implement vendor specific controls for
> AutonomousMode/built-in-firmware-effects via custom HID commands
>
> - (Optional) Implement Virtual HID devices for actual HID devices that don't
> support LampArray in firmware (Open question: How to prevent userspace/OpenRGB
> from interacting with original HID when the virtual HID device is not in
> AutonomousMode? How to associate the original and virtual HID device to each
> other that userspace can easily recognize this relation? Or is it possible to
> add virtual HID commands on top of a real HID device, making it look exactly
> like the pure virtual devices for userspace?)
>
> The LampArray API hereby is made with the intention to be used for multi leds
> devices, like per-key-backlight keyboards, unlike the leds UAPI. And it is
> coming anyway with new RGB devices soon. So it would not conflict with a
> "don't introduce unnecessary UAPI interfaces" principle. Are there any plans
> already of Wrapping LampArray in some kind ioctl/sysfs API? Or just have it
> used via hidraw? Or was there no discussion about it till now?
>
> Regards,
>
> Werner
>
>>
>> - The actual logic interacting with this low level UAPI is implemented by
>> a userspace driver
>>
>> Implementation wise: For the creation of the misc device with the
>> use_leds_uapi switch a helper function/macro might be useful? Wonder if it
>> should go into leds.h, led-class-multicolor.h, or a new header file?
>>
>> - Out of my head it would look something like this:
>>
>> led_classdev_add_optional_misc_control(
>> struct led_classdev *led_cdev,
>> char* name,
>> char* device_type,
>> char* firmware_version_string,
>> char* serial_number,
>> void (*deregister_led)(struct led_classdev *led_cdev),
>> void (*reregister_led)(struct led_classdev *led_cdev))
>>
>> Let me know your thoughts and hopefully I can start implementing it soon for
>> one of our devices.
>>
>> Kind regards,
>>
>> Werner Sembach
>>
^ permalink raw reply
* Re: [PATCH v3] Input: xen-kbdfront - drop keys to shrink modalias
From: Jason Andryuk @ 2024-03-20 17:42 UTC (permalink / raw)
To: linux-kernel, Dmitry Torokhov
Cc: Phillip Susi, stable, Mattijs Korpershoek, linux-input, xen-devel,
Juergen Gross
In-Reply-To: <CAKf6xpuJe6Cza6bow3QxDGf1viu0kish7Y8YRN8haXL1oEF3HA@mail.gmail.com>
Hi Dmitry,
Do you have any feedback, or can you pick up this patch? It solves a
real issue affecting udev, which crashes the Debian installer and
breaks the mouse for Gnome.
Or would you be okay if this patch went in via the Xen tree?
Thanks,
Jason
On Wed, Nov 1, 2023 at 10:11 AM Jason Andryuk <jandryuk@gmail.com> wrote:
>
> Hi Dmitry,
>
> Do you have any feedback or can you pick this up?
>
> Thanks,
> Jason
>
> On Wed, Oct 11, 2023 at 3:34 PM Jason Andryuk <jandryuk@gmail.com> wrote:
> >
> > xen kbdfront registers itself as being able to deliver *any* key since
> > it doesn't know what keys the backend may produce.
> >
> > Unfortunately, the generated modalias gets too large and uevent creation
> > fails with -ENOMEM.
> >
> > This can lead to gdm not using the keyboard since there is no seat
> > associated [1] and the debian installer crashing [2].
> >
> > Trim the ranges of key capabilities by removing some BTN_* ranges.
> > While doing this, some neighboring undefined ranges are removed to trim
> > it further.
> >
> > An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper
> > limit of KEY_BRIGHTNESS_MENU.
> >
> > This removes:
> > BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223)
> > Empty space 0x224..0x229
> >
> > Empty space 0x28a..0x28f
> > KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad)
> > KEY_MACRO_RECORD_START 0x2b0
> > KEY_MACRO_RECORD_STOP 0x2b1
> > KEY_MACRO_PRESET_CYCLE 0x2b2
> > KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5)
> > Empty space 0x2b6..0x2b7
> > KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc)
> > Empty space 0x2bd..0x2bf
> > BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7)
> > Empty space 0x2e8..0x2ff
> >
> > The modalias shrinks from 2082 to 1550 bytes.
> >
> > A chunk of keys need to be removed to allow the keyboard to be used.
> > This may break some functionality, but the hope is these macro keys are
> > uncommon and don't affect any users.
> >
> > [1] https://github.com/systemd/systemd/issues/22944
> > [2] https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T/
> >
> > Cc: Phillip Susi <phill@thesusis.net>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> > Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> > ---
> > v3:
> > Add Mattijs R-b
> > Put /* and */ on separate lines
> > ---
> > drivers/input/misc/xen-kbdfront.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> > index 67f1c7364c95..d59ba8f9852e 100644
> > --- a/drivers/input/misc/xen-kbdfront.c
> > +++ b/drivers/input/misc/xen-kbdfront.c
> > @@ -256,7 +256,16 @@ static int xenkbd_probe(struct xenbus_device *dev,
> > __set_bit(EV_KEY, kbd->evbit);
> > for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
> > __set_bit(i, kbd->keybit);
> > - for (i = KEY_OK; i < KEY_MAX; i++)
> > + /*
> > + * In theory we want to go KEY_OK..KEY_MAX, but that grows the
> > + * modalias line too long. There is a gap of buttons from
> > + * BTN_DPAD_UP..BTN_DPAD_RIGHT and KEY_ALS_TOGGLE is the next
> > + * defined. Then continue up to KEY_BRIGHTNESS_MENU as an upper
> > + * limit.
> > + */
> > + for (i = KEY_OK; i < BTN_DPAD_UP; i++)
> > + __set_bit(i, kbd->keybit);
> > + for (i = KEY_ALS_TOGGLE; i <= KEY_BRIGHTNESS_MENU; i++)
> > __set_bit(i, kbd->keybit);
> >
> > ret = input_register_device(kbd);
> > --
> > 2.41.0
> >
^ 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