* 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 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] 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
* 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
* 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
* 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
* 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: 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 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: 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
* [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
* [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
* 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 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 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
* 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
* [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] 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
* 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 1/2] dt-bindings: input: add GPIO charlieplex keypad
From: Dmitry Torokhov @ 2026-02-05 9:24 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: hvilleneuve, robh, krzk+dt, conor+dt, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260203155023.536103-2-hugo@hugovil.com>
Hi Hugo,
On Tue, Feb 03, 2026 at 10:49:47AM -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Add DT bindings for GPIO charlieplex keypad.
>
...
> + linux,no-autorepeat:
> + type: boolean
> + description: Do not enable autorepeat feature.
Let's use standard "autorepeat" property to enable autorepeat when
needed.
> +
> + gpio-activelow:
> + type: boolean
> + description:
> + Force GPIO polarity to active low.
> + In the absence of this property GPIOs are treated as active high.
No, the polarity should be encoded in individual GPIOs, not via a
separate property.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v12 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Andi Shyti @ 2026-02-05 11:44 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires,
Andy Shevchenko, Conor Dooley, Jiri Kosina, devicetree,
linux-input, Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy,
linux-i2c, linux-kernel, Leo Huang, Arun D Patil, Willie Thai,
Ting-Kai Chen
In-Reply-To: <20251126-cp2112-dt-v12-1-2cdba6481db3@plexus.com>
Hi Danny,
On Wed, Nov 26, 2025 at 11:05:24AM -0600, Danny Kaehn wrote:
> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>
> The binding allows describing the chip's gpio and i2c controller in DT,
> with the i2c controller being bound to a subnode named "i2c". This is
> intended to be used in configurations where the CP2112 is permanently
> connected in hardware.
>
> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
just this patch, merged to i2c/i2c-host-2.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2 2/3] Input: aw86938 - add driver for Awinic AW86938
From: Krzysztof Kozlowski @ 2026-02-05 13:13 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Dmitry Torokhov, Griffin Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Luca Weiss, linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <472d7db3-db34-4966-aa17-588e1153ba12@oss.qualcomm.com>
On Mon, Feb 02, 2026 at 11:12:26AM +0100, Konrad Dybcio wrote:
> On 2/1/26 2:49 AM, Dmitry Torokhov wrote:
> > Hi Griffin,
> >
> > On Wed, Jan 28, 2026 at 04:51:14PM +0100, Griffin Kroah-Hartman wrote:
> >> @@ -717,9 +746,19 @@ static int aw86927_detect(struct aw86927_data *haptics)
> >>
> >> chip_id = be16_to_cpu(read_buf);
> >>
> >> - if (chip_id != AW86927_CHIPID) {
> >> - dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
> >> - return -ENODEV;
> >> + switch (haptics->model) {
> >> + case AW86927:
> >> + if (chip_id != AW86927_CHIPID) {
> >> + dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
> >> + return -ENODEV;
> >> + }
> >
> > If we are able to query chip ID why do we need to have separate
> > compatibles? I would define chip data structure with differences between
> > variants and assign and use it instead of having separate compatible.
>
> dt-bindings guidelines explicitly call for this, a chipid comparison
No, they don't. If devices offer autodetection, then they are in fact
fully compatible for the SW.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: input: awinic,aw86927: Add Awinic AW86938
From: Krzysztof Kozlowski @ 2026-02-05 13:14 UTC (permalink / raw)
To: Griffin Kroah-Hartman
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Luca Weiss, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260128-aw86938-driver-v2-1-b51ee086aaf5@fairphone.com>
On Wed, Jan 28, 2026 at 04:51:13PM +0100, Griffin Kroah-Hartman wrote:
> Add bindings for the Awinic AW86938 haptic chip which can be found in
> smartphones. These two chips require a similar devicetree configuration,
> but have a register layout that's not 100% compatible.
That would be fine if I did not look at your driver which clearly
suggest there is detection mechanism. Reliable detection by
vendor/programming interface means devices are fully compatible, so
fallback.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] input: xpad: Add support for BETOP BTP-KP50B/C controller's wireless mode
From: Shengyu Qu @ 2026-02-05 14:15 UTC (permalink / raw)
To: dmitry.torokhov, vi, lkml, niltonperimneto, linux-input,
linux-kernel
Cc: Shengyu Qu
BETOP's BTP-KP50B and BTP-KP50C controller's wireless dongles are both
working as standard Xbox 360 controllers. Add USB device IDs for them to
xpad driver.
Both controllers can't work as Xbox controllers when using wired mode and
have different USB IDs.
Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
---
drivers/input/joystick/xpad.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 363d50949386..260dd41ea6e5 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -360,6 +360,8 @@ static const struct xpad_device {
{ 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
{ 0x1ee9, 0x1590, "ZOTAC Gaming Zone", 0, XTYPE_XBOX360 },
+ { 0x20bc, 0x5134, "BETOP BTP-KP50B Xinput Dongle", 0, XTYPE_XBOX360 },
+ { 0x20bc, 0x514a, "BETOP BTP-KP50C Xinput Dongle", 0, XTYPE_XBOX360 },
{ 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE },
{ 0x20d6, 0x2009, "PowerA Enhanced Wired Controller for Xbox Series X|S", 0, XTYPE_XBOXONE },
{ 0x20d6, 0x2064, "PowerA Wired Controller for Xbox", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
@@ -562,6 +564,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x1a86), /* Nanjing Qinheng Microelectronics (WCH) */
XPAD_XBOX360_VENDOR(0x1bad), /* Harmonix Rock Band guitar and drums */
XPAD_XBOX360_VENDOR(0x1ee9), /* ZOTAC Technology Limited */
+ XPAD_XBOX360_VENDOR(0x20bc), /* BETOP wireless dongles */
XPAD_XBOX360_VENDOR(0x20d6), /* PowerA controllers */
XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA controllers */
XPAD_XBOX360_VENDOR(0x2345), /* Machenike Controllers */
--
2.43.0
^ permalink raw reply related
* [PATCH] Input: libps2 - embed WARN_ON(1) macros into their enclosing if statements
From: Max Brener @ 2026-02-05 17:27 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Max Brener
Make WARN_ON(1) statements embedded inside their respective 'if' expressions,
to improve code clarity.
Signed-off-by: Max Brener <linmaxi@gmail.com>
---
drivers/input/serio/libps2.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
index 269df83a167d..05b64277aecd 100644
--- a/drivers/input/serio/libps2.c
+++ b/drivers/input/serio/libps2.c
@@ -154,10 +154,8 @@ EXPORT_SYMBOL(ps2_end_command);
*/
void ps2_drain(struct ps2dev *ps2dev, size_t maxbytes, unsigned int timeout)
{
- if (maxbytes > sizeof(ps2dev->cmdbuf)) {
- WARN_ON(1);
+ if (WARN_ON(maxbytes > sizeof(ps2dev->cmdbuf)))
maxbytes = sizeof(ps2dev->cmdbuf);
- }
ps2_begin_command(ps2dev);
@@ -270,15 +268,11 @@ int __ps2_command(struct ps2dev *ps2dev, u8 *param, unsigned int command)
int i;
u8 send_param[16];
- if (receive > sizeof(ps2dev->cmdbuf)) {
- WARN_ON(1);
+ if (WARN_ON(receive > sizeof(ps2dev->cmdbuf)))
return -EINVAL;
- }
- if (send && !param) {
- WARN_ON(1);
+ if (WARN_ON(send && !param))
return -EINVAL;
- }
memcpy(send_param, param, send);
--
2.43.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