* Re: [PATCH 1/2] Input: st1232 - read firmware version and revision
From: Dmitry Torokhov @ 2026-02-05 9:17 UTC (permalink / raw)
To: Michael Tretter; +Cc: linux-input, kernel, Khalid Talash
In-Reply-To: <20260123-input-st1232-firmware-version-v1-1-32df7eefdafe@pengutronix.de>
Hi Michael,
On Fri, Jan 23, 2026 at 05:28:55PM +0100, Michael Tretter wrote:
> +static int st1232_ts_read_fw_version(struct st1232_ts_data *ts,
> + u8 *fw_version, u32 *fw_revision)
> +{
> + int error;
> +
> + /* select firmware version register */
> + error = st1232_ts_read_data(ts, REG_FIRMWARE_VERSION, 1);
> + if (error)
> + return error;
> + *fw_version = ts->read_buf[0];
> +
> + /* select firmware revision register */
> + error = st1232_ts_read_data(ts, REG_FIRMWARE_REVISION_3, 4);
> + if (error)
> + return error;
> + *fw_revision = get_unaligned_le32(ts->read_buf);
Why unaligned? You are not reading at an offset and allocated memory is
cache line aligned.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: quirks: really enable the intended work around for appledisplay
From: René Rebe @ 2026-02-05 9:06 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, kernel-janitors,
linux-kernel, Lukas Bulwahn
In-Reply-To: <20260205081131.426899-1-lukas.bulwahn@redhat.com>
Hi,
> On 5. Feb 2026, at 09:11, Lukas Bulwahn <lbulwahn@redhat.com> wrote:
>
> From: Lukas Bulwahn <lukas.bulwahn@redhat.com>
>
> Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for
> appledisplay") intends to add a quirk for kernels built with Apple Cinema
> Display support, but it refers to the non-existing config option
> CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display
> support is named CONFIG_USB_APPLEDISPLAY.
>
> Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef
> directive.
>
> Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay")
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
> ---
>
> Note this fix suggests that the patch of commit c7fabe4ad921 in this form
> was never effectively tested, checking the effect that the commit message
> claims it would have.
Thanks for spotting this. It was tested when I did this years ago. Though, maybe I
tested before adding the #if IS_ENABLED, anciently hit some key in Vim, o
something was renamed since then.
Either way, I’ll get the display out of the basement and re-test it the coming days.
René
> drivers/hid/hid-quirks.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index 3217e436c052..b91e081ef69c 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -233,7 +233,7 @@ static const struct hid_device_id hid_quirks[] = {
> * used as a driver. See hid_scan_report().
> */
> static const struct hid_device_id hid_have_special_driver[] = {
> -#if IS_ENABLED(CONFIG_APPLEDISPLAY)
> +#if IS_ENABLED(CONFIG_USB_APPLEDISPLAY)
> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9218) },
> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9219) },
> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x921c) },
> --
> 2.52.0
>
--
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe
^ permalink raw reply
* [PATCH] HID: quirks: really enable the intended work around for appledisplay
From: Lukas Bulwahn @ 2026-02-05 8:11 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, René Rebe, linux-input
Cc: kernel-janitors, linux-kernel, Lukas Bulwahn
From: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for
appledisplay") intends to add a quirk for kernels built with Apple Cinema
Display support, but it refers to the non-existing config option
CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display
support is named CONFIG_USB_APPLEDISPLAY.
Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef
directive.
Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
---
Note this fix suggests that the patch of commit c7fabe4ad921 in this form
was never effectively tested, checking the effect that the commit message
claims it would have.
drivers/hid/hid-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3217e436c052..b91e081ef69c 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -233,7 +233,7 @@ static const struct hid_device_id hid_quirks[] = {
* used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
-#if IS_ENABLED(CONFIG_APPLEDISPLAY)
+#if IS_ENABLED(CONFIG_USB_APPLEDISPLAY)
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9218) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9219) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x921c) },
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2] HID: pidff: Fix condition effect bit clearing
From: Nathan Chancellor @ 2026-02-05 0:41 UTC (permalink / raw)
To: kernel test robot
Cc: Tomasz Pakuła, jikos, bentiss, llvm, oe-kbuild-all, oleg,
linux-input, linux-kernel
In-Reply-To: <202602050440.e5LEMod6-lkp@intel.com>
On Thu, Feb 05, 2026 at 05:07:56AM +0800, kernel test robot wrote:
> Hi Tomasz,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on hid/for-next]
> [also build test WARNING on linus/master v6.19-rc8 next-20260204]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Tomasz-Paku-a/HID-pidff-Fix-condition-effect-bit-clearing/20260204-213418
> base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
> patch link: https://lore.kernel.org/r/20260204133138.475880-1-tomasz.pakula.oficjalny%40gmail.com
> patch subject: [PATCH v2] HID: pidff: Fix condition effect bit clearing
> config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260205/202602050440.e5LEMod6-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260205/202602050440.e5LEMod6-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/202602050440.e5LEMod6-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> >> drivers/hid/usbhid/hid-pidff.c:1456:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
> 1456 | if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1457 | test_and_clear_bit(FF_DAMPER, dev->ffbit) |
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1458 | test_and_clear_bit(FF_FRICTION, dev->ffbit) |
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | ||
> 1459 | test_and_clear_bit(FF_INERTIA, dev->ffbit))
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/hid/usbhid/hid-pidff.c:1456:7: note: cast one or both operands to int to silence this warning
> >> drivers/hid/usbhid/hid-pidff.c:1456:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
> 1456 | if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1457 | test_and_clear_bit(FF_DAMPER, dev->ffbit) |
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | ||
> 1458 | test_and_clear_bit(FF_FRICTION, dev->ffbit) |
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/hid/usbhid/hid-pidff.c:1456:7: note: cast one or both operands to int to silence this warning
> >> drivers/hid/usbhid/hid-pidff.c:1456:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
> 1456 | if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | ||
> 1457 | test_and_clear_bit(FF_DAMPER, dev->ffbit) |
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/hid/usbhid/hid-pidff.c:1456:7: note: cast one or both operands to int to silence this warning
> 3 warnings generated.
As the use of the bitwise operation is intentional here per the comment,
I think going back to v1 to avoid introducing this warning would be
better than casting one of these operands to int to silence it with the
v2 structuring of the code. v1 matches what I have done elsewhere in the
kernel to make it obvious that each function should be called (without a
comment):
2e70570656ad ("drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()")
a02dcde595f7 ("Input: touchscreen - avoid bitwise vs logical OR warning")
Cheers,
Nathan
^ permalink raw reply
* RE: [PATCH v3] selftests: hid: tests: test_wacom_generic: add tests for display devices and opaque devices
From: Skomra, Erin @ 2026-02-04 23:42 UTC (permalink / raw)
To: Alex Tran, Jiri Kosina, Benjamin Tissoires, Shuah Khan
Cc: Cheng, Ping, Gerecke, Jason, Erin Skomra,
linux-input@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260131-wacom_selftests_display_opaque_dev_tests-v3-1-0857d734ba4b@gmail.com>
Tested by Erin Skomra <erin.skomra@wacom.com>
Reviewed-by Erin Skomra <erin.skomra@wacom.com>
-----Original Message-----
From: Alex Tran <alex.t.tran@gmail.com>
Sent: Saturday, January 31, 2026 3:58 PM
To: Jiri Kosina <jikos@kernel.org>; Benjamin Tissoires <bentiss@kernel.org>; Shuah Khan <shuah@kernel.org>
Cc: Cheng, Ping <Ping.Cheng@wacom.com>; Gerecke, Jason <Jason.Gerecke@wacom.com>; Erin Skomra <skomra@gmail.com>; linux-input@vger.kernel.org; linux-kselftest@vger.kernel.org; linux-kernel@vger.kernel.org; Alex Tran <alex.t.tran@gmail.com>
Subject: [PATCH v3] selftests: hid: tests: test_wacom_generic: add tests for display devices and opaque devices
[You don't often get email from alex.t.tran@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
⚠ Warning: This email originated from a sender EXTERNAL to Wacom! Please proceed with caution and DO NOT CLICK links, open attachments or provide any username or password information to this sender unless it is a trusted source.
Verify Wacom devices set INPUT_PROP_DIRECT on display devices and INPUT_PROP_POINTER on opaque devices. Verify INPUT_PROP_POINTER is not set on display devices and INPUT_PROP_DIRECT is not set on opaque devices.
Moved test_prop_pointer into TestOpaqueTablet. Created a DirectTabletTest mixin class for test_prop_direct that can be inherited by display tablet test classes.Used DirectTabletTest for TestDTH2452Tablet case.
Signed-off-by: Alex Tran <alex.t.tran@gmail.com>
---
Changes in v3:
- add assertion for prop tests where opposite is not set
Changes in v2:
- Removed the tests from the BaseTest class
- Removed disabling tests for certain subclasses
- Moved test_prop_pointer under TestOpaqueTablet
- Created DirectTabletTest mixin class
- Moved test_prop_direct under TestDTH2452Tablet
---
.../selftests/hid/tests/test_wacom_generic.py | 34 +++++++++++++---------
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/tools/testing/selftests/hid/tests/test_wacom_generic.py b/tools/testing/selftests/hid/tests/test_wacom_generic.py
index 2d6d04f0ff80bea46dc6c61c2b3a43383be6ac50..3903f479b15bdf8937a9f1ae96791f6dee0f89b7 100644
--- a/tools/testing/selftests/hid/tests/test_wacom_generic.py
+++ b/tools/testing/selftests/hid/tests/test_wacom_generic.py
@@ -598,18 +598,6 @@ class BaseTest:
if unit_set:
assert required[usage].contains(field)
- def test_prop_direct(self):
- """
- Todo: Verify that INPUT_PROP_DIRECT is set on display devices.
- """
- pass
-
- def test_prop_pointer(self):
- """
- Todo: Verify that INPUT_PROP_POINTER is set on opaque devices.
- """
- pass
-
class PenTabletTest(BaseTest.TestTablet):
def assertName(self, uhdev):
@@ -677,6 +665,15 @@ class TestOpaqueTablet(PenTabletTest):
uhdev.event(130, 240, pressure=0), [], auto_syn=False, strict=True
)
+ def test_prop_pointer(self):
+ """
+ Verify that INPUT_PROP_POINTER is set and INPUT_PROP_DIRECT
+ is not set on opaque devices.
+ """
+ evdev = self.uhdev.get_evdev()
+ assert libevdev.INPUT_PROP_POINTER in evdev.properties
+ assert libevdev.INPUT_PROP_DIRECT not in evdev.properties
+
class TestOpaqueCTLTablet(TestOpaqueTablet):
def create_device(self):
@@ -862,7 +859,18 @@ class TestPTHX60_Pen(TestOpaqueCTLTablet):
)
-class TestDTH2452Tablet(test_multitouch.BaseTest.TestMultitouch, TouchTabletTest):
+class DirectTabletTest():
+ def test_prop_direct(self):
+ """
+ Verify that INPUT_PROP_DIRECT is set and INPUT_PROP_POINTER
+ is not set on display devices.
+ """
+ evdev = self.uhdev.get_evdev()
+ assert libevdev.INPUT_PROP_DIRECT in evdev.properties
+ assert libevdev.INPUT_PROP_POINTER not in evdev.properties
+
+
+class TestDTH2452Tablet(test_multitouch.BaseTest.TestMultitouch, TouchTabletTest, DirectTabletTest):
ContactIds = namedtuple("ContactIds", "contact_id, tracking_id, slot_num")
def create_device(self):
---
base-commit: 79b95d74470dd97d7d0908d5a3c0734a23e51aa4
change-id: 20260131-wacom_selftests_display_opaque_dev_tests-4519c400143b
Best regards,
--
Alex Tran <alex.t.tran@gmail.com>
^ permalink raw reply related
* [PATCH v3] HID: pidff: Fix condition effect bit clearing
From: Tomasz Pakuła @ 2026-02-04 21:44 UTC (permalink / raw)
To: jikos, bentiss; +Cc: oleg, linux-input, linux-kernel, tomasz.pakula.oficjalny
As reported by MPDarkGuy on discord, NULL pointer dereferences were
happening because not all the conditional effects bits were cleared.
Properly clear all conditional effect bits from ffbit
Fixes: 7f3d7bc0df4b ("HID: pidff: Better quirk assigment when searching for fields")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
Urgent for 6.19 rc period
V1 -> V2: Simplify by using bitwise or operator
V2 -> V3: Going back to separate bool variable. Turns out I couldn't use
bitwise or operator there. Sorry
drivers/hid/usbhid/hid-pidff.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index a4e700b40ba9..56d6af39ba81 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -1452,10 +1452,13 @@ static int pidff_init_fields(struct pidff_device *pidff, struct input_dev *dev)
hid_warn(pidff->hid, "unknown ramp effect layout\n");
if (PIDFF_FIND_FIELDS(set_condition, PID_SET_CONDITION, 1)) {
- if (test_and_clear_bit(FF_SPRING, dev->ffbit) ||
- test_and_clear_bit(FF_DAMPER, dev->ffbit) ||
- test_and_clear_bit(FF_FRICTION, dev->ffbit) ||
- test_and_clear_bit(FF_INERTIA, dev->ffbit))
+ bool test = false;
+
+ test |= test_and_clear_bit(FF_SPRING, dev->ffbit);
+ test |= test_and_clear_bit(FF_DAMPER, dev->ffbit);
+ test |= test_and_clear_bit(FF_FRICTION, dev->ffbit);
+ test |= test_and_clear_bit(FF_INERTIA, dev->ffbit);
+ if (test)
hid_warn(pidff->hid, "unknown condition effect layout\n");
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2] HID: pidff: Fix condition effect bit clearing
From: kernel test robot @ 2026-02-04 21:07 UTC (permalink / raw)
To: Tomasz Pakuła, jikos, bentiss
Cc: llvm, oe-kbuild-all, oleg, linux-input, linux-kernel,
tomasz.pakula.oficjalny
In-Reply-To: <20260204133138.475880-1-tomasz.pakula.oficjalny@gmail.com>
Hi Tomasz,
kernel test robot noticed the following build warnings:
[auto build test WARNING on hid/for-next]
[also build test WARNING on linus/master v6.19-rc8 next-20260204]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Tomasz-Paku-a/HID-pidff-Fix-condition-effect-bit-clearing/20260204-213418
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20260204133138.475880-1-tomasz.pakula.oficjalny%40gmail.com
patch subject: [PATCH v2] HID: pidff: Fix condition effect bit clearing
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260205/202602050440.e5LEMod6-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260205/202602050440.e5LEMod6-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/202602050440.e5LEMod6-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/hid/usbhid/hid-pidff.c:1456:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
1456 | if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1457 | test_and_clear_bit(FF_DAMPER, dev->ffbit) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1458 | test_and_clear_bit(FF_FRICTION, dev->ffbit) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ||
1459 | test_and_clear_bit(FF_INERTIA, dev->ffbit))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/usbhid/hid-pidff.c:1456:7: note: cast one or both operands to int to silence this warning
>> drivers/hid/usbhid/hid-pidff.c:1456:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
1456 | if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1457 | test_and_clear_bit(FF_DAMPER, dev->ffbit) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ||
1458 | test_and_clear_bit(FF_FRICTION, dev->ffbit) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/usbhid/hid-pidff.c:1456:7: note: cast one or both operands to int to silence this warning
>> drivers/hid/usbhid/hid-pidff.c:1456:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
1456 | if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ||
1457 | test_and_clear_bit(FF_DAMPER, dev->ffbit) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/usbhid/hid-pidff.c:1456:7: note: cast one or both operands to int to silence this warning
3 warnings generated.
vim +1456 drivers/hid/usbhid/hid-pidff.c
1398
1399 #define PIDFF_FIND_FIELDS(name, report, strict) \
1400 pidff_find_fields(pidff->name, pidff_ ## name, \
1401 pidff->reports[report], \
1402 ARRAY_SIZE(pidff_ ## name), strict, &pidff->quirks)
1403
1404 /*
1405 * Fill and check the pidff_usages
1406 */
1407 static int pidff_init_fields(struct pidff_device *pidff, struct input_dev *dev)
1408 {
1409 if (PIDFF_FIND_FIELDS(set_effect, PID_SET_EFFECT, 1)) {
1410 hid_err(pidff->hid, "unknown set_effect report layout\n");
1411 return -ENODEV;
1412 }
1413
1414 PIDFF_FIND_FIELDS(block_load, PID_BLOCK_LOAD, 0);
1415 if (!pidff->block_load[PID_EFFECT_BLOCK_INDEX].value) {
1416 hid_err(pidff->hid, "unknown pid_block_load report layout\n");
1417 return -ENODEV;
1418 }
1419
1420 if (PIDFF_FIND_FIELDS(effect_operation, PID_EFFECT_OPERATION, 1)) {
1421 hid_err(pidff->hid, "unknown effect_operation report layout\n");
1422 return -ENODEV;
1423 }
1424
1425 if (PIDFF_FIND_FIELDS(block_free, PID_BLOCK_FREE, 1)) {
1426 hid_err(pidff->hid, "unknown pid_block_free report layout\n");
1427 return -ENODEV;
1428 }
1429
1430 if (pidff_find_special_fields(pidff) || pidff_find_effects(pidff, dev))
1431 return -ENODEV;
1432
1433 if (PIDFF_FIND_FIELDS(set_envelope, PID_SET_ENVELOPE, 1)) {
1434 if (test_and_clear_bit(FF_CONSTANT, dev->ffbit))
1435 hid_warn(pidff->hid,
1436 "has constant effect but no envelope\n");
1437 if (test_and_clear_bit(FF_RAMP, dev->ffbit))
1438 hid_warn(pidff->hid,
1439 "has ramp effect but no envelope\n");
1440
1441 if (test_and_clear_bit(FF_PERIODIC, dev->ffbit))
1442 hid_warn(pidff->hid,
1443 "has periodic effect but no envelope\n");
1444 }
1445
1446 if (PIDFF_FIND_FIELDS(set_constant, PID_SET_CONSTANT, 1) &&
1447 test_and_clear_bit(FF_CONSTANT, dev->ffbit))
1448 hid_warn(pidff->hid, "unknown constant effect layout\n");
1449
1450 if (PIDFF_FIND_FIELDS(set_ramp, PID_SET_RAMP, 1) &&
1451 test_and_clear_bit(FF_RAMP, dev->ffbit))
1452 hid_warn(pidff->hid, "unknown ramp effect layout\n");
1453
1454 if (PIDFF_FIND_FIELDS(set_condition, PID_SET_CONDITION, 1)) {
1455 /* Bitwise to ensure all the bits will be cleared */
> 1456 if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
1457 test_and_clear_bit(FF_DAMPER, dev->ffbit) |
1458 test_and_clear_bit(FF_FRICTION, dev->ffbit) |
1459 test_and_clear_bit(FF_INERTIA, dev->ffbit))
1460 hid_warn(pidff->hid, "unknown condition effect layout\n");
1461 }
1462
1463 if (PIDFF_FIND_FIELDS(set_periodic, PID_SET_PERIODIC, 1) &&
1464 test_and_clear_bit(FF_PERIODIC, dev->ffbit))
1465 hid_warn(pidff->hid, "unknown periodic effect layout\n");
1466
1467 PIDFF_FIND_FIELDS(pool, PID_POOL, 0);
1468
1469 if (!PIDFF_FIND_FIELDS(device_gain, PID_DEVICE_GAIN, 1))
1470 set_bit(FF_GAIN, dev->ffbit);
1471
1472 return 0;
1473 }
1474
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] HID: asus: synchronize fn_lock_sync_work initialization and teardown
From: Sahil Chandna @ 2026-02-04 18:20 UTC (permalink / raw)
To: jikos, bentiss, connorbelli2003, linux-input, linux-kernel, stern
Cc: Sahil Chandna, syzbot+13f8286fa2de04a7cd48
Syzbot reported a workqueue warning where cancel_work_sync() was
called on an uninitialized work_struct. Fix this by adding a mutex lock and
initializing fn_lock_sync_work before marking fn_lock as enabled.
This ensures cancel_work_sync() is only called for an initialized work.
Fixes: f631011e36b8 ("HID: hid-asus: Implement fn lock for Asus ProArt P16")
Reported-by: syzbot+13f8286fa2de04a7cd48@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=13f8286fa2de04a7cd48
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sahil Chandna <chandna.sahil@gmail.com>
---
link to v1: https://lore.kernel.org/all/20260130155204.96831-1-chandna.sahil@gmail.com/
changes since v1:
- Add mutex locking between init_work and cancel_work.
Testing:
- Reproduced bug on local setup and original syz reproducer.
- Tested with fix and original C reproducer, issue is not reproduced
locally.
---
drivers/hid/hid-asus.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 1b9793f7c07e..2d6b6e363bde 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -147,6 +147,7 @@ struct asus_drvdata {
unsigned long battery_next_query;
struct work_struct fn_lock_sync_work;
bool fn_lock;
+ struct mutex lock;
};
static int asus_report_battery(struct asus_drvdata *, u8 *, int);
@@ -960,8 +961,10 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
}
if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
- drvdata->fn_lock = true;
+ mutex_lock(&drvdata->lock);
INIT_WORK(&drvdata->fn_lock_sync_work, asus_sync_fn_lock);
+ drvdata->fn_lock = true;
+ mutex_unlock(&drvdata->lock);
asus_kbd_set_fn_lock(hdev, true);
}
@@ -1258,6 +1261,7 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
drvdata->hdev = hdev;
+ mutex_init(&drvdata->lock);
if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
ret = asus_battery_probe(hdev);
@@ -1343,8 +1347,10 @@ static void asus_remove(struct hid_device *hdev)
cancel_work_sync(&drvdata->kbd_backlight->work);
}
- if (drvdata->quirks & QUIRK_HID_FN_LOCK)
+ mutex_lock(&drvdata->lock);
+ if ((drvdata->quirks & QUIRK_HID_FN_LOCK) && drvdata->fn_lock)
cancel_work_sync(&drvdata->fn_lock_sync_work);
+ mutex_unlock(&drvdata->lock);
hid_hw_stop(hdev);
}
--
2.50.1
^ permalink raw reply related
* [PATCH v2] HID: pidff: Fix condition effect bit clearing
From: Tomasz Pakuła @ 2026-02-04 13:31 UTC (permalink / raw)
To: jikos, bentiss; +Cc: oleg, linux-input, linux-kernel, tomasz.pakula.oficjalny
As reported by MPDarkGuy on discord, NULL pointer dereferences were
happening because not all the conditional effects bits were cleared.
Properly clear all conditional effect bits from ffbit
Fixes: 7f3d7bc0df4b ("HID: pidff: Better quirk assigment when searching for fields")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
Urgent for 6.19 rc period
V1 -> V2: Simplify by using bitwise or operator
drivers/hid/usbhid/hid-pidff.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index a4e700b40ba9..792992c69837 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -1452,9 +1452,10 @@ static int pidff_init_fields(struct pidff_device *pidff, struct input_dev *dev)
hid_warn(pidff->hid, "unknown ramp effect layout\n");
if (PIDFF_FIND_FIELDS(set_condition, PID_SET_CONDITION, 1)) {
- if (test_and_clear_bit(FF_SPRING, dev->ffbit) ||
- test_and_clear_bit(FF_DAMPER, dev->ffbit) ||
- test_and_clear_bit(FF_FRICTION, dev->ffbit) ||
+ /* Bitwise to ensure all the bits will be cleared */
+ if (test_and_clear_bit(FF_SPRING, dev->ffbit) |
+ test_and_clear_bit(FF_DAMPER, dev->ffbit) |
+ test_and_clear_bit(FF_FRICTION, dev->ffbit) |
test_and_clear_bit(FF_INERTIA, dev->ffbit))
hid_warn(pidff->hid, "unknown condition effect layout\n");
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] HID: pidff: Fix condition effect bit clearing
From: Tomasz Pakuła @ 2026-02-04 12:58 UTC (permalink / raw)
To: Jiri Slaby, jikos, bentiss, sashal
Cc: oleg, linux-input, linux-kernel, stable
In-Reply-To: <618af8dc-7698-4335-9d0a-fc7ec36cce9f@kernel.org>
On Wed, 2026-02-04 at 12:58 +0100, Jiri Slaby wrote:
> You could use | directly in the if, perhaps with a comment.
>
That's actually pretty neat. Didn't think about it. Thanks!
Tomasz
^ permalink raw reply
* Re: [PATCH v1 2/9] misc: Support Asus Transformer's EC access device
From: Svyatoslav Ryhel @ 2026-02-04 12:40 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Sebastian Reichel,
Michał Mirosław, Ion Agorria, devicetree, linux-kernel,
linux-input, linux-leds, linux-pm
In-Reply-To: <2026020347-mushy-lunar-d12d@gregkh>
вт, 3 лют. 2026 р. о 18:58 Greg Kroah-Hartman <gregkh@linuxfoundation.org> пише:
>
> On Tue, Feb 03, 2026 at 06:50:01PM +0200, Svyatoslav Ryhel wrote:
> > > debugfs allows you to do much much more than simple stuff like
> > > BIN_ATTR_RW(). Go wild there, but don't put debugging stuff in sysfs,
> > > that is NOT what it is there for at all, but rather, that is exactly
> > > what debugfs is for.
> > >
> >
> > I am removing said stuff from sysfs, that is not what I am asking.
> > Debugs does not allow to upload register values in a form of binary
> > block. It allows only dumping via debugfs_create_blob or
> > debugfs_create_regset32 but not writing. If you know examples of
> > reading and writing register sets as binary data, please point me to
> > it.
>
> You can easily write your own given that debugfs allows you to use what
> ever file operations you want to use for a file. Why not just use that?
>
> > I am asking if it is possible only to preserve dockram_read/write
> > functions in the code, without exposing it to sysfs.
>
> Why would you want to do that?
>
Nevermind, everything is good. I have figured it out hopefully.
> confused,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH] HID: pidff: Fix condition effect bit clearing
From: Jiri Slaby @ 2026-02-04 11:58 UTC (permalink / raw)
To: Tomasz Pakuła, jikos, bentiss, sashal
Cc: oleg, linux-input, linux-kernel, stable
In-Reply-To: <20260203174241.2863219-1-tomasz.pakula.oficjalny@gmail.com>
On 03. 02. 26, 18:42, Tomasz Pakuła wrote:
> As reported by MPDarkGuy on discord, NULL pointer dereferences were
> happening because not all the conditional effects bits were cleared.
>
> Properly clear all conditional effect bits from ffbit
>
> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
> ---
>
> Urgent for 6.19 rc period and backports for 6.18
>
> drivers/hid/usbhid/hid-pidff.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
> index a4e700b40ba9..56d6af39ba81 100644
> --- a/drivers/hid/usbhid/hid-pidff.c
> +++ b/drivers/hid/usbhid/hid-pidff.c
> @@ -1452,10 +1452,13 @@ static int pidff_init_fields(struct pidff_device *pidff, struct input_dev *dev)
> hid_warn(pidff->hid, "unknown ramp effect layout\n");
>
> if (PIDFF_FIND_FIELDS(set_condition, PID_SET_CONDITION, 1)) {
> - if (test_and_clear_bit(FF_SPRING, dev->ffbit) ||
> - test_and_clear_bit(FF_DAMPER, dev->ffbit) ||
> - test_and_clear_bit(FF_FRICTION, dev->ffbit) ||
> - test_and_clear_bit(FF_INERTIA, dev->ffbit))
> + bool test = false;
> +
> + test |= test_and_clear_bit(FF_SPRING, dev->ffbit);
> + test |= test_and_clear_bit(FF_DAMPER, dev->ffbit);
> + test |= test_and_clear_bit(FF_FRICTION, dev->ffbit);
> + test |= test_and_clear_bit(FF_INERTIA, dev->ffbit);
You could use | directly in the if, perhaps with a comment.
> + if (test)
> hid_warn(pidff->hid, "unknown condition effect layout\n");
> }
>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: imagis: allow linux,keycodes for ist3038
From: Dmitry Torokhov @ 2026-02-04 11:25 UTC (permalink / raw)
To: Raymond Hackley
Cc: linux-kernel, Markuss Broks, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-input, devicetree, phone-devel,
~postmarketos/upstreaming
In-Reply-To: <20251224100941.3356201-1-raymondhackley@protonmail.com>
On Wed, Dec 24, 2025 at 10:10:48AM +0000, Raymond Hackley wrote:
> Imagis IST3038 provides touch keys. Allow linux,keycodes for ist3038.
>
> Signed-off-by: Raymond Hackley <raymondhackley@protonmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: asus: Add check for cancelling fn_lock_sync_work
From: Jiri Kosina @ 2026-02-04 10:39 UTC (permalink / raw)
To: Alan Stern
Cc: Sahil Chandna, bentiss, connorbelli2003, linux-input,
linux-kernel
In-Reply-To: <273d8509-3d2e-4686-b56f-a12c5c203291@rowland.harvard.edu>
On Mon, 2 Feb 2026, Alan Stern wrote:
> With no synchronization between the two routines, this patch cannot
> possibly be correct. There's nothing to prevent the CPU running
> asus_input_configured() from executing the assignment to
> drvdata->fn_lock before doing the INIT_WORK() (unless the INIT_WORK()
> call itself contains some synchronization -- but obviously the code
> shouldn't depend on that).
Ouch, you are of course right, that escaped my attention. Thanks a lot for
catching this, Alan!
Now dropped from the queue.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Data Modul Personalengpässe lösen
From: Philip Schiele @ 2026-02-04 9:13 UTC (permalink / raw)
To: linux-input
Sehr geehrtes Data Modul Team,
Ich habe gesehen, dass Sie bei DATA MODUL umfassende Dienstleistungen
von Design-in über Forschung & Entwicklung bis hin zu Qualifizierung
und Fertigung anbieten. Apropos Betriebsabläufe: Plötzliche
Personalausfälle können in der Logistik schnell zu Engpässen führen.
Wir bei Zenjob stellen deutschlandweit flexible Logistik-Aushilfen
innerhalb von 24 Stunden bereit, ohne dass Fixkosten entstehen. Unsere
Besetzungsquote liegt bei über 90 Prozent.
So können Sie bei unvorhergesehenen Ausfällen sofort reagieren und
Ihre Betriebsabläufe aufrechterhalten. Wir sind überzeugt, dass diese
Flexibilität für Ihr Unternehmen wertvoll ist.
Buchen Sie noch heute und haben Sie Ihre Schicht in 24 Stunden besetzt.
Beste Grüße,
Philip
Philip Schiele — Sales Development Representative
ZENJOB
www.zenjob.com | +49302089860400
^ permalink raw reply
* Fundacja Rodzina a optymalizacja podatkowa
From: Mikołaj Rak @ 2026-02-04 8:30 UTC (permalink / raw)
To: linux-input
Szanowni Państwo,
czy byliby Państwo zainteresowani rozmową o możliwych rozwiązaniach dla swojej firmy i rodziny?
Nowelizacja ustawy o Fundacjach Rodzinnych otwiera przed przedsiębiorcami zupełnie nowe możliwości ochrony majątku i planowania sukcesji. Fundacja Rodzinna pozwala oddzielić aktywa od ryzyk biznesowych, prawnych i podatkowych, a jednocześnie zachować kontrolę nad swoim majątkiem i zadbać o jego trwałość dla kolejnych pokoleń.
Co istotne, po upływie 10 lat od wniesienia aktywów do fundacji, roszczenia o zachowek przestają obowiązywać. Ustawodawca przewidział również liczne zwolnienia podatkowe obejmujące m.in. dochody z działalności gospodarczej czy wynajem nieruchomości.
Będę wdzięczny za informację, czy chcieliby Państwo poznać możliwość stworzenia Fundacji Rodzinnej?
Pozdrawiam
Mikołaj Rak
^ permalink raw reply
* Re: [PATCH] HID: pidff: Fix condition effect bit clearing
From: Greg KH @ 2026-02-04 5:21 UTC (permalink / raw)
To: Tomasz Pakuła
Cc: jikos, bentiss, sashal, oleg, linux-input, linux-kernel, stable
In-Reply-To: <20260203174241.2863219-1-tomasz.pakula.oficjalny@gmail.com>
On Tue, Feb 03, 2026 at 06:42:41PM +0100, Tomasz Pakuła wrote:
> As reported by MPDarkGuy on discord, NULL pointer dereferences were
> happening because not all the conditional effects bits were cleared.
>
> Properly clear all conditional effect bits from ffbit
>
> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
> ---
>
> Urgent for 6.19 rc period and backports for 6.18
>
> drivers/hid/usbhid/hid-pidff.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
> index a4e700b40ba9..56d6af39ba81 100644
> --- a/drivers/hid/usbhid/hid-pidff.c
> +++ b/drivers/hid/usbhid/hid-pidff.c
> @@ -1452,10 +1452,13 @@ static int pidff_init_fields(struct pidff_device *pidff, struct input_dev *dev)
> hid_warn(pidff->hid, "unknown ramp effect layout\n");
>
> if (PIDFF_FIND_FIELDS(set_condition, PID_SET_CONDITION, 1)) {
> - if (test_and_clear_bit(FF_SPRING, dev->ffbit) ||
> - test_and_clear_bit(FF_DAMPER, dev->ffbit) ||
> - test_and_clear_bit(FF_FRICTION, dev->ffbit) ||
> - test_and_clear_bit(FF_INERTIA, dev->ffbit))
> + bool test = false;
> +
> + test |= test_and_clear_bit(FF_SPRING, dev->ffbit);
> + test |= test_and_clear_bit(FF_DAMPER, dev->ffbit);
> + test |= test_and_clear_bit(FF_FRICTION, dev->ffbit);
> + test |= test_and_clear_bit(FF_INERTIA, dev->ffbit);
> + if (test)
> hid_warn(pidff->hid, "unknown condition effect layout\n");
> }
>
> --
> 2.52.0
>
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [PATCH 2/2] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: kernel test robot @ 2026-02-03 23:17 UTC (permalink / raw)
To: Hugo Villeneuve, hvilleneuve, dmitry.torokhov, robh, krzk+dt,
conor+dt
Cc: oe-kbuild-all, linux-input, devicetree, linux-kernel, hugo
In-Reply-To: <20260203155023.536103-3-hugo@hugovil.com>
Hi Hugo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ed8a4ef29da3821ee3155d3b1925fa67fc92aae2]
url: https://github.com/intel-lab-lkp/linux/commits/Hugo-Villeneuve/dt-bindings-input-add-GPIO-charlieplex-keypad/20260204-001338
base: ed8a4ef29da3821ee3155d3b1925fa67fc92aae2
patch link: https://lore.kernel.org/r/20260203155023.536103-3-hugo%40hugovil.com
patch subject: [PATCH 2/2] Input: charlieplex_keypad: add GPIO charlieplex keypad
config: parisc-randconfig-r072-20260204 (https://download.01.org/0day-ci/archive/20260204/202602040703.1Bu56Htu-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 8.5.0
smatch version: v0.5.0-8994-gd50c5a4c
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260204/202602040703.1Bu56Htu-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/202602040703.1Bu56Htu-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/input/keyboard/charlieplex_keypad.c: In function 'charlieplex_keypad_init_gpio':
>> drivers/input/keyboard/charlieplex_keypad.c:120:6: warning: variable 'nkeys' set but not used [-Wunused-but-set-variable]
int nkeys;
^~~~~
vim +/nkeys +120 drivers/input/keyboard/charlieplex_keypad.c
115
116 static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
117 struct charlieplex_keypad *keypad)
118 {
119 bool active_low;
> 120 int nkeys;
121 int i;
122
123 keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
124 if (IS_ERR(keypad->line_gpios))
125 return PTR_ERR(keypad->line_gpios);
126
127 keypad->nlines = keypad->line_gpios->ndescs;
128
129 if (keypad->nlines > MATRIX_MAX_ROWS)
130 return -EINVAL;
131
132 nkeys = (keypad->nlines * keypad->nlines) - keypad->nlines;
133
134 active_low = device_property_read_bool(&pdev->dev, "gpio-activelow");
135
136 for (i = 0; i < keypad->nlines; i++) {
137 gpiod_set_consumer_name(keypad->line_gpios->desc[i], "charlieplex_kbd_line");
138
139 if (active_low ^ gpiod_is_active_low(keypad->line_gpios->desc[i]))
140 gpiod_toggle_active_low(keypad->line_gpios->desc[i]);
141 }
142
143 return 0;
144 }
145
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v12 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Jiri Kosina @ 2026-02-03 19:44 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, Denis Benato
In-Reply-To: <CAGwozwEtW4+ke4p-o0+92Qv-03pkVTMt3UUAJfH_o69376pJog@mail.gmail.com>
On Tue, 3 Feb 2026, Antheas Kapenekakis wrote:
> > > This is a two part series which does the following:
> > > - Clean-up init sequence
> > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > devices have synced brightness controls and the backlight button works
> > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > >
> > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > to make this easier to merge.
> >
> > So I see (because of the conflicts in linux-next :) ) that this is now
> > sitting in kernel/git/pdx86/platform-drivers-x86.git with Ack from
> > Benjamin.
> >
> > Where did this Ack happen? I don't see it neither in my inbox, nor at
> > 20260122075044.5070-1-lkml@antheas.dev
>
> Mmmm. From my part Benjamin's acks came on V10[1]. I think that series
> was for kernel 6.19 originally.
>
> I b4 to develop the next version so they were carried.
Ah, I see, thanks.
I guess we'll live with the conflicts between the trees for now then, and
will make Linus aware of it when sending merge window piles.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v12 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Antheas Kapenekakis @ 2026-02-03 19:36 UTC (permalink / raw)
To: Jiri Kosina
Cc: platform-driver-x86, linux-input, linux-kernel,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, Denis Benato
In-Reply-To: <92095q4o-n2o1-p4or-n238-o1ro83616o37@xreary.bet>
On Tue, 3 Feb 2026 at 20:06, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Thu, 22 Jan 2026, Antheas Kapenekakis wrote:
>
> > This is a two part series which does the following:
> > - Clean-up init sequence
> > - Unify backlight handling to happen under asus-wmi so that all Aura
> > devices have synced brightness controls and the backlight button works
> > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >
> > For more context, see cover letter of V1. Since V5, I removed some patches
> > to make this easier to merge.
>
> So I see (because of the conflicts in linux-next :) ) that this is now
> sitting in kernel/git/pdx86/platform-drivers-x86.git with Ack from
> Benjamin.
>
> Where did this Ack happen? I don't see it neither in my inbox, nor at
> 20260122075044.5070-1-lkml@antheas.dev
Mmmm. From my part Benjamin's acks came on V10[1]. I think that series
was for kernel 6.19 originally.
I b4 to develop the next version so they were carried.
Antheas
[1] https://lore.kernel.org/lkml/20251122110032.4274-1-lkml@antheas.dev/
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-02-03 19:06 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: linux-kernel, dmitry.torokhov, conor+dt, devicetree, hvilleneuve,
linux-input, krzk+dt
In-Reply-To: <177014266917.3376127.756776677952580015.robh@kernel.org>
On Tue, 03 Feb 2026 12:17:49 -0600
"Rob Herring (Arm)" <robh@kernel.org> wrote:
>
> On Tue, 03 Feb 2026 10:49:47 -0500, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Add DT bindings for GPIO charlieplex keypad.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > .../input/gpio-charlieplex-keypad.yaml | 88 +++++++++++++++++++
> > 1 file changed, 88 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Lexical error: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.example.dts:30.17-27 Unexpected 'MATRIX_KEY'
> Error: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.example.dts:30.29-30 syntax error
> FATAL ERROR: Unable to parse input tree
> make[2]: *** [scripts/Makefile.dtbs:132: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.example.dtb] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1525: dt_binding_check] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
Hi,
I will add:
#include <dt-bindings/input/input.h>
to the example section to fix this in V2.
Thank you,
Hugo.
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260203155023.536103-2-hugo@hugovil.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v12 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Jiri Kosina @ 2026-02-03 19:06 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, Denis Benato
In-Reply-To: <20260122075044.5070-1-lkml@antheas.dev>
On Thu, 22 Jan 2026, Antheas Kapenekakis wrote:
> This is a two part series which does the following:
> - Clean-up init sequence
> - Unify backlight handling to happen under asus-wmi so that all Aura
> devices have synced brightness controls and the backlight button works
> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>
> For more context, see cover letter of V1. Since V5, I removed some patches
> to make this easier to merge.
So I see (because of the conflicts in linux-next :) ) that this is now
sitting in kernel/git/pdx86/platform-drivers-x86.git with Ack from
Benjamin.
Where did this Ack happen? I don't see it neither in my inbox, nor at
20260122075044.5070-1-lkml@antheas.dev
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: add GPIO charlieplex keypad
From: Rob Herring (Arm) @ 2026-02-03 18:17 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: linux-kernel, dmitry.torokhov, conor+dt, devicetree, hvilleneuve,
linux-input, krzk+dt
In-Reply-To: <20260203155023.536103-2-hugo@hugovil.com>
On Tue, 03 Feb 2026 10:49:47 -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Add DT bindings for GPIO charlieplex keypad.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> .../input/gpio-charlieplex-keypad.yaml | 88 +++++++++++++++++++
> 1 file changed, 88 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Lexical error: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.example.dts:30.17-27 Unexpected 'MATRIX_KEY'
Error: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.example.dts:30.29-30 syntax error
FATAL ERROR: Unable to parse input tree
make[2]: *** [scripts/Makefile.dtbs:132: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1525: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260203155023.536103-2-hugo@hugovil.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH 5/5] HID: Update MAINTAINERS for USB HID PID
From: Tomasz Pakuła @ 2026-02-03 17:45 UTC (permalink / raw)
To: jikos, bentiss; +Cc: oleg, linux-input, linux-kernel, tomasz.pakula.oficjalny
In-Reply-To: <20260203174531.2866644-1-tomasz.pakula.oficjalny@gmail.com>
Take de-facto ownership of core hid-pidff driver
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
MAINTAINERS | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a0dd762f5648..b6c16e134070 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11205,14 +11205,6 @@ F: drivers/hid/hid-sensor-*
F: drivers/iio/*/hid-*
F: include/linux/hid-sensor-*
-HID UNIVERSAL PIDFF DRIVER
-M: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
-M: Oleg Makarenko <oleg@makarenk.ooo>
-L: linux-input@vger.kernel.org
-S: Maintained
-B: https://github.com/JacKeTUs/universal-pidff/issues
-F: drivers/hid/hid-universal-pidff.c
-
HID VRC-2 CAR CONTROLLER DRIVER
M: Marcus Folkesson <marcus.folkesson@gmail.com>
L: linux-input@vger.kernel.org
@@ -26927,6 +26919,15 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: Documentation/hid/hiddev.rst
F: drivers/hid/usbhid/
+USB HID PID DRIVERS (USB WHEELBASES, JOYSTICKS, RUDDERS, ...)
+M: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
+M: Oleg Makarenko <oleg@makarenk.ooo>
+L: linux-input@vger.kernel.org
+S: Maintained
+B: https://github.com/JacKeTUs/universal-pidff/issues
+F: drivers/hid/usbhid/hid-pidff*
+F: drivers/hid/hid-universal-pidff.c
+
USB INTEL XHCI ROLE MUX DRIVER
M: Hans de Goede <hansg@kernel.org>
L: linux-usb@vger.kernel.org
--
2.52.0
^ permalink raw reply related
* [PATCH 4/5] HID: pidff: Add MISSING_DEADBAND quirk
From: Tomasz Pakuła @ 2026-02-03 17:45 UTC (permalink / raw)
To: jikos, bentiss; +Cc: oleg, linux-input, linux-kernel, tomasz.pakula.oficjalny
In-Reply-To: <20260203174531.2866644-1-tomasz.pakula.oficjalny@gmail.com>
Some devices (mainly Asetek) do not have deadband field in set
conditional usage. Do not fail set conditional usage search if it's
missing. Allows conditional effect playback on Asetek wheelbases.
Deadband is practically never used in simracing anyway.
Align property name in the whole driver to use 'deadband' without space.
Co-developed-by: Oleg Makarenko <oleg@makarenk.ooo>
Signed-off-by: Oleg Makarenko <oleg@makarenk.ooo>
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
drivers/hid/usbhid/hid-pidff.c | 12 +++++++++---
drivers/hid/usbhid/hid-pidff.h | 3 +++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index 17bdc36d1908..8106b045a8f7 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -82,7 +82,7 @@ static const u8 pidff_set_envelope[] = { 0x22, 0x5b, 0x5c, 0x5d, 0x5e };
#define PID_NEG_COEFFICIENT 4
#define PID_POS_SATURATION 5
#define PID_NEG_SATURATION 6
-#define PID_DEAD_BAND 7
+#define PID_DEADBAND 7
static const u8 pidff_set_condition[] = {
0x22, 0x23, 0x60, 0x61, 0x62, 0x63, 0x64, 0x65
};
@@ -632,8 +632,11 @@ static void pidff_set_condition_report(struct pidff_device *pidff,
pidff_set_signed(&pidff->set_condition[PID_NEG_SATURATION],
effect->u.condition[i].left_saturation);
- pidff_set(&pidff->set_condition[PID_DEAD_BAND],
- effect->u.condition[i].deadband);
+ /* Omit Deadband field if missing */
+ if (!(pidff->quirks & HID_PIDFF_QUIRK_MISSING_DEADBAND))
+ pidff_set(&pidff->set_condition[PID_DEADBAND],
+ effect->u.condition[i].deadband);
+
hid_hw_request(pidff->hid, pidff->reports[PID_SET_CONDITION],
HID_REQ_SET_REPORT);
}
@@ -1103,6 +1106,9 @@ static int pidff_find_fields(struct pidff_usage *usage, const u8 *table,
else if (table[i] == pidff_set_condition[PID_NEG_SATURATION])
PIDFF_MISSING_FIELD(NEG_SATURATION, quirks);
+ else if (table[i] == pidff_set_condition[PID_DEADBAND])
+ PIDFF_MISSING_FIELD(DEADBAND, quirks);
+
else if (strict) {
pr_debug("failed to locate %d\n", i);
return -1;
diff --git a/drivers/hid/usbhid/hid-pidff.h b/drivers/hid/usbhid/hid-pidff.h
index 8d879067718f..c413aa732842 100644
--- a/drivers/hid/usbhid/hid-pidff.h
+++ b/drivers/hid/usbhid/hid-pidff.h
@@ -27,6 +27,9 @@
/* Allow devices with missing negative saturation in the set condition usage */
#define HID_PIDFF_QUIRK_MISSING_NEG_SATURATION BIT(6)
+/* Allow devices with missing deadband in the set condition usage */
+#define HID_PIDFF_QUIRK_MISSING_DEADBAND BIT(7)
+
#ifdef CONFIG_HID_PID
int hid_pidff_init(struct hid_device *hid);
int hid_pidff_init_with_quirks(struct hid_device *hid, u32 initial_quirks);
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox