* [syzbot] Monthly input report (Sep 2024)
From: syzbot @ 2024-09-02 8:17 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, 3 new issues were detected and 0 were fixed.
In total, 18 issues are still open and 57 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 702 No possible deadlock in evdev_pass_values (2)
https://syzkaller.appspot.com/bug?extid=13d3cb2a3dc61e6092f5
<2> 392 Yes INFO: task hung in uhid_char_release
https://syzkaller.appspot.com/bug?extid=8fe2d362af0e1cba8735
<3> 353 Yes WARNING in cm109_urb_irq_callback/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
<4> 23 Yes WARNING in cm109_input_open/usb_submit_urb (3)
https://syzkaller.appspot.com/bug?extid=ac0f9c4cc1e034160492
<5> 21 Yes possible deadlock in uinput_request_submit
https://syzkaller.appspot.com/bug?extid=159077b1355b8cd72757
<6> 19 No possible deadlock in __input_unregister_device
https://syzkaller.appspot.com/bug?extid=3f4bf5c599ee9b16d704
<7> 10 Yes INFO: rcu detected stall in sendmsg (4)
https://syzkaller.appspot.com/bug?extid=9c0539eda655673bdaa4
<8> 9 No possible deadlock in hid_hw_open
https://syzkaller.appspot.com/bug?extid=2313ca2498b9554beeba
<9> 3 Yes WARNING in bcm5974_start_traffic/usb_submit_urb (2)
https://syzkaller.appspot.com/bug?extid=b064b5599f18f7ebb1e1
---
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
* [PATCH 5.10.y] HID: microsoft: Add rumble support to latest xbox controllers
From: Wei Ping.Xiao @ 2024-09-02 2:42 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input, linux-kernel
Cc: svv, hadess, Jiri Kosina
In-Reply-To: <20240902024205.9243-1-xiaoweiping.pccw@gmail.com>
From: Siarhei Vishniakou <svv@google.com>
Currently, rumble is only supported via bluetooth on a single xbox
controller, called 'model 1708'. On the back of the device, it's named
'wireless controller for xbox one'. However, in 2021, Microsoft released
a firmware update for this controller. As part of this update, the HID
descriptor of the device changed. The product ID was also changed from
0x02fd to 0x0b20. On this controller, rumble was supported via
hid-microsoft, which matched against the old product id (0x02fd). As a
result, the firmware update broke rumble support on this controller.
See:
https://news.xbox.com/en-us/2021/09/08/xbox-controller-firmware-update-rolling-out-to-insiders-starting-today/
The hid-microsoft driver actually supports rumble on the new firmware,
as well. So simply adding new product id is sufficient to bring back
this support.
After discussing further with the xbox team, it was pointed out that
another xbox controller, xbox elite series 2, can be supported in a
similar way.
Add rumble support for all of these devices in this patch. Two of the
devices have received firmware updates that caused their product id's to
change. Both old and new firmware versions of these devices were tested.
The tested controllers are:
1. 'wireless controller for xbox one', model 1708
2. 'xbox wireless controller', model 1914. This is also sometimes
referred to as 'xbox series S|X'.
3. 'elite series 2', model 1797.
The tested configurations are:
1. model 1708, pid 0x02fd (old firmware)
2. model 1708, pid 0x0b20 (new firmware)
3. model 1914, pid 0x0b13
4. model 1797, pid 0x0b05 (old firmware)
5. model 1797, pid 0x0b22 (new firmware)
I verified rumble support on both bluetooth and usb.
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Siarhei Vishniakou <svv@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-ids.h | 10 +++++++++-
drivers/hid/hid-microsoft.c | 11 ++++++++++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9f3f7588fe46..c4e4a24692f6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -875,7 +875,15 @@
#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
#define USB_DEVICE_ID_MS_POWER_COVER 0x07da
#define USB_DEVICE_ID_MS_SURFACE3_COVER 0x07de
-#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
+/*
+ * For a description of the Xbox controller models, refer to:
+ * https://en.wikipedia.org/wiki/Xbox_Wireless_Controller#Summary
+ */
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708 0x02fd
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE 0x0b20
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914 0x0b13
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797 0x0b05
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE 0x0b22
#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb
#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0
#define USB_DEVICE_ID_MS_MOUSE_0783 0x0783
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 071fd093a5f4..9345e2bfd56e 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -446,7 +446,16 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_PRESENTER },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x091B),
.driver_data = MS_SURFACE_DIAL },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER),
+
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE),
.driver_data = MS_QUIRK_FF },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS),
.driver_data = MS_QUIRK_FF },
--
2.39.1
^ permalink raw reply related
* [PATCH 5.10.y] HID: microsoft: Add rumble support to latest xbox controllers
From: Wei Ping.Xiao @ 2024-09-02 2:42 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input, linux-kernel
Cc: svv, hadess, Jiri Kosina
From: Siarhei Vishniakou <svv@google.com>
Currently, rumble is only supported via bluetooth on a single xbox
controller, called 'model 1708'. On the back of the device, it's named
'wireless controller for xbox one'. However, in 2021, Microsoft released
a firmware update for this controller. As part of this update, the HID
descriptor of the device changed. The product ID was also changed from
0x02fd to 0x0b20. On this controller, rumble was supported via
hid-microsoft, which matched against the old product id (0x02fd). As a
result, the firmware update broke rumble support on this controller.
See:
https://news.xbox.com/en-us/2021/09/08/xbox-controller-firmware-update-rolling-out-to-insiders-starting-today/
The hid-microsoft driver actually supports rumble on the new firmware,
as well. So simply adding new product id is sufficient to bring back
this support.
After discussing further with the xbox team, it was pointed out that
another xbox controller, xbox elite series 2, can be supported in a
similar way.
Add rumble support for all of these devices in this patch. Two of the
devices have received firmware updates that caused their product id's to
change. Both old and new firmware versions of these devices were tested.
The tested controllers are:
1. 'wireless controller for xbox one', model 1708
2. 'xbox wireless controller', model 1914. This is also sometimes
referred to as 'xbox series S|X'.
3. 'elite series 2', model 1797.
The tested configurations are:
1. model 1708, pid 0x02fd (old firmware)
2. model 1708, pid 0x0b20 (new firmware)
3. model 1914, pid 0x0b13
4. model 1797, pid 0x0b05 (old firmware)
5. model 1797, pid 0x0b22 (new firmware)
I verified rumble support on both bluetooth and usb.
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Siarhei Vishniakou <svv@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-ids.h | 10 +++++++++-
drivers/hid/hid-microsoft.c | 11 ++++++++++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9f3f7588fe46..c4e4a24692f6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -875,7 +875,15 @@
#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
#define USB_DEVICE_ID_MS_POWER_COVER 0x07da
#define USB_DEVICE_ID_MS_SURFACE3_COVER 0x07de
-#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
+/*
+ * For a description of the Xbox controller models, refer to:
+ * https://en.wikipedia.org/wiki/Xbox_Wireless_Controller#Summary
+ */
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708 0x02fd
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE 0x0b20
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914 0x0b13
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797 0x0b05
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE 0x0b22
#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb
#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0
#define USB_DEVICE_ID_MS_MOUSE_0783 0x0783
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 071fd093a5f4..9345e2bfd56e 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -446,7 +446,16 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_PRESENTER },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x091B),
.driver_data = MS_SURFACE_DIAL },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER),
+
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE),
.driver_data = MS_QUIRK_FF },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS),
.driver_data = MS_QUIRK_FF },
--
2.39.1
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS dac973838b0a37d32141c50cf3882b5ff0e42543
From: kernel test robot @ 2024-09-01 17:17 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: dac973838b0a37d32141c50cf3882b5ff0e42543 Input: zinitix - varying icon status registers
elapsed time: 877m
configs tested: 133
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig gcc-13.2.0
arc allnoconfig gcc-14.1.0
arc allyesconfig gcc-13.2.0
arc defconfig gcc-14.1.0
arm allmodconfig gcc-13.2.0
arm allnoconfig gcc-14.1.0
arm allyesconfig gcc-13.2.0
arm aspeed_g5_defconfig clang-20
arm at91_dt_defconfig clang-20
arm clps711x_defconfig clang-20
arm davinci_all_defconfig clang-20
arm defconfig gcc-14.1.0
arm exynos_defconfig clang-20
arm64 alldefconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240901 clang-18
i386 buildonly-randconfig-002-20240901 clang-18
i386 buildonly-randconfig-003-20240901 clang-18
i386 buildonly-randconfig-004-20240901 clang-18
i386 buildonly-randconfig-005-20240901 clang-18
i386 buildonly-randconfig-006-20240901 clang-18
i386 defconfig clang-18
i386 randconfig-001-20240901 clang-18
i386 randconfig-002-20240901 clang-18
i386 randconfig-003-20240901 clang-18
i386 randconfig-004-20240901 clang-18
i386 randconfig-005-20240901 clang-18
i386 randconfig-006-20240901 clang-18
i386 randconfig-011-20240901 clang-18
i386 randconfig-012-20240901 clang-18
i386 randconfig-013-20240901 clang-18
i386 randconfig-014-20240901 clang-18
i386 randconfig-015-20240901 clang-18
i386 randconfig-016-20240901 clang-18
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k defconfig gcc-14.1.0
m68k hp300_defconfig clang-20
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips ci20_defconfig clang-20
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
openrisc allnoconfig clang-20
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc64 defconfig gcc-14.1.0
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allyesconfig gcc-14.1.0
powerpc fsp2_defconfig clang-20
powerpc mpc832x_rdb_defconfig clang-20
powerpc tqm8540_defconfig clang-20
powerpc wii_defconfig clang-20
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh ecovec24_defconfig clang-20
sh j2_defconfig clang-20
sh kfr2r09_defconfig clang-20
sh urquell_defconfig clang-20
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig gcc-12
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240901 gcc-12
x86_64 buildonly-randconfig-002-20240901 gcc-12
x86_64 buildonly-randconfig-003-20240901 gcc-12
x86_64 buildonly-randconfig-004-20240901 gcc-12
x86_64 buildonly-randconfig-005-20240901 gcc-12
x86_64 buildonly-randconfig-006-20240901 gcc-12
x86_64 defconfig clang-18
x86_64 kexec gcc-12
x86_64 randconfig-001-20240901 gcc-12
x86_64 randconfig-002-20240901 gcc-12
x86_64 randconfig-003-20240901 gcc-12
x86_64 randconfig-004-20240901 gcc-12
x86_64 randconfig-005-20240901 gcc-12
x86_64 randconfig-006-20240901 gcc-12
x86_64 randconfig-011-20240901 gcc-12
x86_64 randconfig-012-20240901 gcc-12
x86_64 randconfig-013-20240901 gcc-12
x86_64 randconfig-014-20240901 gcc-12
x86_64 randconfig-015-20240901 gcc-12
x86_64 randconfig-016-20240901 gcc-12
x86_64 randconfig-071-20240901 gcc-12
x86_64 randconfig-072-20240901 gcc-12
x86_64 randconfig-073-20240901 gcc-12
x86_64 randconfig-074-20240901 gcc-12
x86_64 randconfig-075-20240901 gcc-12
x86_64 randconfig-076-20240901 gcc-12
x86_64 rhel-8.3-rust clang-18
x86_64 rhel-8.3 gcc-12
xtensa allnoconfig gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 2/2] input: add driver for Hynitron CST816X touchscreen
From: Dmitry Torokhov @ 2024-09-01 4:27 UTC (permalink / raw)
To: Oleh Kuzhylnyi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-input,
devicetree, linux-kernel, Conor Dooley, igor.opaniuk,
Neil Armstrong, Jeff LaBundy
In-Reply-To: <20240829212014.111357-2-kuzhylol@gmail.com>
Hi Oleh,
On Thu, Aug 29, 2024 at 11:20:14PM +0200, 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.
>
> Signed-off-by: Oleh Kuzhylnyi <kuzhylol@gmail.com>
> ---
>
> Changes in v4:
> - Update commit based on Dmitry's feedback:
> - Move abs_x and abs_y to u16
> - Remove __packed qualifier for touch_info struct
> - Hide tiny touch irq context to stack
> - Extend cst816x_i2c_read_register() with buf and buf_size
> - Remove loop from event lookup
Thank you for making the changes, a few more comments/suggestions:
> +
> +static const struct cst816x_event_mapping event_map[16] = {
> + {CST816X_SWIPE_UP, BTN_FORWARD},
> + {CST816X_SWIPE_DOWN, BTN_BACK},
> + {CST816X_SWIPE_LEFT, BTN_LEFT},
> + {CST816X_SWIPE_RIGHT, BTN_RIGHT},
> + {CST816X_SINGLE_TAP, BTN_TOUCH},
> + {CST816X_LONG_PRESS, BTN_TOOL_TRIPLETAP},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> + {CST816X_RESERVED, KEY_RESERVED},
> +};
> +
> +static int cst816x_i2c_read_register(struct cst816x_priv *priv, u8 reg,
> + void *buf, size_t len)
> +{
> + struct i2c_client *client;
Whenever reasonable combine declaration and initialization:
struct i2c_client *client = priv->client;
> + struct i2c_msg xfer[2];
struct i2c_msg xfer[] = {
{
.addr = client->addr,
.buf = ®,
.len = sizeof(reg),
},
{
.addr = client->addr,
.flags = I2C_M_RD,
.buf = buf,
.len = len,
},
};
> + int rc;
> +
> + client = priv->client;
> +
> + xfer[0].addr = client->addr;
> + xfer[0].flags = 0;
> + xfer[0].buf = ®
> + xfer[0].len = sizeof(reg);
> +
> + xfer[1].addr = client->addr;
> + xfer[1].flags = I2C_M_RD;
> + xfer[1].buf = buf;
> + xfer[1].len = len;
> +
> + rc = i2c_transfer(client->adapter, xfer, ARRAY_SIZE(xfer));
> + if (rc != ARRAY_SIZE(xfer)) {
> + if (rc >= 0)
> + rc = -EIO;
rc = rc < 0 ? rc : -EIO;
dev_err(...);
return rc;
> + } else {
> + rc = 0;
> + }
> +
> + if (rc < 0)
> + dev_err(&client->dev, "i2c rx err: %d\n", rc);
> +
> + return rc;
Explicitly returning 0 on success is preferred if code looks reasonable.
return 0;
> +}
> +
> +static int cst816x_process_touch(struct cst816x_priv *priv,
> + struct cst816x_touch_info *info)
> +{
> + u8 raw[8];
> + int rc;
int error;
> +
> + rc = cst816x_i2c_read_register(priv, CST816X_FRAME, raw, sizeof(raw));
> + if (!rc) {
error = cst816x_i2c_read_register(...);
if (error)
return error;
> + info->gesture = raw[0];
> + info->touch = raw[1];
> + info->abs_x = ((raw[2] & 0x0F) << 8) | raw[3];
I think it can be written as
info->abs_x = get_unaligned_le16(&raw[2]) & GENMASK(11, 0);
> + info->abs_y = ((raw[4] & 0x0F) << 8) | raw[5];
> +
> + dev_dbg(priv->dev, "x: %d, y: %d, t: %d, g: 0x%x\n",
> + info->abs_x, info->abs_y, info->touch, info->gesture);
> + }
> +
> + return rc;
return 0;
> +}
> +
> +static int cst816x_register_input(struct cst816x_priv *priv)
> +{
> + priv->input = devm_input_allocate_device(priv->dev);
> + if (!priv->input)
> + return -ENOMEM;
> +
> + priv->input->name = "Hynitron CST816X Touchscreen";
> + priv->input->phys = "input/ts";
> + priv->input->id.bustype = BUS_I2C;
> + input_set_drvdata(priv->input, priv);
> +
> + for (unsigned int i = 0; i < ARRAY_SIZE(event_map); i++)
> + input_set_capability(priv->input, EV_KEY, event_map[i].code);
> +
> + input_set_abs_params(priv->input, ABS_X, 0, 240, 0, 0);
> + input_set_abs_params(priv->input, ABS_Y, 0, 240, 0, 0);
> +
> + return input_register_device(priv->input);
> +}
> +
> +static void cst816x_reset(struct cst816x_priv *priv)
> +{
I believe the reset line should be optional, and so check for non-NULL
here before trying to execute the reset sequence.
> + gpiod_set_value_cansleep(priv->reset, 1);
> + msleep(50);
> + gpiod_set_value_cansleep(priv->reset, 0);
> + msleep(100);
> +}
> +
> +static void report_gesture_event(const struct cst816x_priv *priv,
> + enum cst816x_gestures gesture, bool touch)
> +{
> + u16 key = event_map[gesture & 0x0F].code;
> +
> + if (key != KEY_RESERVED)
> + input_report_key(priv->input, key, touch);
> +
> + if (!touch)
> + input_report_key(priv->input, BTN_TOUCH, 0);
This chunk does not belong here but rather where you report the rest of
the touch state.
> +}
> +
> +/*
> + * Supports five gestures: TOUCH, LEFT, RIGHT, FORWARD, BACK, and LONG_PRESS.
> + * Reports surface interaction, sliding coordinates and finger detachment.
> + *
> + * 1. TOUCH Gesture Scenario:
> + *
> + * [x/y] [touch] [gesture] [Action] [Report ABS] [Report Key]
> + * x y true 0x00 Touch ABS_X_Y BTN_TOUCH
> + * x y true 0x00 Slide ABS_X_Y
> + * x y false 0x05 Gesture BTN_TOUCH
> + *
> + * 2. LEFT, RIGHT, FORWARD, BACK, and LONG_PRESS Gestures Scenario:
> + *
> + * [x/y] [touch] [gesture] [Action] [Report ABS] [Report Key]
> + * x y true 0x00 Touch ABS_X_Y BTN_TOUCH
> + * x y true 0x01 Gesture ABS_X_Y BTN_FORWARD
> + * x y true 0x01 Slide ABS_X_Y
> + * x y false 0x01 Detach BTN_FORWARD | BTN_TOUCH
> + */
> +static irqreturn_t cst816x_irq_cb(int irq, void *cookie)
> +{
> + struct cst816x_priv *priv = (struct cst816x_priv *)cookie;
No need to cast void pointers.
> + struct cst816x_touch_info info;
> +
> + if (!cst816x_process_touch(priv, &info)) {
This makes it appear cst816x_process_touch() returning boolean.
error = cst816x_process_touch(priv, &info);
if (error)
goto out;
> + if (info.touch) {
> + input_report_abs(priv->input, ABS_X, info.abs_x);
> + input_report_abs(priv->input, ABS_Y, info.abs_y);
> + input_report_key(priv->input, BTN_TOUCH, 1);
> + }
} else {
input_report_key(priv->input, BTN_TOUCH, 0);
}
> +
> + if (info.gesture)
> + report_gesture_event(priv, info.gesture, info.touch);
> +
> + input_sync(priv->input);
> + }
out:
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int cst816x_probe(struct i2c_client *client)
> +{
> + struct cst816x_priv *priv;
> + struct device *dev = &client->dev;
> + int rc;
int error;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = dev;
> + priv->client = client;
> +
> + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
Please make reset optional, it does not have to be handled by the driver
if something else (firmware) will be doing power sequencing.
> + if (IS_ERR(priv->reset))
> + return dev_err_probe(dev, PTR_ERR(priv->reset),
> + "reset gpio not found\n");
> +
> + cst816x_reset(priv);
> +
> + rc = cst816x_register_input(priv);
> + if (rc)
> + return dev_err_probe(dev, rc, "input register failed\n");
> +
> + rc = devm_request_threaded_irq(dev, client->irq, NULL, cst816x_irq_cb,
> + IRQF_ONESHOT, dev->driver->name, priv);
> + if (rc)
> + return dev_err_probe(dev, rc, "irq request failed\n");
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id cst816x_id[] = {
> + { .name = "cst816s", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, cst816x_id);
> +
> +static const struct of_device_id cst816x_of_match[] = {
> + { .compatible = "hynitron,cst816s", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, cst816x_of_match);
> +
> +static struct i2c_driver cst816x_driver = {
> + .driver = {
> + .name = "cst816x",
> + .of_match_table = cst816x_of_match,
> + },
> + .id_table = cst816x_id,
> + .probe = cst816x_probe,
> +};
> +
> +module_i2c_driver(cst816x_driver);
> +
> +MODULE_AUTHOR("Oleh Kuzhylnyi <kuzhylol@gmail.com>");
> +MODULE_DESCRIPTION("Hynitron CST816X Touchscreen Driver");
> +MODULE_LICENSE("GPL");
> --
> 2.34.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: zinitix - Varying icon status registers
From: Dmitry Torokhov @ 2024-09-01 2:09 UTC (permalink / raw)
To: Linus Walleij; +Cc: Nikita Travkin, linux-input
In-Reply-To: <20240830-zinitix-tk-versions-v2-2-90eae6817eda@linaro.org>
On Fri, Aug 30, 2024 at 04:04:28PM +0200, Linus Walleij wrote:
> The different revisions of the Zinitix BTXXX touchscreens place
> the icon status register (to read out touchkey status) in
> different places. Use the chip revision bits to discern
> between the different versions at runtime.
>
> This makes touchkeys work on the BT404 on the Samsung Codina
> GT-I8160 mobile phone.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - No changes
> ---
> drivers/input/touchscreen/zinitix.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
> index e47e0bff80db..b6b380f5aed5 100644
> --- a/drivers/input/touchscreen/zinitix.c
> +++ b/drivers/input/touchscreen/zinitix.c
> @@ -35,7 +35,13 @@
> #define ZINITIX_DEBUG_REG 0x0115 /* 0~7 */
>
> #define ZINITIX_TOUCH_MODE 0x0010
> +
> #define ZINITIX_CHIP_REVISION 0x0011
> +#define ZINITIX_CHIP_BTX0X_MASK 0xF0F0
> +#define ZINITIX_CHIP_BT4X2 0x4020
> +#define ZINITIX_CHIP_BT4X3 0x4030
> +#define ZINITIX_CHIP_BT4X4 0x4040
> +
> #define ZINITIX_FIRMWARE_VERSION 0x0012
>
> #define ZINITIX_USB_DETECT 0x116
> @@ -63,7 +69,11 @@
> #define ZINITIX_Y_RESOLUTION 0x00C1
>
> #define ZINITIX_POINT_STATUS_REG 0x0080
> -#define ZINITIX_ICON_STATUS_REG 0x00AA
> +
> +#define ZINITIX_BT4X2_ICON_STATUS_REG 0x009A
> +#define ZINITIX_BT4X3_ICON_STATUS_REG 0x00A0
> +#define ZINITIX_BT4X4_ICON_STATUS_REG 0x00A0
> +#define ZINITIX_BT5XX_ICON_STATUS_REG 0x00AA
>
> #define ZINITIX_POINT_COORD_REG (ZINITIX_POINT_STATUS_REG + 2)
>
> @@ -425,7 +435,18 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
> }
>
> if (le16_to_cpu(touch_event.status) & BIT_ICON_EVENT) {
> - error = zinitix_read_data(bt541->client, ZINITIX_ICON_STATUS_REG,
> + u16 iconstatus;
> +
> + if ((bt541->chip_revision & ZINITIX_CHIP_BTX0X_MASK) == ZINITIX_CHIP_BT4X2)
> + iconstatus = ZINITIX_BT4X2_ICON_STATUS_REG;
> + else if ((bt541->chip_revision & ZINITIX_CHIP_BTX0X_MASK) == ZINITIX_CHIP_BT4X3)
> + iconstatus = ZINITIX_BT4X3_ICON_STATUS_REG;
> + else if ((bt541->chip_revision & ZINITIX_CHIP_BTX0X_MASK) == ZINITIX_CHIP_BT4X4)
> + iconstatus = ZINITIX_BT4X4_ICON_STATUS_REG;
> + else
> + iconstatus = ZINITIX_BT5XX_ICON_STATUS_REG;
This does not need to be re-calculated every interrupt. I move this into
zinitix_init_touch() and turned into a switch, and applied.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: zinitix - Read and cache device version numbers
From: Dmitry Torokhov @ 2024-09-01 2:07 UTC (permalink / raw)
To: Linus Walleij; +Cc: Nikita Travkin, linux-input
In-Reply-To: <20240830-zinitix-tk-versions-v2-1-90eae6817eda@linaro.org>
Hi Linus,
On Fri, Aug 30, 2024 at 04:04:27PM +0200, Linus Walleij wrote:
> The chip hardware revision, firmware version and regdata
> revision is needed to discern because for example touchkeys
> are handled by different registers on different versions of
> the chip. Example output from BT404:
>
> Zinitix-TS 3-0020: chip revision 4040 firmware version 0088
> regdata version 0004
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Move read status into the per-device struct.
Thanks for making this change.
> ---
> drivers/input/touchscreen/zinitix.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
> index 1df93c96f6bf..e47e0bff80db 100644
> --- a/drivers/input/touchscreen/zinitix.c
> +++ b/drivers/input/touchscreen/zinitix.c
> @@ -150,6 +150,10 @@ struct bt541_ts_data {
> u32 zinitix_mode;
> u32 keycodes[MAX_SUPPORTED_BUTTON_NUM];
> int num_keycodes;
> + bool read_versioninfo;
I renamed this to "have_versioninfo" and applied.
Thanks.
--
Dmitry
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 81bdc7eab99404ad657a8bc3ee02b95fbfbb7154
From: kernel test robot @ 2024-08-31 21:17 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: 81bdc7eab99404ad657a8bc3ee02b95fbfbb7154 dt-bindings: input: touchscreen: Use generic node name
elapsed time: 1343m
configs tested: 171
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc defconfig gcc-14.1.0
arc randconfig-001-20240831 gcc-14.1.0
arc randconfig-002-20240831 gcc-14.1.0
arm allmodconfig clang-20
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm defconfig gcc-14.1.0
arm ep93xx_defconfig clang-20
arm randconfig-001-20240831 gcc-14.1.0
arm randconfig-002-20240831 gcc-14.1.0
arm randconfig-003-20240831 gcc-14.1.0
arm randconfig-004-20240831 gcc-14.1.0
arm realview_defconfig clang-20
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig clang-20
arm64 defconfig gcc-14.1.0
arm64 randconfig-001-20240831 gcc-14.1.0
arm64 randconfig-002-20240831 gcc-14.1.0
arm64 randconfig-003-20240831 gcc-14.1.0
arm64 randconfig-004-20240831 gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
csky randconfig-001-20240831 gcc-14.1.0
csky randconfig-002-20240831 gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
hexagon randconfig-001-20240831 gcc-14.1.0
hexagon randconfig-002-20240831 gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240831 clang-18
i386 buildonly-randconfig-002-20240831 clang-18
i386 buildonly-randconfig-003-20240831 clang-18
i386 buildonly-randconfig-004-20240831 clang-18
i386 buildonly-randconfig-005-20240831 clang-18
i386 buildonly-randconfig-006-20240831 clang-18
i386 defconfig clang-18
i386 randconfig-001-20240831 clang-18
i386 randconfig-002-20240831 clang-18
i386 randconfig-003-20240831 clang-18
i386 randconfig-004-20240831 clang-18
i386 randconfig-005-20240831 clang-18
i386 randconfig-006-20240831 clang-18
i386 randconfig-011-20240831 clang-18
i386 randconfig-012-20240831 clang-18
i386 randconfig-013-20240831 clang-18
i386 randconfig-014-20240831 clang-18
i386 randconfig-015-20240831 clang-18
i386 randconfig-016-20240831 clang-18
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
loongarch randconfig-001-20240831 gcc-14.1.0
loongarch randconfig-002-20240831 gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k amiga_defconfig clang-20
m68k defconfig gcc-14.1.0
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips gpr_defconfig clang-20
mips malta_kvm_defconfig clang-20
mips rt305x_defconfig clang-20
nios2 alldefconfig clang-20
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
nios2 randconfig-001-20240831 gcc-14.1.0
nios2 randconfig-002-20240831 gcc-14.1.0
openrisc allnoconfig clang-20
openrisc allyesconfig gcc-14.1.0
openrisc defconfig gcc-12
openrisc or1klitex_defconfig clang-20
parisc allmodconfig gcc-14.1.0
parisc allnoconfig clang-20
parisc allyesconfig gcc-14.1.0
parisc defconfig gcc-12
parisc generic-64bit_defconfig clang-20
parisc randconfig-001-20240831 gcc-14.1.0
parisc randconfig-002-20240831 gcc-14.1.0
parisc64 defconfig gcc-14.1.0
powerpc adder875_defconfig clang-20
powerpc allmodconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc allyesconfig gcc-14.1.0
powerpc gamecube_defconfig clang-20
powerpc maple_defconfig clang-20
powerpc mpc834x_itx_defconfig clang-20
powerpc randconfig-001-20240831 gcc-14.1.0
powerpc64 randconfig-001-20240831 gcc-14.1.0
powerpc64 randconfig-002-20240831 gcc-14.1.0
powerpc64 randconfig-003-20240831 gcc-14.1.0
riscv allmodconfig gcc-14.1.0
riscv allnoconfig clang-20
riscv allyesconfig gcc-14.1.0
riscv defconfig gcc-12
riscv nommu_k210_defconfig clang-20
riscv randconfig-001-20240831 gcc-14.1.0
riscv randconfig-002-20240831 gcc-14.1.0
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
s390 randconfig-001-20240831 gcc-14.1.0
s390 randconfig-002-20240831 gcc-14.1.0
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh randconfig-001-20240831 gcc-14.1.0
sh randconfig-002-20240831 gcc-14.1.0
sh se7780_defconfig clang-20
sh secureedge5410_defconfig clang-20
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
sparc64 randconfig-001-20240831 gcc-14.1.0
sparc64 randconfig-002-20240831 gcc-14.1.0
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig gcc-12
um randconfig-001-20240831 gcc-14.1.0
um randconfig-002-20240831 gcc-14.1.0
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240831 clang-18
x86_64 buildonly-randconfig-002-20240831 clang-18
x86_64 buildonly-randconfig-003-20240831 clang-18
x86_64 buildonly-randconfig-004-20240831 clang-18
x86_64 buildonly-randconfig-005-20240831 clang-18
x86_64 buildonly-randconfig-006-20240831 clang-18
x86_64 defconfig clang-18
x86_64 kexec gcc-12
x86_64 randconfig-001-20240831 clang-18
x86_64 randconfig-002-20240831 clang-18
x86_64 randconfig-003-20240831 clang-18
x86_64 randconfig-004-20240831 clang-18
x86_64 randconfig-005-20240831 clang-18
x86_64 randconfig-006-20240831 clang-18
x86_64 randconfig-011-20240831 clang-18
x86_64 randconfig-012-20240831 clang-18
x86_64 randconfig-013-20240831 clang-18
x86_64 randconfig-014-20240831 clang-18
x86_64 randconfig-015-20240831 clang-18
x86_64 randconfig-016-20240831 clang-18
x86_64 randconfig-071-20240831 clang-18
x86_64 randconfig-072-20240831 clang-18
x86_64 randconfig-073-20240831 clang-18
x86_64 randconfig-074-20240831 clang-18
x86_64 randconfig-075-20240831 clang-18
x86_64 randconfig-076-20240831 clang-18
x86_64 rhel-8.3-rust clang-18
x86_64 rhel-8.3 gcc-12
xtensa allnoconfig gcc-14.1.0
xtensa randconfig-001-20240831 gcc-14.1.0
xtensa randconfig-002-20240831 gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v5 0/10] Touch Bar support for T2 Macs
From: Aditya Garg @ 2024-08-31 12:37 UTC (permalink / raw)
To: tzimmermann@suse.de, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, airlied@gmail.com, daniel@ffwll.ch,
Jiri Kosina, bentiss@kernel.org, Thomas Weißschuh
Cc: Orlando Chamberlain, Kerem Karabay, Linux Kernel Mailing List,
linux-input@vger.kernel.org, dri-devel@lists.freedesktop.org,
torvalds@linux-foundation.org
In-Reply-To: <DD9C41AD-6543-47CE-8504-69E4992229B2@live.com>
Hi Maintainers
It has been 2 weeks but I still haven't received a single reply on this version of the patch series. Consider this email as a friendly reminder.
> On 17 Aug 2024, at 5:15 PM, Aditya Garg <gargaditya08@live.com> wrote:
>
> Hi Maintainers
>
> The Touch Bars found on x86 Macs support two USB configurations: one
> where the device presents itself as a HID keyboard and can display
> predefined sets of keys, and one where the operating system has full
> control over what is displayed.
>
> This patch series adds support for both the configurations.
>
> The hid-appletb-bl driver adds support for the backlight of the Touch Bar.
> This enables the user to control the brightness of the Touch Bar from
> userspace. The Touch Bar supports 3 modes here: Max brightness, Dim and Off.
> So, daemons, used to manage Touch Bar can easily manage these modes by writing
> to /sys/class/backlight/appletb_backlight/brightness. It is needed by both the
> configurations of the Touch Bar.
>
> The hid-appletb-kbd adds support for the first (predefined keys) configuration.
> There are 4 modes here: Esc key only, Fn mode, Media keys and No keys.
> Mode can be changed by writing to /sys/bus/hid/drivers/hid-appletb-kbd/<dev>/mode
> This configuration is what Windows uses with the official Apple Bootcamp drivers.
>
> Rest patches support the second configuration, where the OS has full control
> on what's displayed on the Touch Bar. It is achieved by the patching the
> hid-multitouch driver to add support for touch feedback from the Touch Bar
> and the appletbdrm driver, that displays what we want to on the Touch Bar.
> This configuration is what macOS uses.
>
> The appletbdrm driver is based on the similar driver made for Windows by
> imbushuo [1].
>
> Currently, a daemon named tiny-dfr [2] is being used to display function keys
> and media controls using the second configuration for both Apple Silicon and
> T2 Macs.
>
> A daemon for the first configuration is being developed, but that's a userspace
> thing.
>
> [1]: https://github.com/imbushuo/DFRDisplayKm
> [2]: https://github.com/WhatAmISupposedToPutHere/tiny-dfr
>
> v2:
> 1. Cleaned up some code in the hid-appletb-kbd driver.
> 2. Fixed wrong subject in drm/format-helper patch.
> 3. Fixed Co-developed-by wrongly added to hid-multitouch patch.
>
> v3:
> 1. Fixed key mapping for Function keys in hid-appletb-kbd driver.
>
> v4:
> 1. Added support for fn key toggle in the hid-appletb-kbd driver.
>
> v5:
> 1. Do required changes to hid-appletb-bl as requested by upstream.
>
> Aditya Garg (1):
> HID: hid-appletb-kbd: add support for fn toggle between media and
> function mode
>
> Kerem Karabay (9):
> HID: hid-appletb-bl: add driver for the backlight of Apple Touch Bars
> HID: hid-appletb-kbd: add driver for the keyboard mode of Apple Touch
> Bars
> HID: multitouch: support getting the contact ID from
> HID_DG_TRANSDUCER_INDEX fields
> HID: multitouch: support getting the tip state from HID_DG_TOUCH
> fields
> HID: multitouch: take cls->maxcontacts into account for devices
> without a HID_DG_CONTACTMAX field too
> HID: multitouch: allow specifying if a device is direct in a class
> HID: multitouch: add device ID for Apple Touch Bars
> drm/format-helper: Add conversion from XRGB8888 to BGR888 conversion
> drm/tiny: add driver for Apple Touch Bars in x86 Macs
>
> .../ABI/testing/sysfs-driver-hid-appletb-kbd | 13 +
> MAINTAINERS | 6 +
> drivers/gpu/drm/drm_format_helper.c | 54 ++
> .../gpu/drm/tests/drm_format_helper_test.c | 81 +++
> drivers/gpu/drm/tiny/Kconfig | 12 +
> drivers/gpu/drm/tiny/Makefile | 1 +
> drivers/gpu/drm/tiny/appletbdrm.c | 624 ++++++++++++++++++
> drivers/hid/Kconfig | 22 +
> drivers/hid/Makefile | 2 +
> drivers/hid/hid-appletb-bl.c | 207 ++++++
> drivers/hid/hid-appletb-kbd.c | 432 ++++++++++++
> drivers/hid/hid-multitouch.c | 60 +-
> drivers/hid/hid-quirks.c | 8 +-
> include/drm/drm_format_helper.h | 3 +
> 14 files changed, 1509 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd
> create mode 100644 drivers/gpu/drm/tiny/appletbdrm.c
> create mode 100644 drivers/hid/hid-appletb-bl.c
> create mode 100644 drivers/hid/hid-appletb-kbd.c
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [git pull] Input updates for v6.11-rc5
From: pr-tracker-bot @ 2024-08-31 4:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <ZtI7F8X59jgrGp_7@google.com>
The pull request you sent on Fri, 30 Aug 2024 14:35:19 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.11-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1934261d897467a924e2afd1181a74c1cbfa2c1d
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v26 19/33] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp
From: Wesley Cheng @ 2024-08-31 2:11 UTC (permalink / raw)
To: Pierre-Louis Bossart, srinivas.kandagatla, mathias.nyman, perex,
conor+dt, dmitry.torokhov, corbet, broonie, lgirdwood, tiwai,
krzk+dt, Thinh.Nguyen, bgoswami, robh, gregkh
Cc: linux-kernel, devicetree, linux-sound, linux-input, linux-usb,
linux-arm-msm, linux-doc, alsa-devel
In-Reply-To: <ae0ae5f0-a3e9-49b4-95ba-524975d70659@linux.intel.com>
On 8/30/2024 2:12 AM, Pierre-Louis Bossart wrote:
>
> On 8/29/24 21:40, Wesley Cheng wrote:
>> The QC ADSP is able to support USB playback endpoints, so that the main
>> application processor can be placed into lower CPU power modes. This adds
>> the required AFE port configurations and port start command to start an
>> audio session.
>>
>> Specifically, the QC ADSP can support all potential endpoints that are
>> exposed by the audio data interface. This includes, feedback endpoints
>> (both implicit and explicit) as well as the isochronous (data) endpoints.
> I think you meant
>
> "
> this includes isochronous data endpoints, in either synchronous mode or
> asynchronous mode. In the latter case both implicit or explicit feedback
> endpoints are supported.
> "
>
> And now I don't remember how *controls* are handled.
>
> Is this the case that all controls exposed by endpoint zero are visible
> in both the regular USB-audio card AND the offloaded card, with changes
> mirrored?
I think we had a discussion about this previously, but can't seem to find it. The USB volume controls (ie controls still handled by the control EP) are going to still reside only within the USB SND card. As of now, there aren't any kcontrols that are being added to the ASoC platform card for offload.
> It's important to explain so that the volumes are consistent no matter
> which path is used. This should be added to the documentation.
>
>
>> +static const struct snd_soc_dai_ops q6afe_usb_ops = {
>> + .probe = msm_dai_q6_dai_probe,
>> + .prepare = q6afe_dai_prepare,
>> + .hw_params = q6afe_usb_hw_params,
>> + /*
>> + * Shutdown callback required to stop the USB AFE port, which is enabled
>> + * by the prepare() stage. This stops the audio traffic on the USB AFE
>> + * port on the Q6DSP.
>> + */
>> + .shutdown = q6afe_dai_shutdown,
>> + /*
>> + * Startup callback not needed, as AFE port start command passes the PCM
>> + * parameters within the AFE command, which is provided by the PCM core
>> + * during the prepare() stage.
>> + */
> Humm, now this is a bit confusing. Why would you need a shutdown, can't
> you use the hw_free() callback for symmetry with prepare()?
I thought that it was hw_params() -- hw_free() and prepare() -- shutdown()?
"DPCM runs the PCM trigger(stop), hw_free(), shutdown() operations on DAI0 for headset since the path is now disabled.
DPCM runs the PCM ops for startup(), hw_params(), prepare() and trigger(start) for DAI1 Speakers since the path is enabled."
https://www.kernel.org/doc/html/v6.10/sound/soc/dpcm.html
Thanks
Wesley Cheng
>
^ permalink raw reply
* Re: [PATCH v26 16/33] ASoC: doc: Add documentation for SOC USB
From: Wesley Cheng @ 2024-08-31 1:49 UTC (permalink / raw)
To: Pierre-Louis Bossart, srinivas.kandagatla, mathias.nyman, perex,
conor+dt, dmitry.torokhov, corbet, broonie, lgirdwood, tiwai,
krzk+dt, Thinh.Nguyen, bgoswami, robh, gregkh
Cc: linux-kernel, devicetree, linux-sound, linux-input, linux-usb,
linux-arm-msm, linux-doc, alsa-devel
In-Reply-To: <522dd841-2060-4e7c-b8ce-7e9ea2fa8498@linux.intel.com>
On 8/30/2024 2:03 AM, Pierre-Louis Bossart wrote:
>> diff --git a/Documentation/sound/soc/index.rst b/Documentation/sound/soc/index.rst
>> index e57df2dab2fd..8bed8f8f48da 100644
>> --- a/Documentation/sound/soc/index.rst
>> +++ b/Documentation/sound/soc/index.rst
>> @@ -18,3 +18,4 @@ The documentation is spilt into the following sections:-
>> jack
>> dpcm
>> codec-to-codec
>> + usb
>> diff --git a/Documentation/sound/soc/usb.rst b/Documentation/sound/soc/usb.rst
>> new file mode 100644
>> index 000000000000..bd3d9eb86b07
>> --- /dev/null
>> +++ b/Documentation/sound/soc/usb.rst
>> @@ -0,0 +1,429 @@
>> +================
>> +ASoC USB support
>> +================
>> +
>> +Overview
>> +========
>> +In order to leverage the existing USB sound device support in ALSA, the
>> +ASoC USB APIs are introduced to allow for the entities to communicate
>> +with one another.
> nit-pick: entities is rather vague and an overloaded term in USB audio.
> Maybe "allow the subsystems to exchange configuration information"
Sure, will make that change.
>> +One potential use case would be to support USB audio offloading, which is
>> +an implementation that allows for an external DSP on the SoC to handle the
> nit-pick: not sure about the reference to an 'external DSP'. "external"
> would usually to a stand-alone device and there's no real need for DSP
> capabilities for USB offload, e.g. a regular embedded core would do just
> fine.
>
> maybe "allows for an alternate power-optimized path in the audio
> subsystem to handle the transfer of audio data over the USB bus"
Yeah, I guess external doesn't make sense, its just another core within the SoC.
>> +transfer of audio data over the USB bus. This would let the main
>> +processor to stay in lower power modes for longer duration. The following
>> +is an example design of how the ASoC and ALSA pieces can be connected
>> +together to achieve this:
>> + int snd_soc_usb_update_offload_route(struct device *dev, int card, int pcm,
>> + int direction, long *route)
>> +..
>> +
>> + - ``dev``: USB device to look up offload path mapping
>> + - ``card``: USB sound card index
>> + - ``pcm``: USB sound PCM device index
>> + - ``direction``: direction to fetch offload routing information
>> + - ``route``: mapping of sound card and pcm indexes for the offload path
> nit-pick: again explain how the card and pcm indices are handled.
>
Will do.
>> +--------------------------------
>> +USB devices can be hotplugged into the USB root hub at any point in time.
> "root hub" really?
>
> Is this really required? I would think the entire framework would work
> just fine if the device is connected to any hub at any level, not just
> "the" root hub.
Yes, you're right. Will clarify this as well. My test set up for this involves doing audio transfers on multiple devices over an external 4port USB hub.
Thanks
Wesley Cheng
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: input: touchscreen: Use generic node name
From: Dmitry Torokhov @ 2024-08-30 22:50 UTC (permalink / raw)
To: Fabio Estevam
Cc: robh, krzk+dt, conor+dt, linux-input, devicetree, Fabio Estevam,
Conor Dooley
In-Reply-To: <20240830194331.3774408-1-festevam@gmail.com>
On Fri, Aug 30, 2024 at 04:43:31PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Node names should be generic.
>
> Improve the binding example by using 'touchscreen' as the node name.
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [git pull] Input updates for v6.11-rc5
From: Dmitry Torokhov @ 2024-08-30 21:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.11-rc5
to receive updates for the input subsystem. You will get:
- a fix for Cypress PS/2 touchpad for regression introduced in 6.11
merge window where timeout condition is incorrectly reported for
all extended Cypress commands.
Changelog:
---------
Dmitry Torokhov (1):
Input: cypress_ps2 - fix waiting for command response
Diffstat:
--------
drivers/input/mouse/cypress_ps2.c | 58 +++++++++------------------------------
1 file changed, 13 insertions(+), 45 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS c472d33bcbf7a1ed3710efe93822b5e94eabe18c
From: kernel test robot @ 2024-08-30 20:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: c472d33bcbf7a1ed3710efe93822b5e94eabe18c Input: cypress_ps2 - fix waiting for command response
elapsed time: 1585m
configs tested: 167
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-14.1.0
alpha allyesconfig clang-20
alpha defconfig gcc-14.1.0
arc allmodconfig clang-20
arc allmodconfig gcc-13.2.0
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc allyesconfig gcc-13.2.0
arc defconfig gcc-14.1.0
arc randconfig-001-20240830 gcc-14.1.0
arc randconfig-002-20240830 gcc-14.1.0
arm allmodconfig clang-20
arm allmodconfig gcc-13.2.0
arm allnoconfig gcc-14.1.0
arm allyesconfig clang-20
arm allyesconfig gcc-13.2.0
arm defconfig gcc-14.1.0
arm multi_v5_defconfig gcc-14.1.0
arm omap2plus_defconfig gcc-14.1.0
arm qcom_defconfig gcc-14.1.0
arm randconfig-001-20240830 gcc-14.1.0
arm randconfig-002-20240830 gcc-14.1.0
arm randconfig-003-20240830 gcc-14.1.0
arm randconfig-004-20240830 gcc-14.1.0
arm64 allmodconfig clang-20
arm64 allnoconfig gcc-14.1.0
arm64 defconfig gcc-14.1.0
arm64 randconfig-001-20240830 gcc-14.1.0
arm64 randconfig-002-20240830 gcc-14.1.0
arm64 randconfig-003-20240830 gcc-14.1.0
arm64 randconfig-004-20240830 gcc-14.1.0
csky allnoconfig gcc-14.1.0
csky defconfig gcc-14.1.0
csky randconfig-001-20240830 gcc-14.1.0
csky randconfig-002-20240830 gcc-14.1.0
hexagon allmodconfig clang-20
hexagon allnoconfig gcc-14.1.0
hexagon allyesconfig clang-20
hexagon defconfig gcc-14.1.0
hexagon randconfig-001-20240830 gcc-14.1.0
hexagon randconfig-002-20240830 gcc-14.1.0
i386 allmodconfig clang-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240830 gcc-12
i386 buildonly-randconfig-002-20240830 gcc-12
i386 buildonly-randconfig-003-20240830 gcc-12
i386 buildonly-randconfig-004-20240830 gcc-12
i386 buildonly-randconfig-005-20240830 gcc-12
i386 buildonly-randconfig-006-20240830 gcc-12
i386 defconfig clang-18
i386 randconfig-001-20240830 gcc-12
i386 randconfig-002-20240830 gcc-12
i386 randconfig-003-20240830 gcc-12
i386 randconfig-004-20240830 gcc-12
i386 randconfig-005-20240830 gcc-12
i386 randconfig-006-20240830 gcc-12
i386 randconfig-011-20240830 gcc-12
i386 randconfig-012-20240830 gcc-12
i386 randconfig-013-20240830 gcc-12
i386 randconfig-014-20240830 gcc-12
i386 randconfig-015-20240830 gcc-12
i386 randconfig-016-20240830 gcc-12
loongarch allmodconfig gcc-14.1.0
loongarch allnoconfig gcc-14.1.0
loongarch defconfig gcc-14.1.0
loongarch randconfig-001-20240830 gcc-14.1.0
loongarch randconfig-002-20240830 gcc-14.1.0
m68k allmodconfig gcc-14.1.0
m68k allnoconfig gcc-14.1.0
m68k allyesconfig gcc-14.1.0
m68k defconfig gcc-14.1.0
m68k m5275evb_defconfig gcc-14.1.0
m68k virt_defconfig gcc-14.1.0
microblaze allmodconfig gcc-14.1.0
microblaze allnoconfig gcc-14.1.0
microblaze allyesconfig gcc-14.1.0
microblaze defconfig gcc-14.1.0
mips allnoconfig gcc-14.1.0
mips jazz_defconfig gcc-14.1.0
mips loongson2k_defconfig gcc-14.1.0
nios2 allnoconfig gcc-14.1.0
nios2 defconfig gcc-14.1.0
nios2 randconfig-001-20240830 gcc-14.1.0
nios2 randconfig-002-20240830 gcc-14.1.0
openrisc alldefconfig gcc-14.1.0
openrisc allnoconfig clang-20
openrisc defconfig gcc-12
parisc allnoconfig clang-20
parisc defconfig gcc-12
parisc randconfig-001-20240830 gcc-14.1.0
parisc randconfig-002-20240830 gcc-14.1.0
parisc64 defconfig gcc-14.1.0
powerpc allnoconfig clang-20
powerpc cell_defconfig gcc-14.1.0
powerpc ep88xc_defconfig gcc-14.1.0
powerpc ps3_defconfig gcc-14.1.0
powerpc randconfig-001-20240830 gcc-14.1.0
powerpc randconfig-002-20240830 gcc-14.1.0
powerpc64 randconfig-001-20240830 gcc-14.1.0
powerpc64 randconfig-002-20240830 gcc-14.1.0
powerpc64 randconfig-003-20240830 gcc-14.1.0
riscv allnoconfig clang-20
riscv defconfig gcc-12
riscv randconfig-001-20240830 gcc-14.1.0
riscv randconfig-002-20240830 gcc-14.1.0
s390 allmodconfig gcc-14.1.0
s390 allnoconfig clang-20
s390 allyesconfig gcc-14.1.0
s390 defconfig gcc-12
s390 randconfig-001-20240830 gcc-14.1.0
s390 randconfig-002-20240830 gcc-14.1.0
sh allmodconfig gcc-14.1.0
sh allnoconfig gcc-14.1.0
sh allyesconfig gcc-14.1.0
sh defconfig gcc-12
sh landisk_defconfig gcc-14.1.0
sh randconfig-001-20240830 gcc-14.1.0
sh randconfig-002-20240830 gcc-14.1.0
sh rsk7269_defconfig gcc-14.1.0
sh se7722_defconfig gcc-14.1.0
sh sh03_defconfig gcc-14.1.0
sh urquell_defconfig gcc-14.1.0
sparc allmodconfig gcc-14.1.0
sparc64 defconfig gcc-12
sparc64 randconfig-001-20240830 gcc-14.1.0
sparc64 randconfig-002-20240830 gcc-14.1.0
um allmodconfig clang-20
um allnoconfig clang-20
um allyesconfig clang-20
um defconfig gcc-12
um i386_defconfig gcc-12
um randconfig-001-20240830 gcc-14.1.0
um randconfig-002-20240830 gcc-14.1.0
um x86_64_defconfig gcc-12
x86_64 allnoconfig clang-18
x86_64 allyesconfig clang-18
x86_64 buildonly-randconfig-001-20240830 clang-18
x86_64 buildonly-randconfig-002-20240830 clang-18
x86_64 buildonly-randconfig-003-20240830 clang-18
x86_64 buildonly-randconfig-004-20240830 clang-18
x86_64 buildonly-randconfig-005-20240830 clang-18
x86_64 buildonly-randconfig-006-20240830 clang-18
x86_64 defconfig clang-18
x86_64 randconfig-001-20240830 clang-18
x86_64 randconfig-002-20240830 clang-18
x86_64 randconfig-003-20240830 clang-18
x86_64 randconfig-004-20240830 clang-18
x86_64 randconfig-005-20240830 clang-18
x86_64 randconfig-006-20240830 clang-18
x86_64 randconfig-011-20240830 clang-18
x86_64 randconfig-012-20240830 clang-18
x86_64 randconfig-013-20240830 clang-18
x86_64 randconfig-014-20240830 clang-18
x86_64 randconfig-015-20240830 clang-18
x86_64 randconfig-016-20240830 clang-18
x86_64 randconfig-071-20240830 clang-18
x86_64 randconfig-072-20240830 clang-18
x86_64 randconfig-073-20240830 clang-18
x86_64 randconfig-074-20240830 clang-18
x86_64 randconfig-075-20240830 clang-18
x86_64 randconfig-076-20240830 clang-18
x86_64 rhel-8.3-rust clang-18
xtensa allnoconfig gcc-14.1.0
xtensa common_defconfig gcc-14.1.0
xtensa randconfig-001-20240830 gcc-14.1.0
xtensa randconfig-002-20240830 gcc-14.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] dt-bindings: input: touchscreen: Use generic node name
From: Fabio Estevam @ 2024-08-30 19:43 UTC (permalink / raw)
To: dmitry.torokhov
Cc: robh, krzk+dt, conor+dt, linux-input, devicetree, Fabio Estevam,
Conor Dooley
From: Fabio Estevam <festevam@denx.de>
Node names should be generic.
Improve the binding example by using 'touchscreen' as the node name.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes since v1:
- Squash the patches. (Rob)
.../devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml | 4 ++--
.../devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
.../devicetree/bindings/input/touchscreen/goodix.yaml | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml
index 8cf371b99f19..e4dbbafb3779 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml
@@ -666,7 +666,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- touch@56 {
+ touchscreen@56 {
compatible = "azoteq,iqs7210a";
reg = <0x56>;
irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
@@ -704,7 +704,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- touch@56 {
+ touchscreen@56 {
compatible = "azoteq,iqs7211e";
reg = <0x56>;
irq-gpios = <&gpio 4 (GPIO_ACTIVE_LOW |
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
index 51d48d4130d3..70a922e213f2 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -126,7 +126,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
- edt-ft5x06@38 {
+ touchscreen@38 {
compatible = "edt,edt-ft5406";
reg = <0x38>;
interrupt-parent = <&gpio2>;
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
index 2a2d86cfd104..eb4992f708b7 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
@@ -69,7 +69,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
- gt928@5d {
+ touchscreen@5d {
compatible = "goodix,gt928";
reg = <0x5d>;
interrupt-parent = <&gpio>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: Use generic node name
From: Rob Herring (Arm) @ 2024-08-30 16:18 UTC (permalink / raw)
To: Fabio Estevam
Cc: krzk+dt, linux-input, dmitry.torokhov, Fabio Estevam, devicetree,
conor+dt
In-Reply-To: <20240829134428.3347075-1-festevam@gmail.com>
On Thu, 29 Aug 2024 10:44:28 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Node names should be generic.
>
> Improve the binding example by using 'touchscreen' as the node name.
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> .../devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Could be squashed with the others...
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: input: touchscreen: goodix: Use generic node name
From: Rob Herring @ 2024-08-30 15:39 UTC (permalink / raw)
To: Fabio Estevam
Cc: dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree,
Fabio Estevam
In-Reply-To: <20240829183051.3392443-2-festevam@gmail.com>
On Thu, Aug 29, 2024 at 03:30:51PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
Why 2 different subjects for the same change?
Really, both of these go to the same maintainer, so they can be 1 patch.
>
> Node names should be generic.
>
> Improve the binding example by using 'touchscreen' as the node name.
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Documentation/devicetree/bindings/input/touchscreen/goodix.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> index 2a2d86cfd104..eb4992f708b7 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> @@ -69,7 +69,7 @@ examples:
> i2c {
> #address-cells = <1>;
> #size-cells = <0>;
> - gt928@5d {
> + touchscreen@5d {
> compatible = "goodix,gt928";
> reg = <0x5d>;
> interrupt-parent = <&gpio>;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: touchscreen: ad7877: add bindings
From: Conor Dooley @ 2024-08-30 14:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Antoniu Miclaus, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Hennerich, linux-input, devicetree, linux-kernel
In-Reply-To: <ZtC48cOrWPG5SdiS@google.com>
[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]
On Thu, Aug 29, 2024 at 11:07:45AM -0700, Dmitry Torokhov wrote:
> On Thu, Aug 29, 2024 at 05:16:30PM +0100, Conor Dooley wrote:
> > On Thu, Aug 29, 2024 at 12:19:36PM +0300, Antoniu Miclaus wrote:
> > > Add device tree bindings for the ad7877 driver.
> > >
> > > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
> > > ---
> > > .../input/touchscreen/adi,ad7877.yaml | 58 +++++++++++++++++++
> > > 1 file changed, 58 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/adi,ad7877.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/adi,ad7877.yaml b/Documentation/devicetree/bindings/input/touchscreen/adi,ad7877.yaml
> > > new file mode 100644
> > > index 000000000000..5fc5124c5999
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/adi,ad7877.yaml
> > > @@ -0,0 +1,58 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/touchscreen/adi,ad7877.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Analog Devices AD7877 Touch Screen Controller
> > > +
> > > +maintainers:
> > > + - Antoniu Miclaus <antoniu.miclaus@analog.com>
> > > +
> > > +description: |
> > > + Analog Devices Touch Screen Controller
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7877.pdf
> > > +
> > > +allOf:
> > > + - $ref: touchscreen.yaml#
> > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> >
> > > +
> > > +unevaluatedProperties: false
> >
> > So, all of the properties in those two files are valid for this
> > touchscreen controller?
>
> No, the driver does not support transformations (swapping axes,
> inverting, etc) but that is driver limitation, not property of the
> hardware, which DT supposed to be, right?
Yeah, I'm only interested in whether or not the properties are actually
applicable to the hardware. In particular, if there are properties in
spi-peripheral-props required for functionality (eg active high cs) I
would like to see them required.
>
> Still I think we need to extend the driver to do that before adding DT
> match tables and adding DT bindings (or maybe together with it).
>
> The driver also need to have proper GPIO controller support instead of
> having ad-hoc sysfs attributes, and converting in now before there are
> mainline users would be a good time.
Do you mean that this device is a provider of GPIOs? If so, then
absolutely I would want to see gpio controller properties in the binding
here before adding support.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: input: touchscreen: goodix: Use generic node name
From: Conor Dooley @ 2024-08-30 14:19 UTC (permalink / raw)
To: Fabio Estevam
Cc: dmitry.torokhov, robh, krzk+dt, conor+dt, linux-input, devicetree,
Fabio Estevam
In-Reply-To: <20240829183051.3392443-2-festevam@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
On Thu, Aug 29, 2024 at 03:30:51PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Node names should be generic.
>
> Improve the binding example by using 'touchscreen' as the node name.
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: touchscreen: iqs7211: Use 'touchscreen' as node name
From: Conor Dooley @ 2024-08-30 14:18 UTC (permalink / raw)
To: Fabio Estevam
Cc: dmitry.torokhov, robh, krzk+dt, conor+dt, linux-input, devicetree,
Fabio Estevam
In-Reply-To: <20240829183051.3392443-1-festevam@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Thu, Aug 29, 2024 at 03:30:50PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> 'touchscreen' is the recommended node name, not 'touch'.
>
> Fix it accordingly.
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
Ultimately I feel acking this is pointless given how trivial it is, I
wouldn't want a trivial patch held up by the lack of one.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 2/2] Input: zinitix - Varying icon status registers
From: Linus Walleij @ 2024-08-30 14:04 UTC (permalink / raw)
To: Dmitry Torokhov, Nikita Travkin; +Cc: linux-input, Linus Walleij
In-Reply-To: <20240830-zinitix-tk-versions-v2-0-90eae6817eda@linaro.org>
The different revisions of the Zinitix BTXXX touchscreens place
the icon status register (to read out touchkey status) in
different places. Use the chip revision bits to discern
between the different versions at runtime.
This makes touchkeys work on the BT404 on the Samsung Codina
GT-I8160 mobile phone.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- No changes
---
drivers/input/touchscreen/zinitix.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
index e47e0bff80db..b6b380f5aed5 100644
--- a/drivers/input/touchscreen/zinitix.c
+++ b/drivers/input/touchscreen/zinitix.c
@@ -35,7 +35,13 @@
#define ZINITIX_DEBUG_REG 0x0115 /* 0~7 */
#define ZINITIX_TOUCH_MODE 0x0010
+
#define ZINITIX_CHIP_REVISION 0x0011
+#define ZINITIX_CHIP_BTX0X_MASK 0xF0F0
+#define ZINITIX_CHIP_BT4X2 0x4020
+#define ZINITIX_CHIP_BT4X3 0x4030
+#define ZINITIX_CHIP_BT4X4 0x4040
+
#define ZINITIX_FIRMWARE_VERSION 0x0012
#define ZINITIX_USB_DETECT 0x116
@@ -63,7 +69,11 @@
#define ZINITIX_Y_RESOLUTION 0x00C1
#define ZINITIX_POINT_STATUS_REG 0x0080
-#define ZINITIX_ICON_STATUS_REG 0x00AA
+
+#define ZINITIX_BT4X2_ICON_STATUS_REG 0x009A
+#define ZINITIX_BT4X3_ICON_STATUS_REG 0x00A0
+#define ZINITIX_BT4X4_ICON_STATUS_REG 0x00A0
+#define ZINITIX_BT5XX_ICON_STATUS_REG 0x00AA
#define ZINITIX_POINT_COORD_REG (ZINITIX_POINT_STATUS_REG + 2)
@@ -425,7 +435,18 @@ static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
}
if (le16_to_cpu(touch_event.status) & BIT_ICON_EVENT) {
- error = zinitix_read_data(bt541->client, ZINITIX_ICON_STATUS_REG,
+ u16 iconstatus;
+
+ if ((bt541->chip_revision & ZINITIX_CHIP_BTX0X_MASK) == ZINITIX_CHIP_BT4X2)
+ iconstatus = ZINITIX_BT4X2_ICON_STATUS_REG;
+ else if ((bt541->chip_revision & ZINITIX_CHIP_BTX0X_MASK) == ZINITIX_CHIP_BT4X3)
+ iconstatus = ZINITIX_BT4X3_ICON_STATUS_REG;
+ else if ((bt541->chip_revision & ZINITIX_CHIP_BTX0X_MASK) == ZINITIX_CHIP_BT4X4)
+ iconstatus = ZINITIX_BT4X4_ICON_STATUS_REG;
+ else
+ iconstatus = ZINITIX_BT5XX_ICON_STATUS_REG;
+
+ error = zinitix_read_data(bt541->client, iconstatus,
&icon_events, sizeof(icon_events));
if (error) {
dev_err(&client->dev, "Failed to read icon events\n");
--
2.46.0
^ permalink raw reply related
* [PATCH v2 0/2] Input: zinitix - Handle chip revisions for touchkeys
From: Linus Walleij @ 2024-08-30 14:04 UTC (permalink / raw)
To: Dmitry Torokhov, Nikita Travkin; +Cc: linux-input, Linus Walleij
The registers containing the touchkey status varies between
different chip revisions for the Zinitix touchscreens.
This series address the problem by reading out some chip
revision and firmware data so we can take different runtime
paths in different chip versions.
Also read out firmware and register version as this may
prove helpful to similar situations in the future.
This applies on top of Nikitas series to handle touchkeys
that was recently merged.
After this my BT404 touchkeys work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v2:
- Move the variable keeping track of versioning info being
read into the per-device state.
- Link to v1: https://lore.kernel.org/r/20240806-zinitix-tk-versions-v1-0-63ef79c7f2a1@linaro.org
---
Linus Walleij (2):
Input: zinitix - Read and cache device version numbers
Input: zinitix - Varying icon status registers
drivers/input/touchscreen/zinitix.c | 59 +++++++++++++++++++++++++++++++++++--
1 file changed, 57 insertions(+), 2 deletions(-)
---
base-commit: 669e9cb5f59903fbb1649660f3cb04e5217a7e58
change-id: 20240806-zinitix-tk-versions-9b18b20ebaad
Best regards,
--
Linus Walleij <linus.walleij@linaro.org>
^ permalink raw reply
* [PATCH v2 1/2] Input: zinitix - Read and cache device version numbers
From: Linus Walleij @ 2024-08-30 14:04 UTC (permalink / raw)
To: Dmitry Torokhov, Nikita Travkin; +Cc: linux-input, Linus Walleij
In-Reply-To: <20240830-zinitix-tk-versions-v2-0-90eae6817eda@linaro.org>
The chip hardware revision, firmware version and regdata
revision is needed to discern because for example touchkeys
are handled by different registers on different versions of
the chip. Example output from BT404:
Zinitix-TS 3-0020: chip revision 4040 firmware version 0088
regdata version 0004
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Move read status into the per-device struct.
---
drivers/input/touchscreen/zinitix.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
index 1df93c96f6bf..e47e0bff80db 100644
--- a/drivers/input/touchscreen/zinitix.c
+++ b/drivers/input/touchscreen/zinitix.c
@@ -150,6 +150,10 @@ struct bt541_ts_data {
u32 zinitix_mode;
u32 keycodes[MAX_SUPPORTED_BUTTON_NUM];
int num_keycodes;
+ bool read_versioninfo;
+ u16 chip_revision;
+ u16 firmware_version;
+ u16 regdata_version;
};
static int zinitix_read_data(struct i2c_client *client,
@@ -194,6 +198,18 @@ static int zinitix_write_cmd(struct i2c_client *client, u16 reg)
return 0;
}
+static u16 zinitix_get_u16_reg(struct bt541_ts_data *bt541, u16 vreg)
+{
+ struct i2c_client *client = bt541->client;
+ int error;
+ __le16 val;
+
+ error = zinitix_read_data(client, vreg, (void *)&val, 2);
+ if (error)
+ return U8_MAX;
+ return le16_to_cpu(val);
+}
+
static int zinitix_init_touch(struct bt541_ts_data *bt541)
{
struct i2c_client *client = bt541->client;
@@ -207,6 +223,24 @@ static int zinitix_init_touch(struct bt541_ts_data *bt541)
return error;
}
+ /*
+ * Read and cache the chip revision and firmware version the first time
+ * we get here.
+ */
+ if (!bt541->read_versioninfo) {
+ bt541->chip_revision = zinitix_get_u16_reg(bt541,
+ ZINITIX_CHIP_REVISION);
+ bt541->firmware_version = zinitix_get_u16_reg(bt541,
+ ZINITIX_FIRMWARE_VERSION);
+ bt541->regdata_version = zinitix_get_u16_reg(bt541,
+ ZINITIX_DATA_VERSION_REG);
+ dev_dbg(&client->dev,
+ "chip revision %04x firmware version %04x regdata version %04x\n",
+ bt541->chip_revision, bt541->firmware_version,
+ bt541->regdata_version);
+ bt541->read_versioninfo = true;
+ }
+
error = zinitix_write_u16(client, ZINITIX_INT_ENABLE_FLAG, 0x0);
if (error) {
dev_err(&client->dev,
--
2.46.0
^ permalink raw reply related
* Lenovo Ideapad and hid-multitouch
From: Luigi Baldoni @ 2024-08-30 13:23 UTC (permalink / raw)
To: linux-input; +Cc: Benjamin Tissoires, Stephane Chatty
Hello everyone,
I've had a problem with the touchpad on my Lenovo Ideapad laptop since buying it, namely
it's way too sensitive and this results in fake clicks and jumpy behaviour overall.
Libinput people told me there's nothing they can do (https://gitlab.freedesktop.org/libinput/libinput/-/issues/946)
and referred me to this mailing list.
Do you see a potential margin of improvement here?
If there's any further test I could run or experimental drivers to try, please tell me.
Thanks
^ 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