* Re: [PATCH v11 0/3] Input: Add TouchNetix axiom touchscreen driver
From: Kamel BOUHARA @ 2024-05-21 15:24 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, linux-input, linux-kernel, devicetree,
Marco Felsch, Jeff LaBundy
Cc: catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo
In-Reply-To: <20240419123829.120396-1-kamel.bouhara@bootlin.com>
Le 2024-04-19 14:38, Kamel Bouhara a écrit :
> Add a new driver for the TouchNetix's axiom family of touchscreen
> controller. This driver only support i2c and can be later adapted for
> SPI and USB support.
>
Hello Dmitry,
I just saw you are still applying patch and I wanted to know if this
series could be merged as well ?
Kamel
> --
> Changes in v11:
> - Fix regulators name to match dt-binding
> - Enable regulators before reset is asserted
>
> Changes in v10:
> - Set regulators as required
> - Enable power supply before reset
> - Fix ref count due to regulator requested twice
> - Rebase on v6.9-rc4
>
> Changes in v9:
> - Fix issue reported in
> https://lore.kernel.org/oe-kbuild-all/202402201157.BKo97uWl-lkp@intel.com/
> - Rebase on v6.8-rc2
>
> Changes in v8:
> - Fix missing call to input_report_slot_state()
> - Fix issue reported in
> https://lore.kernel.org/oe-kbuild-all/202402020623.8T1Ah513-lkp@intel.com/
>
> Changes in v7:
> - Remove startup time from dt-binding
> - Fix usage table not correctly populated
>
> Changes in v6:
> - Fix missing unevaluatedProperties.in dt-binding
> - Use __le16 to correctly deal with device endianness
> - Use standart kernel types s/char/u8/
> - Use regmap api as driver might support spi later
> - Use get_unaligned_le16() for the sake of clarity
> - Use devm_regulator_enable_optional()
>
> Changes in v5:
> - Fix wrong message constructed in axiom_i2c_read
> - Delay required between i2c reads is >= 250us
> - Do not split report reading in two phases as we'll
> have to wait 500us
> - Use lower-case in properties names
> - Make regulators properties are required in dt-binding
> - Fix bug report:
> https://lore.kernel.org/lkml/202312051457.y3N1q3sZ-lkp@intel.com/
> - Fix bug report:
> https://lore.kernel.org/lkml/6f8e3b64-5b21-4a50-8680-063ef7a93bdb@suswa.mountain/
>
> Changes in v4:
> - Cleanup unused headers and macros
> - Use standard kernel type
> - Namespace structures and functions
> - Use packed struct when possible to avoid bitfield operators
> - Fix missing break when address is found in
> axiom_populate_target_address()
> - Split reads in two steps for the reports, first length then report
> itself so we only read required bytes
> - Get poll-interval from devicetree
> - Add VDDI/VDDA regulators
> - Add a startup delay of 110 ms required after VDDA/VDDI is applied
> - Remove axiom_i2c_write() as it is no more used
>
> Changes in v3:
> - Remove irq-gpios property in dt-binding
> - Use a generic node name
> - Fix issues reported in
> https://lore.kernel.org/oe-kbuild-all/202310100300.oAC2M62R-lkp@intel.com/
>
> Changes in v2:
> - Add device tree binding documentation
> - Move core functions in axiom_i2c as we only care about i2c support
> now
> - Use static function when required
> - Use syntax dev_err_probe()
> - Add an hardware based reset
>
>
> Kamel Bouhara (3):
> dt-bindings: vendor-prefixes: Add TouchNetix AS
> dt-bindings: input: Add TouchNetix axiom touchscreen
> Input: Add TouchNetix axiom i2c touchscreen driver
>
> .../input/touchscreen/touchnetix,ax54a.yaml | 62 ++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/touchnetix_axiom.c | 657 ++++++++++++++++++
> 6 files changed, 742 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/touchnetix,ax54a.yaml
> create mode 100644 drivers/input/touchscreen/touchnetix_axiom.c
>
> --
> 2.25.1
--
--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 0/2] Input: edt-ft5x06 - add support for FocalTech FT5452 and FT8719
From: Joel Selvaraj via B4 Relay @ 2024-05-21 14:02 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Joel Selvaraj
The driver is compatible with FocalTech FT5452 and FT8719 touchscreens
too. FT5452 supports up to 5 touch points. FT8719 supports up to 10 touch
points. Add compatible data for both of them. Currently in mainline,
FT8719 touchscreen is present in Xiaomi Poco F1 (EBBG variant)[1] and
FT5452 touchscreen is present in Shift6mq[2].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts?h=v6.9
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts?h=v6.9
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
---
Joel Selvaraj (2):
dt-bindings: input: touchscreen: edt-ft5x06: Document FT5452 and FT8719 support
Input: edt-ft5x06 - add support for FocalTech FT5452 and FT8719
.../devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 ++
drivers/input/touchscreen/edt-ft5x06.c | 12 ++++++++++++
2 files changed, 14 insertions(+)
---
base-commit: 6595aff3307919c5866493ea994af4edd24582ab
change-id: 20240521-add-support-ft5452-and-ft8719-touchscreen-f823c74efaf1
Best regards,
--
Joel Selvaraj <joelselvaraj.oss@gmail.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: input: touchscreen: edt-ft5x06: Document FT5452 and FT8719 support
From: Joel Selvaraj via B4 Relay @ 2024-05-21 14:02 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Joel Selvaraj
In-Reply-To: <20240521-add-support-ft5452-and-ft8719-touchscreen-v1-0-2a648ac7176b@gmail.com>
From: Joel Selvaraj <joelselvaraj.oss@gmail.com>
Document FocalTech FT5452 and FT8719 support by adding their compatibles.
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
---
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
index f2808cb4d99df..745e57c05176e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -39,7 +39,9 @@ properties:
- edt,edt-ft5406
- edt,edt-ft5506
- evervision,ev-ft5726
+ - focaltech,ft5452
- focaltech,ft6236
+ - focaltech,ft8719
reg:
maxItems: 1
--
2.45.1
^ permalink raw reply related
* [PATCH 2/2] Input: edt-ft5x06 - add support for FocalTech FT5452 and FT8719
From: Joel Selvaraj via B4 Relay @ 2024-05-21 14:02 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Joel Selvaraj
In-Reply-To: <20240521-add-support-ft5452-and-ft8719-touchscreen-v1-0-2a648ac7176b@gmail.com>
From: Joel Selvaraj <joelselvaraj.oss@gmail.com>
The driver is compatible with FocalTech FT5452 and FT8719 touchscreens
too. FT5452 supports up to 5 touch points. FT8719 supports up to 10 touch
points. Add compatible data for both of them.
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
---
drivers/input/touchscreen/edt-ft5x06.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 2a1db11344766..06ec0f2e18ae3 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1462,6 +1462,10 @@ static const struct edt_i2c_chip_data edt_ft5x06_data = {
.max_support_points = 5,
};
+static const struct edt_i2c_chip_data edt_ft5452_data = {
+ .max_support_points = 5,
+};
+
static const struct edt_i2c_chip_data edt_ft5506_data = {
.max_support_points = 10,
};
@@ -1470,12 +1474,18 @@ static const struct edt_i2c_chip_data edt_ft6236_data = {
.max_support_points = 2,
};
+static const struct edt_i2c_chip_data edt_ft8719_data = {
+ .max_support_points = 10,
+};
+
static const struct i2c_device_id edt_ft5x06_ts_id[] = {
{ .name = "edt-ft5x06", .driver_data = (long)&edt_ft5x06_data },
{ .name = "edt-ft5506", .driver_data = (long)&edt_ft5506_data },
{ .name = "ev-ft5726", .driver_data = (long)&edt_ft5506_data },
+ { .name = "ft5452", .driver_data = (long)&edt_ft5452_data },
/* Note no edt- prefix for compatibility with the ft6236.c driver */
{ .name = "ft6236", .driver_data = (long)&edt_ft6236_data },
+ { .name = "ft8719", .driver_data = (long)&edt_ft8719_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, edt_ft5x06_ts_id);
@@ -1486,8 +1496,10 @@ static const struct of_device_id edt_ft5x06_of_match[] = {
{ .compatible = "edt,edt-ft5406", .data = &edt_ft5x06_data },
{ .compatible = "edt,edt-ft5506", .data = &edt_ft5506_data },
{ .compatible = "evervision,ev-ft5726", .data = &edt_ft5506_data },
+ { .compatible = "focaltech,ft5452", .data = &edt_ft5452_data },
/* Note focaltech vendor prefix for compatibility with ft6236.c */
{ .compatible = "focaltech,ft6236", .data = &edt_ft6236_data },
+ { .compatible = "focaltech,ft8719", .data = &edt_ft8719_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, edt_ft5x06_of_match);
--
2.45.1
^ permalink raw reply related
* Re: BUG: Framework Laptop 16 i2c-hid Based Touchpad Sometimes Fails To Initialize Properly On Early Boot
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-05-21 13:44 UTC (permalink / raw)
To: Arazil Songweaver
Cc: linux-input, Jiri Kosina, Linux regressions mailing list,
Benjamin Tissoires, LKML
In-Reply-To: <0111018f9b597531-d4643a7e-c27a-46f9-9e25-90530d648d65-000000@us-west-1.amazonses.com>
On 21.05.24 15:31, Arazil Songweaver wrote:
> I was able to reproduce bug again with: Linux version
> 6.9.0-1-git-10323-g8f6a15f095a6 (linux-git@archlinux) (gcc (GCC) 14.1.1
> 20240507, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Tue, 21
> May 2024 11:58:24 +0000 (not an official Arch Linux package)
>
> The relevant I2C_HID module needs to be built in to the kernel for the
> bug to trigger on a consistent basis. Arch Linux and mkinitcpio is
> currently getting around this issue by building I2C_HID as a module and
> delaying the load of that module until the part when autoprobe starts
> loading relevant kernel modules. The bug became (more) visible on Arch
> Linux after an update to mkinitcpio moved the I2C_HID module up to the
> beginning of the boot process.
>
> This is not a recent regression. In my testing, I was able to reproduce
> this issue as far back as version 6.8. I did not test 6.7 or earlier
> revisions yet.
Okay, then I won't track this as a regression; might still be worth
trying a few older kernels in a spare minute to see if it was introduced
in the last 12 or 18 months and can be bisected.
CCed Jiri and Benjamin nevertheless in case they missed this report on
the lists.
Ciao, Thorsten
> On 5/21/24 5:57 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 14.05.24 04:57, Arazil Songweaver wrote:
>>> We are experiencing an issue where the touch pad on the Framework Laptop
>>> 16 fails to initialize properly when the "i2c-hid" is loaded early in
>>> the boot process. This issue is especially prominent when "i2c-hid" is
>>> built directly into the kernel. When the "i2c-hid" module is built in,
>>> the issue occurs roughly 50% of the time.
>>> (https://community.frame.work/t/touchpad-not-working-since-update-archlinux/50304) Moving the module load to later in the boot process appears to resolve this issue by making initialization more likely to succeed. (https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39.1)
>>>
>>> Kernel version: Linux artemis 6.9.0-1-git-01560-ga7c840ba5fa7 #1 SMP
>>> PREEMPT_DYNAMIC Tue, 14 May 2024 01:49:25 +0000 x86_64 GNU/Linux
>>>
>>> I'm using the standard Arch Linux AUR "linux-git" package with the
>>> following kernel configuration changes:
>>>
>>> CONFIG_I2C_DEBUG_CORE=y
>>> CONFIG_I2C_DEBUG_ALGO=y
>>> CONFIG_I2C_DEBUG_BUS=y
>>> CONFIG_I2C_HID=y
>>> CONFIG_I2C_HID_ACPI=y
>>> CONFIG_I2C_HID_OF=y
>>> CONFIG_I2C_HID_CORE=y
>>>
>>> We tried reverting the following patches without any behavior impact
>>> (good or bad):
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=fb49deec375aa5beca4a5d71d7a74ec951872f28
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=418c5575d56410c6e186ab727bf32ae32447d497
>>>
>>> Impacted devices seem to include: "PIXA3854:00" and "i2c_designware
>>> AMDI0010:03"
>> Any news on this? If this is still unresolved I'll bring this to the
>> attention of the right developer, if this is a recent regressions (it
>> sounds like it, but it's not exactly clear; and from the first link
>> above it sounds like it's partly due to a change in arch's approach to
>> the initramfs).
>>
>> Ciao, Thorsten
>
>
^ permalink raw reply
* Re: BUG: Framework Laptop 16 i2c-hid Based Touchpad Sometimes Fails To Initialize Properly On Early Boot
From: Arazil Songweaver @ 2024-05-21 13:31 UTC (permalink / raw)
To: Linux regressions mailing list; +Cc: linux-input
In-Reply-To: <f0dd90aa-78b0-4253-96b0-3241e8b2a11b@leemhuis.info>
I was able to reproduce bug again with: Linux version
6.9.0-1-git-10323-g8f6a15f095a6 (linux-git@archlinux) (gcc (GCC) 14.1.1
20240507, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Tue, 21
May 2024 11:58:24 +0000 (not an official Arch Linux package)
The relevant I2C_HID module needs to be built in to the kernel for the
bug to trigger on a consistent basis. Arch Linux and mkinitcpio is
currently getting around this issue by building I2C_HID as a module and
delaying the load of that module until the part when autoprobe starts
loading relevant kernel modules. The bug became (more) visible on Arch
Linux after an update to mkinitcpio moved the I2C_HID module up to the
beginning of the boot process.
This is not a recent regression. In my testing, I was able to reproduce
this issue as far back as version 6.8. I did not test 6.7 or earlier
revisions yet.
Thanks for the follow up.
-Arazil
On 5/21/24 5:57 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 14.05.24 04:57, Arazil Songweaver wrote:
>> We are experiencing an issue where the touch pad on the Framework Laptop
>> 16 fails to initialize properly when the "i2c-hid" is loaded early in
>> the boot process. This issue is especially prominent when "i2c-hid" is
>> built directly into the kernel. When the "i2c-hid" module is built in,
>> the issue occurs roughly 50% of the time.
>> (https://community.frame.work/t/touchpad-not-working-since-update-archlinux/50304) Moving the module load to later in the boot process appears to resolve this issue by making initialization more likely to succeed. (https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39.1)
>>
>> Kernel version: Linux artemis 6.9.0-1-git-01560-ga7c840ba5fa7 #1 SMP
>> PREEMPT_DYNAMIC Tue, 14 May 2024 01:49:25 +0000 x86_64 GNU/Linux
>>
>> I'm using the standard Arch Linux AUR "linux-git" package with the
>> following kernel configuration changes:
>>
>> CONFIG_I2C_DEBUG_CORE=y
>> CONFIG_I2C_DEBUG_ALGO=y
>> CONFIG_I2C_DEBUG_BUS=y
>> CONFIG_I2C_HID=y
>> CONFIG_I2C_HID_ACPI=y
>> CONFIG_I2C_HID_OF=y
>> CONFIG_I2C_HID_CORE=y
>>
>> We tried reverting the following patches without any behavior impact
>> (good or bad):
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=fb49deec375aa5beca4a5d71d7a74ec951872f28
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=418c5575d56410c6e186ab727bf32ae32447d497
>>
>> Impacted devices seem to include: "PIXA3854:00" and "i2c_designware
>> AMDI0010:03"
> Any news on this? If this is still unresolved I'll bring this to the
> attention of the right developer, if this is a recent regressions (it
> sounds like it, but it's not exactly clear; and from the first link
> above it sounds like it's partly due to a change in arch's approach to
> the initramfs).
>
> Ciao, Thorsten
^ permalink raw reply
* [PATCH 1/2] dt-bindings: input: document Novatek NVT touchscreen controller
From: Joel Selvaraj via B4 Relay @ 2024-05-21 12:09 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Joel Selvaraj
In-Reply-To: <20240521-nvt-ts-devicetree-regulator-support-v1-0-8d766c639dca@gmail.com>
From: Joel Selvaraj <joelselvaraj.oss@gmail.com>
Document the Novatek NVT touchscreen driver which is used in devices like
the Xiaomi Poco F1 [1]. Also, include the devictree binding file in the
MAINTAINERS file.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts?h=v6.9
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
---
.../bindings/input/touchscreen/novatek,nvt-ts.yaml | 62 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
new file mode 100644
index 0000000000000..7839c6a028e4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/novatek,nvt-ts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NVT Touchscreen Controller
+
+maintainers:
+ - Hans de Goede <hdegoede@redhat.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - novatek,nvt-ts
+ - novatek,nt36672a-ts
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vcc-supply: true
+ iovcc-supply: true
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@1 {
+ compatible = "novatek,nt36672a-ts";
+ reg = <0x01>;
+ interrupts-extended = <&tlmm 31 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l22a_2p85>;
+ iovcc-supply = <&vreg_l14a_1p8>;
+ pinctrl-0 = <&ts_int_default &ts_reset_default>;
+ pinctrl-1 = <&ts_int_sleep &ts_reset_sleep>;
+ pinctrl-names = "default", "sleep";
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <2246>;
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 90754a451bcfc..e1f744992b15f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15942,6 +15942,7 @@ NOVATEK NVT-TS I2C TOUCHSCREEN DRIVER
M: Hans de Goede <hdegoede@redhat.com>
L: linux-input@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
F: drivers/input/touchscreen/novatek-nvt-ts.c
NSDEPS
--
2.45.1
^ permalink raw reply related
* [PATCH 2/2] Input: novatek-nvt-ts: add support for NT36672A touchscreen
From: Joel Selvaraj via B4 Relay @ 2024-05-21 12:09 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Joel Selvaraj
In-Reply-To: <20240521-nvt-ts-devicetree-regulator-support-v1-0-8d766c639dca@gmail.com>
From: Joel Selvaraj <joelselvaraj.oss@gmail.com>
Extend the novatek touchscreen driver to support NT36672A chip which
is found in phones like Xiaomi Poco F1 [1]. Added devicetree support for
the driver and used i2c chip data to handle the variation in chip id and
wake type. Also added vcc and iovcc regulators which are used to power
the touchscreen hardware.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts?h=v6.9
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
---
drivers/input/touchscreen/novatek-nvt-ts.c | 78 +++++++++++++++++++++++++++---
1 file changed, 72 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/novatek-nvt-ts.c b/drivers/input/touchscreen/novatek-nvt-ts.c
index 1a797e410a3fa..83b881e14a0f3 100644
--- a/drivers/input/touchscreen/novatek-nvt-ts.c
+++ b/drivers/input/touchscreen/novatek-nvt-ts.c
@@ -31,9 +31,6 @@
#define NVT_TS_PARAMS_CHIP_ID 0x0e
#define NVT_TS_PARAMS_SIZE 0x0f
-#define NVT_TS_SUPPORTED_WAKE_TYPE 0x05
-#define NVT_TS_SUPPORTED_CHIP_ID 0x05
-
#define NVT_TS_MAX_TOUCHES 10
#define NVT_TS_MAX_SIZE 4096
@@ -51,11 +48,18 @@ static const int nvt_ts_irq_type[4] = {
IRQF_TRIGGER_HIGH
};
+struct nvt_ts_i2c_chip_data {
+ u8 wake_type;
+ u8 chip_id;
+};
+
struct nvt_ts_data {
struct i2c_client *client;
struct input_dev *input;
struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data regulators[2];
struct touchscreen_properties prop;
+ const struct nvt_ts_i2c_chip_data *chip;
int max_touches;
u8 buf[NVT_TS_TOUCH_SIZE * NVT_TS_MAX_TOUCHES];
};
@@ -139,9 +143,23 @@ static irqreturn_t nvt_ts_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static void nvt_ts_disable_regulators(void *_data)
+{
+ struct nvt_ts_data *data = _data;
+
+ regulator_bulk_disable(ARRAY_SIZE(data->regulators), data->regulators);
+}
+
static int nvt_ts_start(struct input_dev *dev)
{
struct nvt_ts_data *data = input_get_drvdata(dev);
+ int error;
+
+ error = regulator_bulk_enable(ARRAY_SIZE(data->regulators), data->regulators);
+ if (error) {
+ dev_err(&data->client->dev, "failed to enable regulators\n");
+ return error;
+ }
enable_irq(data->client->irq);
gpiod_set_value_cansleep(data->reset_gpio, 0);
@@ -155,6 +173,7 @@ static void nvt_ts_stop(struct input_dev *dev)
disable_irq(data->client->irq);
gpiod_set_value_cansleep(data->reset_gpio, 1);
+ nvt_ts_disable_regulators(data);
}
static int nvt_ts_suspend(struct device *dev)
@@ -199,9 +218,37 @@ static int nvt_ts_probe(struct i2c_client *client)
if (!data)
return -ENOMEM;
+ data->chip = device_get_match_data(&client->dev);
+ if (!data->chip)
+ return -EINVAL;
+
data->client = client;
i2c_set_clientdata(client, data);
+ /*
+ * VCC is the analog voltage supply
+ * IOVCC is the digital voltage supply
+ */
+ data->regulators[0].supply = "vcc";
+ data->regulators[1].supply = "iovcc";
+ error = devm_regulator_bulk_get(dev, ARRAY_SIZE(data->regulators), data->regulators);
+ if (error) {
+ dev_err(dev, "cannot get regulators: %d\n", error);
+ return error;
+ }
+
+ error = regulator_bulk_enable(ARRAY_SIZE(data->regulators), data->regulators);
+ if (error) {
+ dev_err(dev, "failed to enable regulators\n");
+ return error;
+ }
+
+ error = devm_add_action_or_reset(dev, nvt_ts_disable_regulators, data);
+ if (error) {
+ dev_err(dev, "failed to install regulator disable handler\n");
+ return error;
+ }
+
data->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
error = PTR_ERR_OR_ZERO(data->reset_gpio);
if (error) {
@@ -225,8 +272,8 @@ static int nvt_ts_probe(struct i2c_client *client)
if (width > NVT_TS_MAX_SIZE || height >= NVT_TS_MAX_SIZE ||
data->max_touches > NVT_TS_MAX_TOUCHES ||
irq_type >= ARRAY_SIZE(nvt_ts_irq_type) ||
- data->buf[NVT_TS_PARAMS_WAKE_TYPE] != NVT_TS_SUPPORTED_WAKE_TYPE ||
- data->buf[NVT_TS_PARAMS_CHIP_ID] != NVT_TS_SUPPORTED_CHIP_ID) {
+ data->buf[NVT_TS_PARAMS_WAKE_TYPE] != data->chip->wake_type ||
+ data->buf[NVT_TS_PARAMS_CHIP_ID] != data->chip->chip_id) {
dev_err(dev, "Unsupported touchscreen parameters: %*ph\n",
NVT_TS_PARAMS_SIZE, data->buf);
return -EIO;
@@ -277,8 +324,26 @@ static int nvt_ts_probe(struct i2c_client *client)
return 0;
}
+static const struct nvt_ts_i2c_chip_data nvt_ts_data = {
+ .wake_type = 0x05,
+ .chip_id = 0x05,
+};
+
+static const struct nvt_ts_i2c_chip_data nvt_nt36672a_ts_data = {
+ .wake_type = 0x01,
+ .chip_id = 0x08,
+};
+
+static const struct of_device_id nvt_ts_of_match[] = {
+ { .compatible = "novatek,nvt-ts", .data = &nvt_ts_data },
+ { .compatible = "novatek,nt36672a-ts", .data = &nvt_nt36672a_ts_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, nvt_ts_of_match);
+
static const struct i2c_device_id nvt_ts_i2c_id[] = {
- { "NVT-ts" },
+ { "NVT-ts", (unsigned long) &nvt_ts_data },
+ { "NT36672A-ts", (unsigned long) &nvt_nt36672a_ts_data },
{ }
};
MODULE_DEVICE_TABLE(i2c, nvt_ts_i2c_id);
@@ -287,6 +352,7 @@ static struct i2c_driver nvt_ts_driver = {
.driver = {
.name = "novatek-nvt-ts",
.pm = pm_sleep_ptr(&nvt_ts_pm_ops),
+ .of_match_table = nvt_ts_of_match,
},
.probe = nvt_ts_probe,
.id_table = nvt_ts_i2c_id,
--
2.45.1
^ permalink raw reply related
* [PATCH 0/2] novatek-nvt-ts: add support for NT36672A touchscreen
From: Joel Selvaraj via B4 Relay @ 2024-05-21 12:09 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Joel Selvaraj
Extend the novatek touchscreen driver to support NT36672A chip which
is found in phones like Xiaomi Poco F1 [1]. Added devicetree support for
the driver and used i2c chip data to handle the variation in chip id and
wake type. Also added vcc and iovcc regulators which are used to power
the touchscreen hardware.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts?h=v6.9
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
---
Joel Selvaraj (2):
dt-bindings: input: document Novatek NVT touchscreen controller
Input: novatek-nvt-ts: add support for NT36672A touchscreen
.../bindings/input/touchscreen/novatek,nvt-ts.yaml | 62 +++++++++++++++++
MAINTAINERS | 1 +
drivers/input/touchscreen/novatek-nvt-ts.c | 78 ++++++++++++++++++++--
3 files changed, 135 insertions(+), 6 deletions(-)
---
base-commit: 6578aac6a270bd6deb9f9319b991dd430de263dd
change-id: 20240518-nvt-ts-devicetree-regulator-support-ac9e49b78a16
Best regards,
--
Joel Selvaraj <joelselvaraj.oss@gmail.com>
^ permalink raw reply
* Input: uinput - race after request submit tiemout
From: Hillf Danton @ 2024-05-21 11:36 UTC (permalink / raw)
To: linux-input
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Tetsuo Handa,
Linus Torvalds, linux-kernel
uinput_request_submit() uinput_ioctl_handler()
--- ---
wait_for_completion_timeout() case UI_END_FF_ERASE:
req = uinput_request_find()
uinput_request_release_slot()
req->retval = ff_erase.retval;
complete(&req->done);
Given the race between request submit and ioctl handler, memory corruption
could happen after releasing request slot.
^ permalink raw reply
* Re: BUG: Framework Laptop 16 i2c-hid Based Touchpad Sometimes Fails To Initialize Properly On Early Boot
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-05-21 10:57 UTC (permalink / raw)
To: Linux kernel regressions list; +Cc: Arazil Songweaver, linux-input
In-Reply-To: <0111018f7508efb1-1206661a-d4b5-4bd1-b54f-ccb8504b8b4a-000000@us-west-1.amazonses.com>
On 14.05.24 04:57, Arazil Songweaver wrote:
> We are experiencing an issue where the touch pad on the Framework Laptop
> 16 fails to initialize properly when the "i2c-hid" is loaded early in
> the boot process. This issue is especially prominent when "i2c-hid" is
> built directly into the kernel. When the "i2c-hid" module is built in,
> the issue occurs roughly 50% of the time.
> (https://community.frame.work/t/touchpad-not-working-since-update-archlinux/50304) Moving the module load to later in the boot process appears to resolve this issue by making initialization more likely to succeed. (https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39.1)
>
> Kernel version: Linux artemis 6.9.0-1-git-01560-ga7c840ba5fa7 #1 SMP
> PREEMPT_DYNAMIC Tue, 14 May 2024 01:49:25 +0000 x86_64 GNU/Linux
>
> I'm using the standard Arch Linux AUR "linux-git" package with the
> following kernel configuration changes:
>
> CONFIG_I2C_DEBUG_CORE=y
> CONFIG_I2C_DEBUG_ALGO=y
> CONFIG_I2C_DEBUG_BUS=y
> CONFIG_I2C_HID=y
> CONFIG_I2C_HID_ACPI=y
> CONFIG_I2C_HID_OF=y
> CONFIG_I2C_HID_CORE=y
>
> We tried reverting the following patches without any behavior impact
> (good or bad):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=fb49deec375aa5beca4a5d71d7a74ec951872f28
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=418c5575d56410c6e186ab727bf32ae32447d497
>
> Impacted devices seem to include: "PIXA3854:00" and "i2c_designware
> AMDI0010:03"
Any news on this? If this is still unresolved I'll bring this to the
attention of the right developer, if this is a recent regressions (it
sounds like it, but it's not exactly clear; and from the first link
above it sounds like it's partly due to a change in arch's approach to
the initramfs).
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH] Input: wacom_w8001: Check for string overflow from strscpy calls
From: Ping Cheng @ 2024-05-21 3:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Aaron Armstrong Skomra, Jason Gerecke,
Joshua Dickens, Joshua Dickens
In-Reply-To: <Zkvcs0yg1ltamZPY@google.com>
On Mon, May 20, 2024 at 4:28 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
Hi Dmitry,
> > This fix is the same as [1]. Without checking the return value,
> > Wolfram's patch [2] fails our downstream build script. I'm adding my
> > r-b, if it makes any difference ;).
>
> Could you please tell me how exactly it makes your build script to fail?
We got an "unused-result warning". Jason made a temporary workaround
at https://github.com/linuxwacom/input-wacom/commit/e83a9bb3e48d2d1b52ec709e60f73b9960d568e5.
> My concern is that the warnings are not actionable and therefore pretty
> much worthless.
The return value tells us which strscpy call(s) didn't have enough space.
Cheers,
Ping
^ permalink raw reply
* Re: [PATCH v2] Input: xpad - add support for Machenike G5 Pro Controller
From: Dmitry Torokhov @ 2024-05-20 23:51 UTC (permalink / raw)
To: Kirill Artemev; +Cc: linux-input
In-Reply-To: <20240516032926.12501-2-artewar6767@gmail.com>
On Thu, May 16, 2024 at 08:29:27AM +0500, Kirill Artemev wrote:
> Add VID and PID to the xpad_device and VID to the xpad_table
> to allow driver to use Machenike G5 Pro Controller, which is
> XTYPE_XBOX360 compatible in Xinput mode.
>
> Signed-off-by: Kirill Artemev <artewar6767@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: wacom_w8001: Check for string overflow from strscpy calls
From: Dmitry Torokhov @ 2024-05-20 23:28 UTC (permalink / raw)
To: Ping Cheng
Cc: linux-input, Aaron Armstrong Skomra, Jason Gerecke,
Joshua Dickens, Joshua Dickens
In-Reply-To: <CAF8JNhKKCCwRzUxookmv9VUecT37fR8psoz7uSVBQqDhnYEBgQ@mail.gmail.com>
Hi Ping,
On Mon, May 20, 2024 at 11:00:26AM -0700, Ping Cheng wrote:
> Hi Dmitry,
>
> This fix is the same as [1]. Without checking the return value,
> Wolfram's patch [2] fails our downstream build script. I'm adding my
> r-b, if it makes any difference ;).
Could you please tell me how exactly it makes your build script to fail?
My concern is that the warnings are not actionable and therefore pretty
much worthless.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: wacom_w8001: Check for string overflow from strscpy calls
From: Ping Cheng @ 2024-05-20 18:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Aaron Armstrong Skomra, Jason Gerecke,
Joshua Dickens, Joshua Dickens
In-Reply-To: <20240510234332.139038-1-Joshua@Joshua-Dickens.com>
Hi Dmitry,
This fix is the same as [1]. Without checking the return value,
Wolfram's patch [2] fails our downstream build script. I'm adding my
r-b, if it makes any difference ;).
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Thank you,
Ping
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/wacom_sys.c?id=d9eef346b601afb0bd74b49e0db06f6a5cebd030
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/input/touchscreen/wacom_w8001.c?id=a9f08ad7adb3d2f90e11efbb40a1246ef95b0c04
On Fri, May 10, 2024 at 4:43 PM <joshua@joshua-dickens.com> wrote:
>
> From: Joshua Dickens <Joshua@Joshua-Dickens.com>
>
> The strscpy function is able to return an error code when a copy would
> overflow the size of the destination. The copy is stopped and the buffer
> terminated before overflow actually occurs so it is safe to continue
> execution, but we should still produce a warning should this occur.
>
> Signed-off-by: Joshua Dickens <joshua.dickens@wacom.com>
> ---
> drivers/input/touchscreen/wacom_w8001.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/touchscreen/wacom_w8001.c b/drivers/input/touchscreen/wacom_w8001.c
> index 928c5ee3ac36..b8acf196a09a 100644
> --- a/drivers/input/touchscreen/wacom_w8001.c
> +++ b/drivers/input/touchscreen/wacom_w8001.c
> @@ -625,7 +625,10 @@ static int w8001_connect(struct serio *serio, struct serio_driver *drv)
> /* For backwards-compatibility we compose the basename based on
> * capabilities and then just append the tool type
> */
> - strscpy(basename, "Wacom Serial", sizeof(basename));
> + if (strscpy(basename, "Wacom Serial", sizeof(basename)) < 0) {
> + dev_warn(&w8001->pen_dev->dev,
> + "String overflow while assembling basename");
> + }
>
> err_pen = w8001_setup_pen(w8001, basename, sizeof(basename));
> err_touch = w8001_setup_touch(w8001, basename, sizeof(basename));
> @@ -635,7 +638,11 @@ static int w8001_connect(struct serio *serio, struct serio_driver *drv)
> }
>
> if (!err_pen) {
> - strscpy(w8001->pen_name, basename, sizeof(w8001->pen_name));
> + if (strscpy(w8001->pen_name, basename,
> + sizeof(w8001->pen_name)) < 0) {
> + dev_warn(&w8001->pen_dev->dev,
> + "String overflow while assembling pen_name");
> + }
> strlcat(w8001->pen_name, " Pen", sizeof(w8001->pen_name));
> input_dev_pen->name = w8001->pen_name;
>
> @@ -651,7 +658,11 @@ static int w8001_connect(struct serio *serio, struct serio_driver *drv)
> }
>
> if (!err_touch) {
> - strscpy(w8001->touch_name, basename, sizeof(w8001->touch_name));
> + if (strscpy(w8001->touch_name, basename,
> + sizeof(w8001->touch_name)) < 0) {
> + dev_warn(&w8001->touch_dev->dev,
> + "String overflow while assembling touch_name");
> + }
> strlcat(w8001->touch_name, " Finger",
> sizeof(w8001->touch_name));
> input_dev_touch->name = w8001->touch_name;
> --
> 2.45.0
>
^ permalink raw reply
* Re: [PATCH RESEND v10 4/5] Input: cs40l50 - Add support for the CS40L50 haptic driver
From: James Ogletree @ 2024-05-20 15:47 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: James Ogletree, robh+dt@kernel.org, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Mark Brown, Jeff LaBundy,
open list:CIRRUS LOGIC HAPTIC DRIVERS,
open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
devicetree@vger.kernel.org
In-Reply-To: <BC84DC9F-65FB-4553-A0B9-52151DD549DB@cirrus.com>
Hi Dmitry,
Reaching out to get closure on these few comments before I send up the
next version.
> On May 3, 2024, at 10:25 AM, James Ogletree <James.Ogletree@cirrus.com> wrote:
>
> Hi Dmitry,
>
> Trimming down my last reply to just the points that need your attention/ack.
>
> I made some small edits for the sake of clarity.
>
>> On Apr 16, 2024, at 6:28 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>>
>> On Mon, Apr 08, 2024 at 03:32:13PM +0000, James Ogletree wrote:
>>>
>>> +/* Describes an area in DSP memory populated by effects */
>>> +struct cs40l50_bank {
>>> + enum cs40l50_bank_type type;
>>> + u32 base_index;
>>> + u32 max_index;
>>
>> This looks like it is written to the device, so I think this needs
>> proper endianness annotation. Is there any concern about padding between
>> the type and base_index?
>
> The structure itself is never written, so there is no concern about padding.
> Only base_index is written, and the endianness conversion is handled by regmap.
>
>>> +static void cs40l50_start_worker(struct work_struct *work)
>>> +{
>>> + struct cs40l50_work *work_data = container_of(work, struct cs40l50_work, work);
>>> + struct cs40l50_vibra *vibra = work_data->vibra;
>>> + struct cs40l50_effect *start_effect;
>>> +
>>> + if (pm_runtime_resume_and_get(vibra->dev) < 0)
>>> + goto err_free;
>>> +
>>> + mutex_lock(&vibra->lock);
>>> +
>>> + start_effect = cs40l50_find_effect(work_data->effect->id, &vibra->effect_head);
>>> + if (start_effect) {
>>> + while (--work_data->count >= 0) {
>>> + vibra->dsp.write(vibra->dev, vibra->regmap, start_effect->index);
>>> + usleep_range(work_data->effect->replay.length,
>>> + work_data->effect->replay.length + 100);
>>
>> If (I am reading this right you are spinning here playing the effect. It
>> would be much better if you tracked outstanding number of replays for an
>> effect and had a work re-scheduled that would play an instance.
>> Similarly to what code in ff-memless.c is doing.
>
> Yes, you are reading it right.
>
> It appears that ff-memless.c handles repeats atomically, however for
> reasons explained below, this driver must queue work for playback
> executions.
>
> This results in a possible scenario where if a playback is issued with a
> high enough repeat value, an erase operation could arrive in the middle of
> the chain of re-scheduling and disrupt the playbacks which have yet to be
> queued. But with the current approach, the effect is guaranteed to repeat
> any number of times without risk of being erased in the middle.
>
> That’s my concern with adopting the re-scheduling approach for this
> driver. Please let me know your thoughts.
>
>>> +static int cs40l50_erase(struct input_dev *dev, int effect_id)
>>> +{
>>> + struct cs40l50_vibra *vibra = input_get_drvdata(dev);
>>> + struct cs40l50_work work_data;
>>> +
>>> + work_data.vibra = vibra;
>>> + work_data.effect = &dev->ff->effects[effect_id];
>>> +
>>> + INIT_WORK(&work_data.work, cs40l50_erase_worker);
>>> +
>>> + /* Push to workqueue to serialize with playbacks */
>>> + queue_work(vibra->vibe_wq, &work_data.work);
>>> + flush_work(&work_data.work);
>>
>> You already take the lock when you play, upload or erase an effect. Why
>> do we need additional single-thread workqueue for this? Why do we need
>> additional ordering and synchronization?
>
> The workqueue is necessary is because playback blocks (via
> pm_runtime_resume_and_get), and so playback must defer work. Upload
> and erase are not called in atomic context, but without queueing those
> executions, they could cut in front of playbacks waiting in the
> workqueue.
>
> But as the callbacks are already serialized via the workqueue, then I do
> think the locks are excessive. That’s my thinking, let me know if it is
> sound.
>
> Best,
> James
^ permalink raw reply
* Re: [PATCH v2 4/7] HID: i2c-hid: elan: fix reset suspend current leakage
From: Doug Anderson @ 2024-05-20 15:38 UTC (permalink / raw)
To: Johan Hovold
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Linus Walleij, linux-input, devicetree,
linux-arm-msm, linux-kernel, stable, Steev Klimaszewski
In-Reply-To: <Zks5gJ7H6ZuWr_Xm@hovoldconsulting.com>
Hi,
On Mon, May 20, 2024 at 4:52 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Mon, May 20, 2024 at 01:44:06PM +0200, Johan Hovold wrote:
> > On Fri, May 10, 2024 at 04:36:08PM -0700, Doug Anderson wrote:
> > > On Tue, May 7, 2024 at 7:48 AM Johan Hovold <johan+linaro@kernel.org> wrote:
>
> > > > @@ -67,7 +77,14 @@ static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
> > > > struct i2c_hid_of_elan *ihid_elan =
> > > > container_of(ops, struct i2c_hid_of_elan, ops);
> > > >
> > > > - gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> > > > + /*
> > > > + * Do not assert reset when the hardware allows for it to remain
> > > > + * deasserted regardless of the state of the (shared) power supply to
> > > > + * avoid wasting power when the supply is left on.
> > > > + */
> > > > + if (!ihid_elan->no_reset_on_power_off)
> > > > + gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> > > > +
> > > > if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms)
> > > > msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms);
> > >
> > > Shouldn't the above two lines be inside the "if
> > > (!ihid_elan->no_reset_on_power_off)" test? If you're not setting the
> > > reset GPIO then you don't need to do the delay, right?
> >
> > Yes, I guess you're right. The off-delay is weird and not normally used,
> > but apparently it is needed by some panel-follower use case. AFAICT it's
> > not even related to the reset line, just a hack to add a delay before
> > the panel is reset by some other driver (see f2f43bf15d7a ("HID:
> > i2c-hid: elan: Add ili9882t timing")).
> >
> > I think that's why I just looked the other way and left this little
> > oddity here unchanged.
>
> Hit send too soon.
>
> Since this hack does not appear to be related to the reset line, I think
> it's correct to not have it depend on whether the reset line is asserted
> or not (e.g. as there could be 'panel-followers' with
> 'no_reset_on_power_off'):
>
> The datasheet specifies there should be 60ms between touch SDA
> sleep and panel RESX. Doug's series[1] allows panels and
> touchscreens to power on/off together, so we can add the 65 ms
> delay in i2c_hid_core_suspend before panel_unprepare.
>
> The power-off delay variable should probably be renamed, but that's a
> separate change.
>
> So I think v2 of this series is good to go.
Sure. As I think we've seen in the past, my choice of bikeshed paint
color seems to be quite different than yours, but nothing here seems
like it needs to block landing, so:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 0774d19038c496f0c3602fb505c43e1b2d8eed85
From: kernel test robot @ 2024-05-20 13:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 0774d19038c496f0c3602fb505c43e1b2d8eed85 Input: try trimming too long modalias strings
elapsed time: 726m
configs tested: 196
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs103_defconfig gcc
arc defconfig gcc
arc randconfig-001-20240520 gcc
arc randconfig-002-20240520 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm assabet_defconfig clang
arm collie_defconfig gcc
arm defconfig clang
arm ep93xx_defconfig clang
arm exynos_defconfig clang
arm hisi_defconfig gcc
arm imx_v6_v7_defconfig clang
arm lpc18xx_defconfig clang
arm moxart_defconfig gcc
arm netwinder_defconfig gcc
arm pxa168_defconfig clang
arm randconfig-001-20240520 clang
arm randconfig-002-20240520 clang
arm randconfig-003-20240520 gcc
arm randconfig-004-20240520 clang
arm spear13xx_defconfig gcc
arm spear3xx_defconfig clang
arm versatile_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240520 clang
arm64 randconfig-002-20240520 clang
arm64 randconfig-003-20240520 clang
arm64 randconfig-004-20240520 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240520 gcc
csky randconfig-002-20240520 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240520 clang
hexagon randconfig-002-20240520 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240520 clang
i386 buildonly-randconfig-002-20240520 clang
i386 buildonly-randconfig-003-20240520 clang
i386 buildonly-randconfig-004-20240520 clang
i386 buildonly-randconfig-005-20240520 clang
i386 buildonly-randconfig-006-20240520 clang
i386 defconfig clang
i386 randconfig-001-20240520 clang
i386 randconfig-002-20240520 clang
i386 randconfig-003-20240520 gcc
i386 randconfig-004-20240520 gcc
i386 randconfig-005-20240520 clang
i386 randconfig-006-20240520 gcc
i386 randconfig-011-20240520 gcc
i386 randconfig-012-20240520 gcc
i386 randconfig-013-20240520 clang
i386 randconfig-014-20240520 gcc
i386 randconfig-015-20240520 clang
i386 randconfig-016-20240520 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240520 gcc
loongarch randconfig-002-20240520 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k atari_defconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
mips bigsur_defconfig gcc
mips loongson2k_defconfig gcc
mips malta_defconfig gcc
mips malta_qemu_32r6_defconfig gcc
mips maltaup_xpa_defconfig gcc
mips vocore2_defconfig clang
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240520 gcc
nios2 randconfig-002-20240520 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240520 gcc
parisc randconfig-002-20240520 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc arches_defconfig gcc
powerpc bamboo_defconfig clang
powerpc currituck_defconfig clang
powerpc katmai_defconfig clang
powerpc maple_defconfig clang
powerpc mpc8315_rdb_defconfig clang
powerpc randconfig-001-20240520 gcc
powerpc randconfig-002-20240520 clang
powerpc randconfig-003-20240520 clang
powerpc sequoia_defconfig clang
powerpc storcenter_defconfig gcc
powerpc64 randconfig-001-20240520 clang
powerpc64 randconfig-002-20240520 gcc
powerpc64 randconfig-003-20240520 clang
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240520 gcc
riscv randconfig-002-20240520 gcc
riscv rv32_defconfig clang
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 debug_defconfig gcc
s390 defconfig clang
s390 randconfig-001-20240520 gcc
s390 randconfig-002-20240520 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20240520 gcc
sh randconfig-002-20240520 gcc
sh urquell_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240520 gcc
sparc64 randconfig-002-20240520 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240520 clang
um randconfig-002-20240520 gcc
um x86_64_defconfig clang
x86_64 alldefconfig gcc
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240520 clang
x86_64 buildonly-randconfig-002-20240520 gcc
x86_64 buildonly-randconfig-003-20240520 gcc
x86_64 buildonly-randconfig-004-20240520 gcc
x86_64 buildonly-randconfig-005-20240520 gcc
x86_64 buildonly-randconfig-006-20240520 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20240520 clang
x86_64 randconfig-002-20240520 gcc
x86_64 randconfig-003-20240520 gcc
x86_64 randconfig-004-20240520 gcc
x86_64 randconfig-005-20240520 gcc
x86_64 randconfig-006-20240520 clang
x86_64 randconfig-011-20240520 clang
x86_64 randconfig-012-20240520 gcc
x86_64 randconfig-013-20240520 clang
x86_64 randconfig-014-20240520 clang
x86_64 randconfig-015-20240520 gcc
x86_64 randconfig-016-20240520 gcc
x86_64 randconfig-071-20240520 clang
x86_64 randconfig-072-20240520 gcc
x86_64 randconfig-073-20240520 clang
x86_64 randconfig-074-20240520 gcc
x86_64 randconfig-075-20240520 clang
x86_64 randconfig-076-20240520 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20240520 gcc
xtensa randconfig-002-20240520 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 4/7] HID: i2c-hid: elan: fix reset suspend current leakage
From: Johan Hovold @ 2024-05-20 11:52 UTC (permalink / raw)
To: Doug Anderson
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Linus Walleij, linux-input, devicetree,
linux-arm-msm, linux-kernel, stable, Steev Klimaszewski
In-Reply-To: <Zks3hp5iUhTe3rLH@hovoldconsulting.com>
On Mon, May 20, 2024 at 01:44:06PM +0200, Johan Hovold wrote:
> On Fri, May 10, 2024 at 04:36:08PM -0700, Doug Anderson wrote:
> > On Tue, May 7, 2024 at 7:48 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> > > @@ -67,7 +77,14 @@ static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
> > > struct i2c_hid_of_elan *ihid_elan =
> > > container_of(ops, struct i2c_hid_of_elan, ops);
> > >
> > > - gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> > > + /*
> > > + * Do not assert reset when the hardware allows for it to remain
> > > + * deasserted regardless of the state of the (shared) power supply to
> > > + * avoid wasting power when the supply is left on.
> > > + */
> > > + if (!ihid_elan->no_reset_on_power_off)
> > > + gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> > > +
> > > if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms)
> > > msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms);
> >
> > Shouldn't the above two lines be inside the "if
> > (!ihid_elan->no_reset_on_power_off)" test? If you're not setting the
> > reset GPIO then you don't need to do the delay, right?
>
> Yes, I guess you're right. The off-delay is weird and not normally used,
> but apparently it is needed by some panel-follower use case. AFAICT it's
> not even related to the reset line, just a hack to add a delay before
> the panel is reset by some other driver (see f2f43bf15d7a ("HID:
> i2c-hid: elan: Add ili9882t timing")).
>
> I think that's why I just looked the other way and left this little
> oddity here unchanged.
Hit send too soon.
Since this hack does not appear to be related to the reset line, I think
it's correct to not have it depend on whether the reset line is asserted
or not (e.g. as there could be 'panel-followers' with
'no_reset_on_power_off'):
The datasheet specifies there should be 60ms between touch SDA
sleep and panel RESX. Doug's series[1] allows panels and
touchscreens to power on/off together, so we can add the 65 ms
delay in i2c_hid_core_suspend before panel_unprepare.
The power-off delay variable should probably be renamed, but that's a
separate change.
So I think v2 of this series is good to go.
Johan
^ permalink raw reply
* Re: [PATCH v2 4/7] HID: i2c-hid: elan: fix reset suspend current leakage
From: Johan Hovold @ 2024-05-20 11:44 UTC (permalink / raw)
To: Doug Anderson
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Linus Walleij, linux-input, devicetree,
linux-arm-msm, linux-kernel, stable, Steev Klimaszewski
In-Reply-To: <CAD=FV=V59t_tZ9Xk=uhbgOdTRYLKu+kZt8cpaksTkJo+D4yt8Q@mail.gmail.com>
Hi Doug,
and sorry about the late reply. Was travelling last week.
On Fri, May 10, 2024 at 04:36:08PM -0700, Doug Anderson wrote:
> On Tue, May 7, 2024 at 7:48 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> >
> > @@ -40,17 +41,17 @@ static int elan_i2c_hid_power_up(struct i2chid_ops *ops)
> > container_of(ops, struct i2c_hid_of_elan, ops);
> > int ret;
> >
> > + gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
>
> Could probably use a comment above it saying that this is important
> when we have "no_reset_on_power_off" and doesn't do anything bad when
> we don't so we can just do it unconditionally.
Possibly, but I'd prefer not to add comments for things like this, which
should be apparent from just looking at the code. And explicitly
asserting reset before deasserting it is not unusual in any way.
> > +
> > if (ihid_elan->vcc33) {
> > ret = regulator_enable(ihid_elan->vcc33);
> > if (ret)
> > - return ret;
> > + goto err_deassert_reset;
> > }
> >
> > ret = regulator_enable(ihid_elan->vccio);
> > - if (ret) {
> > - regulator_disable(ihid_elan->vcc33);
> > - return ret;
> > - }
> > + if (ret)
> > + goto err_disable_vcc33;
> >
> > if (ihid_elan->chip_data->post_power_delay_ms)
> > msleep(ihid_elan->chip_data->post_power_delay_ms);
> > @@ -60,6 +61,15 @@ static int elan_i2c_hid_power_up(struct i2chid_ops *ops)
> > msleep(ihid_elan->chip_data->post_gpio_reset_on_delay_ms);
> >
> > return 0;
> > +
> > +err_disable_vcc33:
> > + if (ihid_elan->vcc33)
> > + regulator_disable(ihid_elan->vcc33);
> > +err_deassert_reset:
> > + if (ihid_elan->no_reset_on_power_off)
> > + gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0);
>
> Small nit about the error label: it sounds as if when you go here you
> _will_ deassert reset when in actuality you might or might not
> (depending on no_reset_on_power_off).
Yes, this is similar to how err_disable_vcc33 may or may not disable the
optional regulator.
> Personally I prefer to label
> error jumps based on things I've done instead of things that the error
> jump needs to do, so you could call them "err_enabled_vcc33" and
> "err_asserted_reset"...
Naming labels after what they do is less error prone and also explicitly
recommended by the coding style.
> I don't feel that strongly about it, though, so if you love the label
> you have then no need to change it.
So I'd prefer keeping things this way.
> > @@ -67,7 +77,14 @@ static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
> > struct i2c_hid_of_elan *ihid_elan =
> > container_of(ops, struct i2c_hid_of_elan, ops);
> >
> > - gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> > + /*
> > + * Do not assert reset when the hardware allows for it to remain
> > + * deasserted regardless of the state of the (shared) power supply to
> > + * avoid wasting power when the supply is left on.
> > + */
> > + if (!ihid_elan->no_reset_on_power_off)
> > + gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
> > +
> > if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms)
> > msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms);
>
> Shouldn't the above two lines be inside the "if
> (!ihid_elan->no_reset_on_power_off)" test? If you're not setting the
> reset GPIO then you don't need to do the delay, right?
Yes, I guess you're right. The off-delay is weird and not normally used,
but apparently it is needed by some panel-follower use case. AFAICT it's
not even related to the reset line, just a hack to add a delay before
the panel is reset by some other driver (see f2f43bf15d7a ("HID:
i2c-hid: elan: Add ili9882t timing")).
I think that's why I just looked the other way and left this little
oddity here unchanged.
> > @@ -79,6 +96,7 @@ static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
> > static int i2c_hid_of_elan_probe(struct i2c_client *client)
> > {
> > struct i2c_hid_of_elan *ihid_elan;
> > + int ret;
> >
> > ihid_elan = devm_kzalloc(&client->dev, sizeof(*ihid_elan), GFP_KERNEL);
> > if (!ihid_elan)
> > @@ -93,21 +111,38 @@ static int i2c_hid_of_elan_probe(struct i2c_client *client)
> > if (IS_ERR(ihid_elan->reset_gpio))
> > return PTR_ERR(ihid_elan->reset_gpio);
> >
> > + ihid_elan->no_reset_on_power_off = of_property_read_bool(client->dev.of_node,
> > + "no-reset-on-power-off");
>
> Personally, I'd rather you query for the property before you request
> the GPIO and then request the GPIO in the "powered off" state just to
> keep everything in the most consistent state possible.
No, I don't know what state the reset line is in before the driver
probes. So either I leave it unchanged as I did in v1 or I assert it
here unconditionally as I do in v2 (e.g. to avoid deasserting reset
before the supply is stable).
Johan
^ permalink raw reply
* [PATCH] HID: lenovo: fix Fn-Lock on Lenovo TrackPoint Keyboard II in USB mode
From: ValdikSS @ 2024-05-20 0:05 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, Benjamin Tissoires, Rodrigo Aguilera
When Fn-Lock is pressed on Lenovo TrackPoint Keyboard II in USB mode,
the keyboard only sends the scancode to the host and does not toggle
the mode by itself, contrary to Bluetooth mode.
This results in non-working Fn-Lock switching.
Fix this issue by sending switching command upon receiving Fn-Lock
scancode.
Signed-off-by: ValdikSS <iam@valdikss.org.ru>
Reported-by: Rodrigo Aguilera <rodrigoaguileraparraga@gmail.com>
Tested-by: Rodrigo Aguilera <rodrigoaguileraparraga@gmail.com>
Cc: stable@vger.kernel.org # 6.x
---
drivers/hid/hid-lenovo.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index f86c1ea..a84fc55 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -758,6 +758,13 @@ static int lenovo_event_cptkbd(struct hid_device *hdev,
* ensure things are in sync (the syncing should be a no-op).
*/
cptkbd_data->fn_lock = !cptkbd_data->fn_lock;
+ if (hdev->product == USB_DEVICE_ID_LENOVO_TPIIUSBKBD) {
+ /*
+ * ThinkPad TrackPoint keyboard II in USB mode needs
+ * host to toggle Fn-lock
+ */
+ lenovo_send_cmd_cptkbd(hdev, 0x05, cptkbd_data->fn_lock);
+ }
}
return 0;
--
2.45.1
^ permalink raw reply related
* [dtor-input:next 188/188] drivers/input/input.c:1489:9: warning: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof ((1UL << 12)) *' (aka 'unsigned long *'))
From: kernel test robot @ 2024-05-19 21:39 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: llvm, oe-kbuild-all, linux-input, Peter Hutterer
tree: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
head: c1307f8a152ac69f7efb759edfb8d71b4aa228f4
commit: c1307f8a152ac69f7efb759edfb8d71b4aa228f4 [188/188] Input: try trimming too long modalias strings
config: hexagon-allnoconfig (https://download.01.org/0day-ci/archive/20240520/202405200512.hpbZWegE-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project fa9b1be45088dce1e4b602d451f118128b94237b)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240520/202405200512.hpbZWegE-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405200512.hpbZWegE-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/input.c:1489:9: warning: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof ((1UL << 12)) *' (aka 'unsigned long *')) [-Wcompare-distinct-pointer-types]
1489 | return min(len, PAGE_SIZE);
| ^~~~~~~~~~~~~~~~~~~
include/linux/minmax.h:67:19: note: expanded from macro 'min'
67 | #define min(x, y) __careful_cmp(x, y, <)
| ^~~~~~~~~~~~~~~~~~~~~~
include/linux/minmax.h:36:24: note: expanded from macro '__careful_cmp'
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~~~~~~~
include/linux/minmax.h:26:4: note: expanded from macro '__safe_cmp'
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~~~~~~~
include/linux/minmax.h:20:28: note: expanded from macro '__typecheck'
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
1 warning generated.
vim +1489 drivers/input/input.c
1477
1478 static ssize_t input_dev_show_modalias(struct device *dev,
1479 struct device_attribute *attr,
1480 char *buf)
1481 {
1482 struct input_dev *id = to_input_dev(dev);
1483 size_t len;
1484
1485 len = input_print_modalias(buf, PAGE_SIZE, id);
1486 if (len < PAGE_SIZE - 2)
1487 len += snprintf(buf + len, PAGE_SIZE - len, "\n");
1488
> 1489 return min(len, PAGE_SIZE);
1490 }
1491 static DEVICE_ATTR(modalias, S_IRUGO, input_dev_show_modalias, NULL);
1492
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next 188/188] drivers/input/input.c:1489:9: warning: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (((1UL) << 12)) *' (aka 'unsigned long *'))
From: kernel test robot @ 2024-05-19 21:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: llvm, oe-kbuild-all, linux-input, Peter Hutterer
tree: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
head: c1307f8a152ac69f7efb759edfb8d71b4aa228f4
commit: c1307f8a152ac69f7efb759edfb8d71b4aa228f4 [188/188] Input: try trimming too long modalias strings
config: arm-allnoconfig (https://download.01.org/0day-ci/archive/20240520/202405200547.y7iHuRu6-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project fa9b1be45088dce1e4b602d451f118128b94237b)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240520/202405200547.y7iHuRu6-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405200547.y7iHuRu6-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/input.c:1489:9: warning: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (((1UL) << 12)) *' (aka 'unsigned long *')) [-Wcompare-distinct-pointer-types]
1489 | return min(len, PAGE_SIZE);
| ^~~~~~~~~~~~~~~~~~~
include/linux/minmax.h:67:19: note: expanded from macro 'min'
67 | #define min(x, y) __careful_cmp(x, y, <)
| ^~~~~~~~~~~~~~~~~~~~~~
include/linux/minmax.h:36:24: note: expanded from macro '__careful_cmp'
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~~~~~~~
include/linux/minmax.h:26:4: note: expanded from macro '__safe_cmp'
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~~~~~~~
include/linux/minmax.h:20:28: note: expanded from macro '__typecheck'
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
1 warning generated.
vim +1489 drivers/input/input.c
1477
1478 static ssize_t input_dev_show_modalias(struct device *dev,
1479 struct device_attribute *attr,
1480 char *buf)
1481 {
1482 struct input_dev *id = to_input_dev(dev);
1483 size_t len;
1484
1485 len = input_print_modalias(buf, PAGE_SIZE, id);
1486 if (len < PAGE_SIZE - 2)
1487 len += snprintf(buf + len, PAGE_SIZE - len, "\n");
1488
> 1489 return min(len, PAGE_SIZE);
1490 }
1491 static DEVICE_ATTR(modalias, S_IRUGO, input_dev_show_modalias, NULL);
1492
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Scuf Envision Pro controller support
From: Andres David Ortiz @ 2024-05-19 20:23 UTC (permalink / raw)
To: linux-input
Hello. I would like to help get the sucf envision pro controller
supported in the Linux kernel. Currently, everything works except
mappings and rumble.
Mappings can be worked around in userspace, and I created the relevant
pull rule requests to SDL to get them working in Steam and other SDL
applications.
What would be needed to get force feedback support working for this controller?
here is a lsusb -vd of the controller in question
sudo lsusb -vd 2e95:434d
Bus 001 Device 005: ID 2e95:434d SCUF Gaming SCUF Envision Pro Controller
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x2e95 SCUF Gaming
idProduct 0x434d SCUF Envision Pro Controller
bcdDevice 0.00
iManufacturer 1 Scuf Gaming
iProduct 2 SCUF Envision Pro Controller
iSerial 3 18f6f23000070215
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x01b5
bNumInterfaces 5
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 250mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 10
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x005d
bInCollection 2
baInterfaceNr(0) 1
baInterfaceNr(1) 2
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0402 Headset
bAssocTerminal 0
bNrChannels 1
wChannelConfig 0x0004
Center Front (C)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 3
bSourceID 1
bControlSize 1
bmaControls(0) 0x01
Mute Control
bmaControls(1) 0x02
Volume Control
iFeature 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 3
iTerminal 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 5
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 10
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 8
bSourceID 7
bControlSize 1
bmaControls(0) 0x01
Mute Control
bmaControls(1) 0x02
Volume Control
bmaControls(2) 0x02
Volume Control
iFeature 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 6
bSourceID 1
bControlSize 1
bmaControls(0) 0x03
Mute Control
Volume Control
bmaControls(1) 0x00
iFeature 0
AudioControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 4 (MIXER_UNIT)
bUnitID 7
bNrInPins 2
baSourceID(0) 5
baSourceID(1) 6
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
bmControls(0) 0x00
iMixer 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 9
wTerminalType 0x0402 Headset
bAssocTerminal 0
bSourceID 8
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 4
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 32
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize 2
bBitResolution 16
bSamFreqType 8 Discrete
tSamFreq[ 0] 8000
tSamFreq[ 1] 11025
tSamFreq[ 2] 16000
tSamFreq[ 3] 22050
tSamFreq[ 4] 24000
tSamFreq[ 5] 32000
tSamFreq[ 6] 44100
tSamFreq[ 7] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0062 1x 98 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0001
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 4
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 32
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize 3
bBitResolution 24
bSamFreqType 8 Discrete
tSamFreq[ 0] 8000
tSamFreq[ 1] 11025
tSamFreq[ 2] 16000
tSamFreq[ 3] 22050
tSamFreq[ 4] 24000
tSamFreq[ 5] 32000
tSamFreq[ 6] 44100
tSamFreq[ 7] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0093 1x 147 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0001
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 5
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 26
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 6 Discrete
tSamFreq[ 0] 32000
tSamFreq[ 1] 44100
tSamFreq[ 2] 48000
tSamFreq[ 3] 64000
tSamFreq[ 4] 88200
tSamFreq[ 5] 96000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0184 1x 388 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0001
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 5
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 26
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 3
bBitResolution 24
bSamFreqType 6 Discrete
tSamFreq[ 0] 32000
tSamFreq[ 1] 44100
tSamFreq[ 2] 48000
tSamFreq[ 3] 64000
tSamFreq[ 4] 88200
tSamFreq[ 5] 96000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0246 1x 582 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0001
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 156
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 154
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
Regards
Andres
^ permalink raw reply
* Re: [PATCH 1/2] input: add driver for Hynitron CST816X touchscreen
From: Krzysztof Kozlowski @ 2024-05-19 11:49 UTC (permalink / raw)
To: Oleh Kuzhylnyi, linux-input
Cc: dmitry.torokhov, artur.serhiienko, igor.opaniuk
In-Reply-To: <20240517092732.47715-1-kuzhylol@gmail.com>
On 17/05/2024 11:27, Oleh Kuzhylnyi wrote:
> Introduce support for the Hynitron CST816X touchscreen controller
> used for 240×240 1.28-inch Round LCD Display Module manufactured
> by Waveshare Electronics. The driver is designed based on an Arduino
> implementation marked as under MIT License. This driver is written
> for a particular round display based on the CST816S controller, which
> is not compatiable with existing driver for Hynitron controllers.
>
...
> +static int cst816x_process_touch(struct cst816x_priv *priv)
> +{
> + u8 *raw;
> + int rc;
> +
> + rc = cst816x_i2c_read_reg(priv, CST816X_FRAME);
> + if (!rc) {
> + raw = priv->rxtx;
> +
> + priv->info.gesture = raw[0];
> + priv->info.x = ((raw[2] & 0x0F) << 8) | raw[3];
> + priv->info.y = ((raw[4] & 0x0F) << 8) | raw[5];
> +
> + dev_dbg(priv->dev, "x: %d, y: %d, gesture: 0x%x\n",
> + priv->info.x, priv->info.y, priv->info.gesture);
> + } else {
> + dev_warn(priv->dev, "request was dropped\n");
Not a warn. First, it feels like really spamming the log, second,
drivers should be moderately quiet.
> + }
> +
> + return rc;
> +}
> +
> +static int cst816x_register_input(struct cst816x_priv *priv)
> +{
> + int rc;
> +
> + priv->input = devm_input_allocate_device(priv->dev);
> + if (!priv->input) {
> + rc = -ENOMEM;
> + dev_err(priv->dev, "input device alloc err: %d\n", rc);
Memory allocation errors are *never* printk'ed by drivers.
> + goto err;
> + }
...
> +static int cst816x_resume(struct device *dev)
> +{
> + struct cst816x_priv *priv = i2c_get_clientdata(to_i2c_client(dev));
> + int rc;
> +
> + cst816x_reset(priv);
> + rc = cst816x_regs_setup(priv);
> + if (!rc)
> + enable_irq(priv->irq);
> +
> + return rc;
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(cst816x_pm_ops, cst816x_suspend, cst816x_resume);
> +
> +static int cst816x_probe(struct i2c_client *client)
> +{
> + struct cst816x_priv *priv;
> + struct device *dev = &client->dev;
> + int rc;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + rc = -ENOMEM;
No, just return.
> + dev_err(dev, "devm alloc failed: %d\n", rc);
No, drop. This is some ancient, downstream code. Do you see anything
like this anywhere else?
> + goto err;
> + }
> +
> + INIT_DELAYED_WORK(&priv->dw, cst816x_dw_cb);
> + timer_setup(&priv->timer, cst816x_timer_cb, 0);
> +
> + priv->dev = dev;
> + priv->client = client;
> +
> + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (priv->reset == NULL) {
> + rc = -EIO;
Syntax is return dev_err_probe().
Same everywhere else.
Best regards,
Krzysztof
^ 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