* Re: [PATCH v1 3/3] dt-bindings: google,cros-ec-keyb: add fn-key and f-keymap props
From: Dmitry Torokhov @ 2025-12-17 18:05 UTC (permalink / raw)
To: Fabio Baltieri
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Benson Leung,
Guenter Roeck, Tzung-Bi Shih, Simon Glass, linux-input,
devicetree, chrome-platform, linux-kernel
In-Reply-To: <aUFPKni-iFkxQQGu@google.com>
Hi Fabio,
On Tue, Dec 16, 2025 at 12:23:06PM +0000, Fabio Baltieri wrote:
> Hi Dmitry,
>
> On Thu, Dec 11, 2025 at 08:44:02PM -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 10, 2025 at 06:00:29PM +0000, Fabio Baltieri wrote:
> > > Hey Rob, thanks for the review.
> > >
> > > On Tue, Dec 09, 2025 at 01:22:43PM -0600, Rob Herring wrote:
> > > > On Tue, Dec 09, 2025 at 03:47:06PM +0000, Fabio Baltieri wrote:
> > > > > + fn-key:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > > + description: |
> > > > > + An u32 containing the coordinate of the Fn key, use the MATRIX_KEY(row,
> > > > > + col, code) macro, code is ignored.
> > > > > +
> > > > > + fn-keymap:
> > > >
> > > > If keymap is linux,keymap, then this should perhaps be linux,fn-keymap.
> > > > Depends if we still think linux,keymap is Linux specific?
> > >
> > > I'm open for suggestions, trying to understand the pattern, these are
> > > specific to this binding I think if anything they should be
> > > google,fn-key and google,fn-keymap, similarly to the existing
> > > google,needs-ghost-filter -- no idea why function-row-physmap was not
> > > prefixed but I guess it slipped in and now it's not worth changing it.
> >
> > Just double the number of rows in the regular keymap to accommodate the
> > FN modifier, no need for separate keymap. Also no need to have fn-key
> > property, use whatever key that reports KEY_FN. See how it is done in
> > drivers/input/keyboard/tegra-kbc.c
>
> Had a look at the tegra-kbc driver as you suggested, first thing it
> seems like the fn-key functionality there is dead code since 2013,
> `use_fn_map` could only be enabled with platform data, not OF, and that
> has been removed in 3a495aeada2b, as it stands kbc->use_fn_map can only
> be false. I could send a patch to rip off that code if you want me to,
> clearly it hasn't been used in a while (unless I'm missing something).
I guess you are right, we shoudl clean that up. We have another newer
driver that uses the same approach:
drivers/input/keyboard/pinephone-keyboard.c
> About the extended fn map, I've two problems with it:
> - it seems very wasteful: the normal map is loaded in a linear array
> so it can be access directly, which make sense as that's typically
> very densely populated, but in the case of the fn keys that's going to
> be mostly empty, I'd expect ~20 keys top from a 18x8 matrix. So that
> would waste load of space, direct access is good but for ~20 keys I
> think it's fine to scan it, especially since it only happens when Fn
> is pressed.
I am not concerned with this, as this is a singleton device. You
probably "waste" as much space in the code segment by implementing the
custom scanning logic. Additionally with the consolidated keymap
approach you are not breaking ioctls dealing with setting and retrieving
key codes.
> - I'd end up with two values for cols kicking around the driver, the
> real one and the one used in the map, which I feel adds confusing in
> the code.
Not sure I follow. You still have the same row and col reported, just
when figuring out the final keycode you need to add an offset.
> - more importantly, one would have to keep the offset in mind when
> setting the keys in dt, we rely on OEM doing this and I think having a
Do we now? I thought we retain greater control over this. Maybe we
should sync internally.
> separate property with a meaningful name and a map with the same
> row,col and different code is more intuitive and would make their life
> easier, especially since we ship with keyboard of different size
> and the offset would be different depending on the device.
>
> As for the fn-key property, unfortunately based on past experience I'd
> expect such OEM to want to change that code, I could specify the code
> rather than the row,col but I would not plain hardcode. Even my
> (thinkpad) laptop sends KEY_WAKEUP for Fn.
Again, we need to make sure we control OEMs better. On Lenovo Fn sends
wakeup only if it is not combined with another key, so it really has
custom logic with events delivered either through the main AT keyboard
or through custom interface in thinkpad platform driver. We do not need
this in oiur designs.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Rob Herring @ 2025-12-17 13:34 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Krzysztof Kozlowski, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Heiko Stuebner, kernel,
linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <6778765.lOV4Wx5bFT@workhorse>
On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > property. This makes it impossible to model devices that have ADC inputs
> > > that should generate switch events.
> >
> > The solution is to use unevaluatedProps instead, which also allows
> > dropping other properties.
> >
> > Best regards,
> > Krzysztof
> >
> >
>
> Hi Krzysztof,
>
> to understand the motivation behind this suggestion correctly:
> are the "linux," vendor prefixed properties, especially with regards
> to key codes, generally a bit of a thorn in the side of DT bindings
> maintainers?
Not really. Most have existed for decades. New ones get extra scrutiny
and often end up dropping the linux prefix.
> I'd imagine so since they technically tie the DT to a specific OS
> kernel (though of course, others are free to translate those key
> codes). And the whole idea of configuring which code is emitted
> from something is basically abusing DT for configuring software
> rather than describing hardware.
>
> I'm mainly interested because this is a thought that has been in
> the back of my mind for a while now, and I'm curious if the DT
> binding maintainers happen to have arrived at the same impassé,
> where linux,input-type et al abuse the DT model for something we
> would tell any other vendor not to abuse it for, but no better
> solution exists right now to achieve the same thing.
Not sure what the BSDs do here. It's never come up that I remember. Best
I can tell is they just make it a userspace problem. So every possible
keyboard needs a keymap file. Though I'm not sure how that would work
with GPIO keys as you don't really have a scan code.
Rob
^ permalink raw reply
* [syzbot] Monthly input report (Dec 2025)
From: syzbot @ 2025-12-17 13:12 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 3 new issues were detected and 0 were fixed.
In total, 22 issues are still open and 63 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 3202 Yes WARNING in cm109_urb_irq_callback/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
<2> 1621 No possible deadlock in evdev_pass_values (2)
https://syzkaller.appspot.com/bug?extid=13d3cb2a3dc61e6092f5
<3> 241 Yes KASAN: slab-out-of-bounds Read in mcp2221_raw_event (2)
https://syzkaller.appspot.com/bug?extid=1018672fe70298606e5f
<4> 107 Yes WARNING in cm109_input_open/usb_submit_urb (3)
https://syzkaller.appspot.com/bug?extid=ac0f9c4cc1e034160492
<5> 74 Yes possible deadlock in uinput_request_submit
https://syzkaller.appspot.com/bug?extid=159077b1355b8cd72757
<6> 47 No KASAN: slab-use-after-free Read in report_descriptor_read
https://syzkaller.appspot.com/bug?extid=bc537ca7a0efe33988eb
<7> 46 Yes WARNING in cm109_urb_irq_callback
https://syzkaller.appspot.com/bug?extid=c708736c2ec142a386fd
<8> 13 Yes INFO: task hung in console_callback (6)
https://syzkaller.appspot.com/bug?extid=6027421afa74a2ba440d
<9> 3 No WARNING in cm109_input_open
https://syzkaller.appspot.com/bug?extid=fed3fab8533934671abc
<10> 2 No possible deadlock in tasklet_action_common
https://syzkaller.appspot.com/bug?extid=16c5be44e508252dc97a
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Nicolas Frattaroli @ 2025-12-17 12:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner, kernel, linux-input,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20251217-tough-ultra-junglefowl-f1a9ae@quoll>
On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > property. This makes it impossible to model devices that have ADC inputs
> > that should generate switch events.
>
> The solution is to use unevaluatedProps instead, which also allows
> dropping other properties.
>
> Best regards,
> Krzysztof
>
>
Hi Krzysztof,
to understand the motivation behind this suggestion correctly:
are the "linux," vendor prefixed properties, especially with regards
to key codes, generally a bit of a thorn in the side of DT bindings
maintainers?
I'd imagine so since they technically tie the DT to a specific OS
kernel (though of course, others are free to translate those key
codes). And the whole idea of configuring which code is emitted
from something is basically abusing DT for configuring software
rather than describing hardware.
I'm mainly interested because this is a thought that has been in
the back of my mind for a while now, and I'm curious if the DT
binding maintainers happen to have arrived at the same impassé,
where linux,input-type et al abuse the DT model for something we
would tell any other vendor not to abuse it for, but no better
solution exists right now to achieve the same thing.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: sitronix,st1232: Add Sitronix ST1624
From: Krzysztof Kozlowski @ 2025-12-17 8:40 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, Bastian Hecht,
linux-input, devicetree, linux-kernel
In-Reply-To: <20251215212524.3318311-1-robh@kernel.org>
On Mon, Dec 15, 2025 at 03:25:24PM -0600, Rob Herring (Arm) wrote:
> Add the Sitronix ST1624 which is compatible with ST1633.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> .../bindings/input/touchscreen/sitronix,st1232.yaml | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Krzysztof Kozlowski @ 2025-12-17 8:31 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner, kernel, linux-input,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20251215-rock4d-audio-v2-1-82a61de39b4c@collabora.com>
On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> property. This makes it impossible to model devices that have ADC inputs
> that should generate switch events.
The solution is to use unevaluatedProps instead, which also allows
dropping other properties.
Best regards,
Krzysztof
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS aed3716db7fff74919cc5775ca3a80c8bb246489
From: kernel test robot @ 2025-12-17 7:01 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: aed3716db7fff74919cc5775ca3a80c8bb246489 Input: i8042 - add TUXEDO InfinityBook Max Gen10 AMD to i8042 quirk table
elapsed time: 1460m
configs tested: 292
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig clang-22
arc allyesconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc randconfig-001-20251216 gcc-12.5.0
arc randconfig-001-20251217 clang-22
arc randconfig-002-20251216 gcc-12.5.0
arc randconfig-002-20251217 clang-22
arm allnoconfig clang-22
arm allnoconfig gcc-15.1.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.1.0
arm am200epdkit_defconfig clang-22
arm aspeed_g4_defconfig clang-22
arm bcm2835_defconfig clang-22
arm defconfig gcc-15.1.0
arm ep93xx_defconfig clang-22
arm ixp4xx_defconfig clang-22
arm lpc18xx_defconfig clang-22
arm nhk8815_defconfig clang-22
arm randconfig-001-20251216 gcc-10.5.0
arm randconfig-001-20251217 clang-22
arm randconfig-002-20251216 gcc-8.5.0
arm randconfig-002-20251217 clang-22
arm randconfig-003-20251216 gcc-11.5.0
arm randconfig-003-20251217 clang-22
arm randconfig-004-20251216 clang-19
arm randconfig-004-20251217 clang-22
arm vt8500_v6_v7_defconfig clang-22
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.1.0
arm64 defconfig gcc-15.1.0
arm64 randconfig-001-20251217 clang-22
arm64 randconfig-002-20251217 clang-22
arm64 randconfig-003-20251217 clang-22
arm64 randconfig-004-20251217 clang-22
csky allmodconfig gcc-15.1.0
csky allnoconfig gcc-15.1.0
csky defconfig gcc-15.1.0
csky randconfig-001-20251217 clang-22
csky randconfig-002-20251217 clang-22
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.1.0
hexagon allnoconfig clang-22
hexagon allnoconfig gcc-15.1.0
hexagon defconfig gcc-15.1.0
hexagon randconfig-001-20251216 clang-22
hexagon randconfig-001-20251217 gcc-11.5.0
hexagon randconfig-002-20251216 clang-19
hexagon randconfig-002-20251217 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.1.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20251216 clang-20
i386 buildonly-randconfig-001-20251217 clang-20
i386 buildonly-randconfig-002-20251216 gcc-14
i386 buildonly-randconfig-002-20251217 clang-20
i386 buildonly-randconfig-003-20251216 gcc-14
i386 buildonly-randconfig-003-20251217 clang-20
i386 buildonly-randconfig-004-20251216 gcc-14
i386 buildonly-randconfig-004-20251217 clang-20
i386 buildonly-randconfig-005-20251216 clang-20
i386 buildonly-randconfig-005-20251217 clang-20
i386 buildonly-randconfig-006-20251216 gcc-14
i386 buildonly-randconfig-006-20251217 clang-20
i386 defconfig gcc-15.1.0
i386 randconfig-001-20251217 clang-20
i386 randconfig-001-20251217 gcc-14
i386 randconfig-002-20251217 clang-20
i386 randconfig-002-20251217 gcc-14
i386 randconfig-003-20251217 clang-20
i386 randconfig-003-20251217 gcc-14
i386 randconfig-004-20251217 gcc-14
i386 randconfig-005-20251217 gcc-13
i386 randconfig-005-20251217 gcc-14
i386 randconfig-006-20251217 clang-20
i386 randconfig-006-20251217 gcc-14
i386 randconfig-007-20251217 clang-20
i386 randconfig-007-20251217 gcc-14
i386 randconfig-011-20251216 gcc-13
i386 randconfig-011-20251217 clang-20
i386 randconfig-012-20251216 clang-20
i386 randconfig-012-20251217 clang-20
i386 randconfig-013-20251216 gcc-13
i386 randconfig-013-20251217 clang-20
i386 randconfig-014-20251216 gcc-13
i386 randconfig-014-20251217 clang-20
i386 randconfig-015-20251216 clang-20
i386 randconfig-015-20251217 clang-20
i386 randconfig-016-20251216 clang-20
i386 randconfig-016-20251217 clang-20
i386 randconfig-017-20251216 clang-20
i386 randconfig-017-20251217 clang-20
loongarch allmodconfig clang-22
loongarch allnoconfig clang-22
loongarch allnoconfig gcc-15.1.0
loongarch defconfig clang-19
loongarch randconfig-001-20251216 gcc-15.1.0
loongarch randconfig-001-20251217 gcc-11.5.0
loongarch randconfig-002-20251216 clang-22
loongarch randconfig-002-20251217 gcc-11.5.0
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.1.0
m68k defconfig clang-19
m68k defconfig gcc-15.1.0
m68k mac_defconfig clang-22
m68k virt_defconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig clang-19
microblaze defconfig gcc-15.1.0
mips allmodconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips allyesconfig gcc-15.1.0
mips bcm63xx_defconfig clang-22
mips gcw0_defconfig clang-22
mips maltaaprp_defconfig clang-22
mips rb532_defconfig clang-18
mips rb532_defconfig clang-22
nios2 10m50_defconfig gcc-11.5.0
nios2 3c120_defconfig gcc-15.1.0
nios2 allmodconfig clang-22
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20251216 gcc-8.5.0
nios2 randconfig-001-20251217 gcc-11.5.0
nios2 randconfig-002-20251216 gcc-11.5.0
nios2 randconfig-002-20251217 gcc-11.5.0
openrisc allmodconfig clang-22
openrisc allmodconfig gcc-15.1.0
openrisc allnoconfig clang-22
openrisc allnoconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig clang-22
parisc allnoconfig gcc-15.1.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20251216 gcc-11.5.0
parisc randconfig-001-20251217 gcc-8.5.0
parisc randconfig-002-20251216 gcc-11.5.0
parisc randconfig-002-20251217 gcc-8.5.0
parisc64 defconfig clang-19
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig clang-22
powerpc allnoconfig gcc-15.1.0
powerpc chrp32_defconfig gcc-15.1.0
powerpc ebony_defconfig gcc-15.1.0
powerpc randconfig-001-20251216 clang-22
powerpc randconfig-001-20251217 gcc-8.5.0
powerpc randconfig-002-20251216 clang-19
powerpc randconfig-002-20251217 gcc-8.5.0
powerpc tqm8560_defconfig clang-22
powerpc64 randconfig-001-20251216 clang-22
powerpc64 randconfig-001-20251217 gcc-8.5.0
powerpc64 randconfig-002-20251216 clang-17
powerpc64 randconfig-002-20251217 gcc-8.5.0
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv defconfig gcc-15.1.0
riscv nommu_k210_defconfig gcc-15.1.0
riscv randconfig-001-20251216 gcc-9.5.0
riscv randconfig-001-20251217 clang-18
riscv randconfig-002-20251216 clang-17
riscv randconfig-002-20251217 clang-18
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 defconfig gcc-15.1.0
s390 randconfig-001-20251216 clang-22
s390 randconfig-001-20251217 clang-18
s390 randconfig-002-20251216 clang-20
s390 randconfig-002-20251217 clang-18
sh allmodconfig gcc-15.1.0
sh allnoconfig clang-22
sh allnoconfig gcc-15.1.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.1.0
sh apsh4a3a_defconfig gcc-15.1.0
sh defconfig gcc-14
sh dreamcast_defconfig gcc-15.1.0
sh randconfig-001-20251216 gcc-13.4.0
sh randconfig-001-20251217 clang-18
sh randconfig-002-20251216 gcc-12.5.0
sh randconfig-002-20251217 clang-18
sh rsk7203_defconfig gcc-15.1.0
sh se7750_defconfig clang-22
sh secureedge5410_defconfig gcc-15.1.0
sh urquell_defconfig gcc-15.1.0
sparc allnoconfig clang-22
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20251217 gcc-15.1.0
sparc randconfig-002-20251217 gcc-15.1.0
sparc64 alldefconfig clang-22
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20251217 clang-20
sparc64 randconfig-001-20251217 gcc-15.1.0
sparc64 randconfig-002-20251217 gcc-12.5.0
sparc64 randconfig-002-20251217 gcc-15.1.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-14
um allyesconfig gcc-15.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20251217 clang-22
um randconfig-001-20251217 gcc-15.1.0
um randconfig-002-20251217 clang-22
um randconfig-002-20251217 gcc-15.1.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20251217 clang-20
x86_64 buildonly-randconfig-001-20251217 gcc-14
x86_64 buildonly-randconfig-002-20251217 clang-20
x86_64 buildonly-randconfig-002-20251217 gcc-14
x86_64 buildonly-randconfig-003-20251217 gcc-13
x86_64 buildonly-randconfig-003-20251217 gcc-14
x86_64 buildonly-randconfig-004-20251217 gcc-14
x86_64 buildonly-randconfig-005-20251217 gcc-14
x86_64 buildonly-randconfig-006-20251217 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20251216 gcc-14
x86_64 randconfig-001-20251217 clang-20
x86_64 randconfig-002-20251216 clang-20
x86_64 randconfig-002-20251217 clang-20
x86_64 randconfig-003-20251216 clang-20
x86_64 randconfig-003-20251217 clang-20
x86_64 randconfig-004-20251216 gcc-14
x86_64 randconfig-004-20251217 clang-20
x86_64 randconfig-005-20251216 clang-20
x86_64 randconfig-005-20251217 clang-20
x86_64 randconfig-006-20251216 gcc-14
x86_64 randconfig-006-20251217 clang-20
x86_64 randconfig-011-20251216 gcc-14
x86_64 randconfig-011-20251217 gcc-14
x86_64 randconfig-012-20251216 gcc-14
x86_64 randconfig-012-20251217 gcc-14
x86_64 randconfig-013-20251216 clang-20
x86_64 randconfig-013-20251217 gcc-14
x86_64 randconfig-014-20251216 clang-20
x86_64 randconfig-014-20251217 gcc-14
x86_64 randconfig-015-20251216 clang-20
x86_64 randconfig-015-20251217 gcc-14
x86_64 randconfig-016-20251216 clang-20
x86_64 randconfig-016-20251217 gcc-14
x86_64 randconfig-071-20251217 gcc-14
x86_64 randconfig-072-20251217 gcc-14
x86_64 randconfig-073-20251217 gcc-14
x86_64 randconfig-074-20251217 gcc-14
x86_64 randconfig-075-20251217 gcc-14
x86_64 randconfig-076-20251217 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allnoconfig gcc-15.1.0
xtensa allyesconfig clang-22
xtensa allyesconfig gcc-15.1.0
xtensa randconfig-001-20251217 gcc-15.1.0
xtensa randconfig-001-20251217 gcc-8.5.0
xtensa randconfig-002-20251217 gcc-15.1.0
xtensa smp_lx200_defconfig gcc-15.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS d79f302f2f9829d04b0ab6181c38716c5a68804d
From: kernel test robot @ 2025-12-17 7:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: d79f302f2f9829d04b0ab6181c38716c5a68804d dt-bindings: input: touchscreen: sitronix,st1232: Add Sitronix ST1624
elapsed time: 1460m
configs tested: 264
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc randconfig-001-20251216 gcc-12.5.0
arc randconfig-001-20251217 clang-22
arc randconfig-002-20251216 gcc-12.5.0
arc randconfig-002-20251217 clang-22
arm allnoconfig clang-22
arm allnoconfig gcc-15.1.0
arm allyesconfig gcc-15.1.0
arm defconfig clang-22
arm imxrt_defconfig clang-22
arm milbeaut_m10v_defconfig clang-19
arm mps2_defconfig clang-22
arm mvebu_v7_defconfig clang-22
arm randconfig-001-20251216 gcc-10.5.0
arm randconfig-001-20251217 clang-22
arm randconfig-002-20251216 gcc-8.5.0
arm randconfig-002-20251217 clang-22
arm randconfig-003-20251216 gcc-11.5.0
arm randconfig-003-20251217 clang-22
arm randconfig-004-20251216 clang-19
arm randconfig-004-20251217 clang-22
arm vt8500_v6_v7_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 defconfig gcc-15.1.0
arm64 randconfig-001-20251217 gcc-8.5.0
arm64 randconfig-002-20251217 clang-22
arm64 randconfig-003-20251217 clang-22
arm64 randconfig-004-20251217 clang-20
csky alldefconfig gcc-15.1.0
csky allmodconfig gcc-15.1.0
csky allnoconfig gcc-15.1.0
csky defconfig gcc-15.1.0
csky randconfig-001-20251217 gcc-15.1.0
csky randconfig-002-20251217 gcc-9.5.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.1.0
hexagon allnoconfig clang-22
hexagon allnoconfig gcc-15.1.0
hexagon defconfig clang-22
hexagon randconfig-001-20251216 clang-22
hexagon randconfig-001-20251217 gcc-11.5.0
hexagon randconfig-002-20251216 clang-19
hexagon randconfig-002-20251217 gcc-11.5.0
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.1.0
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20251216 clang-20
i386 buildonly-randconfig-002-20251216 gcc-14
i386 buildonly-randconfig-003-20251216 gcc-14
i386 buildonly-randconfig-004-20251216 gcc-14
i386 buildonly-randconfig-005-20251216 clang-20
i386 buildonly-randconfig-006-20251216 gcc-14
i386 defconfig clang-20
i386 randconfig-001-20251216 clang-20
i386 randconfig-001-20251217 clang-20
i386 randconfig-001-20251217 gcc-14
i386 randconfig-002-20251216 clang-20
i386 randconfig-002-20251217 clang-20
i386 randconfig-002-20251217 gcc-14
i386 randconfig-003-20251216 gcc-14
i386 randconfig-003-20251217 clang-20
i386 randconfig-003-20251217 gcc-14
i386 randconfig-004-20251216 gcc-14
i386 randconfig-004-20251217 gcc-14
i386 randconfig-005-20251216 gcc-14
i386 randconfig-005-20251217 gcc-13
i386 randconfig-005-20251217 gcc-14
i386 randconfig-006-20251216 gcc-14
i386 randconfig-006-20251217 clang-20
i386 randconfig-006-20251217 gcc-14
i386 randconfig-007-20251216 clang-20
i386 randconfig-007-20251217 clang-20
i386 randconfig-007-20251217 gcc-14
i386 randconfig-011-20251216 gcc-13
i386 randconfig-011-20251217 clang-20
i386 randconfig-012-20251216 clang-20
i386 randconfig-012-20251217 clang-20
i386 randconfig-013-20251216 gcc-13
i386 randconfig-013-20251217 clang-20
i386 randconfig-014-20251216 gcc-13
i386 randconfig-014-20251217 clang-20
i386 randconfig-015-20251216 clang-20
i386 randconfig-015-20251217 clang-20
i386 randconfig-016-20251216 clang-20
i386 randconfig-016-20251217 clang-20
i386 randconfig-017-20251216 clang-20
i386 randconfig-017-20251217 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch allnoconfig gcc-15.1.0
loongarch defconfig clang-19
loongarch randconfig-001-20251216 gcc-15.1.0
loongarch randconfig-001-20251217 gcc-11.5.0
loongarch randconfig-002-20251216 clang-22
loongarch randconfig-002-20251217 gcc-11.5.0
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
m68k defconfig clang-19
m68k defconfig gcc-15.1.0
m68k virt_defconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig clang-19
microblaze defconfig gcc-15.1.0
mips allmodconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips allyesconfig gcc-15.1.0
mips eyeq6_defconfig clang-22
mips rbtx49xx_defconfig gcc-15.1.0
nios2 3c120_defconfig gcc-15.1.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20251216 gcc-8.5.0
nios2 randconfig-001-20251217 gcc-11.5.0
nios2 randconfig-002-20251216 gcc-11.5.0
nios2 randconfig-002-20251217 gcc-11.5.0
openrisc allmodconfig gcc-15.1.0
openrisc allnoconfig clang-22
openrisc allnoconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig clang-22
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20251216 gcc-11.5.0
parisc randconfig-001-20251217 gcc-8.5.0
parisc randconfig-002-20251216 gcc-11.5.0
parisc randconfig-002-20251217 gcc-8.5.0
parisc64 defconfig clang-19
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig clang-22
powerpc allnoconfig gcc-15.1.0
powerpc chrp32_defconfig gcc-15.1.0
powerpc ebony_defconfig gcc-15.1.0
powerpc ppa8548_defconfig gcc-15.1.0
powerpc randconfig-001-20251216 clang-22
powerpc randconfig-001-20251217 gcc-8.5.0
powerpc randconfig-002-20251216 clang-19
powerpc randconfig-002-20251217 gcc-8.5.0
powerpc sequoia_defconfig clang-17
powerpc xes_mpc85xx_defconfig gcc-15.1.0
powerpc64 randconfig-001-20251216 clang-22
powerpc64 randconfig-001-20251217 gcc-8.5.0
powerpc64 randconfig-002-20251216 clang-17
powerpc64 randconfig-002-20251217 gcc-8.5.0
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv defconfig gcc-15.1.0
riscv nommu_k210_defconfig gcc-15.1.0
riscv randconfig-001-20251216 gcc-9.5.0
riscv randconfig-002-20251216 clang-17
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 defconfig gcc-15.1.0
s390 randconfig-001-20251216 clang-22
s390 randconfig-002-20251216 clang-20
sh allmodconfig gcc-15.1.0
sh allnoconfig clang-22
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-14
sh defconfig gcc-15.1.0
sh randconfig-001-20251216 gcc-13.4.0
sh randconfig-002-20251216 gcc-12.5.0
sh rsk7203_defconfig gcc-15.1.0
sh se7712_defconfig gcc-15.1.0
sh se7724_defconfig gcc-15.1.0
sh se7751_defconfig gcc-15.1.0
sh secureedge5410_defconfig gcc-15.1.0
sparc allnoconfig clang-22
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20251216 gcc-8.5.0
sparc randconfig-002-20251216 gcc-14.3.0
sparc64 allmodconfig clang-22
sparc64 defconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20251216 clang-22
sparc64 randconfig-002-20251216 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-14
um allyesconfig gcc-15.1.0
um defconfig clang-22
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20251216 gcc-12
um randconfig-002-20251216 gcc-14
um x86_64_defconfig clang-22
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20251216 clang-20
x86_64 buildonly-randconfig-002-20251216 gcc-14
x86_64 buildonly-randconfig-003-20251216 clang-20
x86_64 buildonly-randconfig-004-20251216 clang-20
x86_64 buildonly-randconfig-005-20251216 gcc-14
x86_64 buildonly-randconfig-006-20251216 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20251216 gcc-14
x86_64 randconfig-002-20251216 clang-20
x86_64 randconfig-003-20251216 clang-20
x86_64 randconfig-004-20251216 gcc-14
x86_64 randconfig-005-20251216 clang-20
x86_64 randconfig-006-20251216 gcc-14
x86_64 randconfig-011-20251216 gcc-14
x86_64 randconfig-011-20251217 gcc-14
x86_64 randconfig-012-20251216 gcc-14
x86_64 randconfig-012-20251217 gcc-14
x86_64 randconfig-013-20251216 clang-20
x86_64 randconfig-013-20251217 gcc-14
x86_64 randconfig-014-20251216 clang-20
x86_64 randconfig-014-20251217 gcc-14
x86_64 randconfig-015-20251216 clang-20
x86_64 randconfig-015-20251217 gcc-14
x86_64 randconfig-016-20251216 clang-20
x86_64 randconfig-016-20251217 gcc-14
x86_64 randconfig-071-20251216 clang-20
x86_64 randconfig-071-20251217 clang-20
x86_64 randconfig-072-20251216 gcc-14
x86_64 randconfig-072-20251217 gcc-13
x86_64 randconfig-073-20251216 gcc-14
x86_64 randconfig-073-20251217 gcc-14
x86_64 randconfig-074-20251216 gcc-12
x86_64 randconfig-074-20251217 clang-20
x86_64 randconfig-075-20251216 clang-20
x86_64 randconfig-075-20251217 clang-20
x86_64 randconfig-076-20251216 clang-20
x86_64 randconfig-076-20251217 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allnoconfig gcc-15.1.0
xtensa allyesconfig gcc-15.1.0
xtensa randconfig-001-20251216 gcc-8.5.0
xtensa randconfig-002-20251216 gcc-12.5.0
xtensa smp_lx200_defconfig gcc-15.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2 RESEND 2/2] Input: psmouse - Replace flush_workqueue() with disable_delayed_work_sync()
From: Duoming Zhou @ 2025-12-17 3:00 UTC (permalink / raw)
To: linux-input
Cc: linux-kernel, dmitry.torokhov, pali, kuba, alexander.deucher,
akpm, johannes.berg, pkshih, hverkuil+cisco, andriy.shevchenko,
tglx, mingo, Duoming Zhou
In-Reply-To: <cover.1765939397.git.duoming@zju.edu.cn>
The original code uses flush_workqueue() in psmouse_disconnect() to
ensure the completion of both resync_work and dev3_register_work.
Given that alps_disconnect() already uses disable_delayed_work_sync()
to cancel dev3_register_work, replacing flush_workqueue() with
disable_delayed_work_sync(&psmouse->resync_work) is more robust
and efficient.
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
---
Changes in v2:
- focus on the robustness and efficiency improvements of disable_delayed_work_sync(), not on the UAF aspect.
drivers/input/mouse/psmouse-base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
index 77ea7da3b1c..eb41c553e80 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -1484,7 +1484,7 @@ static void psmouse_disconnect(struct serio *serio)
/* make sure we don't have a resync in progress */
mutex_unlock(&psmouse_mutex);
- flush_workqueue(kpsmoused_wq);
+ disable_delayed_work_sync(&psmouse->resync_work);
mutex_lock(&psmouse_mutex);
if (serio->parent && serio->id.type == SERIO_PS_PSTHRU) {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 RESEND 0/2] Input: alps/psmouse: Fix UAF bugs and improve workqueue synchronization
From: Duoming Zhou @ 2025-12-17 3:00 UTC (permalink / raw)
To: linux-input
Cc: linux-kernel, dmitry.torokhov, pali, kuba, alexander.deucher,
akpm, johannes.berg, pkshih, hverkuil+cisco, andriy.shevchenko,
tglx, mingo, Duoming Zhou
This patch series addresses use-after-free bugs in the ALPS
touchpad driver and enhances workqueue handling efficiency
in the psmouse subsystem.
The first patch fixes a critical use-after-free race condition
in the ALPS driver where dev3_register_work could be scheduled
after the alps_data structure was already freed. This was caused
by insufficient synchronization during device disconnection,
where flush_workqueue() couldn't prevent subsequent work item
submissions.
The second patch optimizes the psmouse disconnect path by replacing
flush_workqueue() with disable_delayed_work_sync() for better
efficiency and robustness.
Duoming Zhou (2):
Input: alps - fix use-after-free bugs caused by dev3_register_work
Input: psmouse - Replace flush_workqueue() with
disable_delayed_work_sync()
drivers/input/mouse/alps.c | 1 +
drivers/input/mouse/psmouse-base.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
2.34.1
^ permalink raw reply
* [PATCH v2 RESEND 1/2] Input: alps - fix use-after-free bugs caused by dev3_register_work
From: Duoming Zhou @ 2025-12-17 3:00 UTC (permalink / raw)
To: linux-input
Cc: linux-kernel, dmitry.torokhov, pali, kuba, alexander.deucher,
akpm, johannes.berg, pkshih, hverkuil+cisco, andriy.shevchenko,
tglx, mingo, Duoming Zhou, stable
In-Reply-To: <cover.1765939397.git.duoming@zju.edu.cn>
The dev3_register_work delayed work item is initialized within
alps_reconnect() and scheduled upon receipt of the first bare
PS/2 packet from an external PS/2 device connected to the ALPS
touchpad. During device detachment, the original implementation
calls flush_workqueue() in psmouse_disconnect() to ensure
completion of dev3_register_work. However, the flush_workqueue()
in psmouse_disconnect() only blocks and waits for work items that
were already queued to the workqueue prior to its invocation. Any
work items submitted after flush_workqueue() is called are not
included in the set of tasks that the flush operation awaits.
This means that after flush_workqueue() has finished executing,
the dev3_register_work could still be scheduled. Although the
psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),
the scheduling of dev3_register_work remains unaffected.
The race condition can occur as follows:
CPU 0 (cleanup path) | CPU 1 (delayed work)
psmouse_disconnect() |
psmouse_set_state() |
flush_workqueue() | alps_report_bare_ps2_packet()
alps_disconnect() | psmouse_queue_work()
kfree(priv); // FREE | alps_register_bare_ps2_mouse()
| priv = container_of(work...); // USE
| priv->dev3 // USE
Add disable_delayed_work_sync() in alps_disconnect() to ensure
that dev3_register_work is properly canceled and prevented from
executing after the alps_data structure has been deallocated.
This bug is identified by static analysis.
Fixes: 04aae283ba6a ("Input: ALPS - do not mix trackstick and external PS/2 mouse data")
Cc: stable@kernel.org
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
---
Changes in v2:
- Split the original patch into two separate patches (alps and psmouse-base).
drivers/input/mouse/alps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index d0cb9fb9482..df8953a5196 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2975,6 +2975,7 @@ static void alps_disconnect(struct psmouse *psmouse)
psmouse_reset(psmouse);
timer_shutdown_sync(&priv->timer);
+ disable_delayed_work_sync(&priv->dev3_register_work);
if (priv->dev2)
input_unregister_device(priv->dev2);
if (!IS_ERR_OR_NULL(priv->dev3))
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 1/2] Input: add ABS_SND_PROFILE
From: David Heidelberg @ 2025-12-16 14:06 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Casey Connolly, Guido Günther
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles
In-Reply-To: <20251113-op6-tri-state-v8-1-54073f3874bc@ixit.cz>
On 13/11/2025 17:02, David Heidelberg via B4 Relay wrote:
> From: Gergo Koteles <soyer@irl.hu>
>
> ABS_SND_PROFILE used to describe the state of a multi-value sound profile
> switch. This will be used for the alert-slider on OnePlus phones or other
> phones.
>
> Profile values added as SND_PROFLE_(SILENT|VIBRATE|RING) identifiers
> to input-event-codes.h so they can be used from DTS.
>
> Signed-off-by: Gergo Koteles <soyer@irl.hu>
> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> Tested-by: Guido Günther <agx@sigxcpu.org> # oneplus,fajita & oneplus,enchilada
> Reviewed-by: Guido Günther <agx@sigxcpu.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Documentation/input/event-codes.rst | 6 ++++++
> drivers/hid/hid-debug.c | 1 +
> include/uapi/linux/input-event-codes.h | 9 +++++++++
> 3 files changed, 16 insertions(+)
>
Hello Dmitry, can I count this one reaches Linux 6.20?
Thank you
David
--
David Heidelberg
^ permalink raw reply
* Re: (subset) [PATCH v6 0/7] mfd: macsmc: add rtc, hwmon and hid subdevices
From: Sven Peter @ 2025-12-16 12:37 UTC (permalink / raw)
To: Janne Grunau, Alyssa Rosenzweig, Neal Gompa, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
James Calligeros
Cc: Sven Peter, asahi, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, linux-hwmon, linux-input, linux-doc, Hector Martin
In-Reply-To: <20251215-macsmc-subdevs-v6-0-0518cb5f28ae@gmail.com>
On Mon, 15 Dec 2025 19:37:44 +1000, James Calligeros wrote:
> This series adds support for the remaining SMC subdevices. These are the
> RTC, hwmon, and HID devices. They are being submitted together as the RTC
> and hwmon drivers both require changes to the SMC DT schema.
>
> The RTC driver is responsible for getting and setting the system clock,
> and requires an NVMEM cell. This series replaces Sven's original RTC driver
> submission [1].
>
> [...]
Applied to local tree (apple-soc/dt-6.20), thanks!
[6/7] arm64: dts: apple: t8103,t60xx,t8112: Add SMC RTC node
https://github.com/AsahiLinux/linux/commit/faf317d4c705
Best regards,
--
Sven Peter <sven@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 3/3] dt-bindings: google,cros-ec-keyb: add fn-key and f-keymap props
From: Fabio Baltieri @ 2025-12-16 12:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Benson Leung,
Guenter Roeck, Tzung-Bi Shih, Simon Glass, linux-input,
devicetree, chrome-platform, linux-kernel
In-Reply-To: <2gd2npolfpo5jruwraamwpn3wurm7w447jnwsbcfonmhos2owf@ejrqiz3qdxj4>
Hi Dmitry,
On Thu, Dec 11, 2025 at 08:44:02PM -0800, Dmitry Torokhov wrote:
> On Wed, Dec 10, 2025 at 06:00:29PM +0000, Fabio Baltieri wrote:
> > Hey Rob, thanks for the review.
> >
> > On Tue, Dec 09, 2025 at 01:22:43PM -0600, Rob Herring wrote:
> > > On Tue, Dec 09, 2025 at 03:47:06PM +0000, Fabio Baltieri wrote:
> > > > + fn-key:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + description: |
> > > > + An u32 containing the coordinate of the Fn key, use the MATRIX_KEY(row,
> > > > + col, code) macro, code is ignored.
> > > > +
> > > > + fn-keymap:
> > >
> > > If keymap is linux,keymap, then this should perhaps be linux,fn-keymap.
> > > Depends if we still think linux,keymap is Linux specific?
> >
> > I'm open for suggestions, trying to understand the pattern, these are
> > specific to this binding I think if anything they should be
> > google,fn-key and google,fn-keymap, similarly to the existing
> > google,needs-ghost-filter -- no idea why function-row-physmap was not
> > prefixed but I guess it slipped in and now it's not worth changing it.
>
> Just double the number of rows in the regular keymap to accommodate the
> FN modifier, no need for separate keymap. Also no need to have fn-key
> property, use whatever key that reports KEY_FN. See how it is done in
> drivers/input/keyboard/tegra-kbc.c
Had a look at the tegra-kbc driver as you suggested, first thing it
seems like the fn-key functionality there is dead code since 2013,
`use_fn_map` could only be enabled with platform data, not OF, and that
has been removed in 3a495aeada2b, as it stands kbc->use_fn_map can only
be false. I could send a patch to rip off that code if you want me to,
clearly it hasn't been used in a while (unless I'm missing something).
About the extended fn map, I've two problems with it:
- it seems very wasteful: the normal map is loaded in a linear array
so it can be access directly, which make sense as that's typically
very densely populated, but in the case of the fn keys that's going to
be mostly empty, I'd expect ~20 keys top from a 18x8 matrix. So that
would waste load of space, direct access is good but for ~20 keys I
think it's fine to scan it, especially since it only happens when Fn
is pressed.
- I'd end up with two values for cols kicking around the driver, the
real one and the one used in the map, which I feel adds confusing in
the code.
- more importantly, one would have to keep the offset in mind when
setting the keys in dt, we rely on OEM doing this and I think having a
separate property with a meaningful name and a map with the same
row,col and different code is more intuitive and would make their life
easier, especially since we ship with keyboard of different size
and the offset would be different depending on the device.
As for the fn-key property, unfortunately based on past experience I'd
expect such OEM to want to change that code, I could specify the code
rather than the row,col but I would not plain hardcode. Even my
(thinkpad) laptop sends KEY_WAKEUP for Fn.
Cheers,
Fabio
--
Fabio Baltieri
^ permalink raw reply
* Re: [PATCH 4/4] Input: stmfts - use client to make future code cleaner
From: David Heidelberg @ 2025-12-16 9:13 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Maxime Coquelin, Alexandre Torgue, Petr Hodina,
Javier Martinez Canillas, Rob Herring, Andi Shyti, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <hpmm5fhs74swrhkneaif4s5dquqeclujdlua7ygmkvcmtf6n4t@rsahxu23xwfp>
On 16/12/2025 07:13, Dmitry Torokhov wrote:
> Hi David,
>
> On Mon, Dec 15, 2025 at 03:30:04PM +0100, David Heidelberg via B4 Relay wrote:
>> From: Petr Hodina <petr.hodina@protonmail.com>
>>
>> Make code cleaner, compiler will optimize it away anyway.
>>
>> Preparation for FTM5 support, where more steps are needed.
>>
>> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> ---
>> drivers/input/touchscreen/stmfts.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c
>> index 4b166b0a9a5a6..06845a00348cc 100644
>> --- a/drivers/input/touchscreen/stmfts.c
>> +++ b/drivers/input/touchscreen/stmfts.c
>> @@ -747,9 +747,10 @@ static int stmfts_runtime_suspend(struct device *dev)
>> static int stmfts_runtime_resume(struct device *dev)
>> {
>> struct stmfts_data *sdata = dev_get_drvdata(dev);
>> + struct i2c_client *client = sdata->client;
>> int ret;
>>
>> - ret = i2c_smbus_write_byte(sdata->client, STMFTS_SLEEP_OUT);
>> + ret = i2c_smbus_write_byte(client, STMFTS_SLEEP_OUT);
>
> Sorry but I do not see how using a temporary cleans things up compared
> to a simple structure member access, given that it happens only once
> here.
Thank you for applying rest of patchset.
This one can be postponed together with introducing fts5 support (where
we need do more steps here).
David
>
>> if (ret)
>> dev_err(dev, "failed to resume device: %d\n", ret);
>>
>>
>
> Thanks.
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Alexandre Belloni @ 2025-12-16 8:47 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, kernel, linux-input, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20251215-rock4d-audio-v2-1-82a61de39b4c@collabora.com>
On 15/12/2025 13:29:29+0100, Nicolas Frattaroli wrote:
> adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> property. This makes it impossible to model devices that have ADC inputs
> that should generate switch events.
>
> Add the property to the binding with the same default as gpio-keys.
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> Documentation/devicetree/bindings/input/adc-keys.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.yaml b/Documentation/devicetree/bindings/input/adc-keys.yaml
> index 7aa078dead37..e372ebc23d16 100644
> --- a/Documentation/devicetree/bindings/input/adc-keys.yaml
> +++ b/Documentation/devicetree/bindings/input/adc-keys.yaml
> @@ -42,6 +42,9 @@ patternProperties:
>
> linux,code: true
>
> + linux,input-type:
> + default: 1 # EV_KEY
> +
> press-threshold-microvolt:
> description:
> Voltage above or equal to which this key is considered pressed. No
>
> --
> 2.52.0
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 2/4] Input: adc-keys - support EV_SW as well, not just EV_KEY.
From: Alexandre Belloni @ 2025-12-16 8:45 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, kernel, linux-input, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20251215-rock4d-audio-v2-2-82a61de39b4c@collabora.com>
On 15/12/2025 13:29:30+0100, Nicolas Frattaroli wrote:
> Instead of doing something like what gpio-keys is doing, adc-keys
> hardcodes that all keycodes must be of type EV_KEY.
>
> This limits the usefulness of adc-keys, and overcomplicates the code
> with manual bit-setting logic.
>
> Instead, refactor the code to read the linux,input-type fwnode property,
> and get rid of the custom bit setting logic, replacing it with
> input_set_capability instead. input_report_key is replaced with
> input_event, which allows us to explicitly pass the type.
>
> Only EV_KEY and EV_SW is allowed at this stage.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/input/keyboard/adc-keys.c | 37 +++++++++++++++++++++++++------------
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> index f1753207429d..62376f34f7d0 100644
> --- a/drivers/input/keyboard/adc-keys.c
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -18,13 +18,15 @@
>
> struct adc_keys_button {
> u32 voltage;
> - u32 keycode;
> + u32 code;
> + u32 type;
> };
>
> struct adc_keys_state {
> struct iio_channel *channel;
> u32 num_keys;
> u32 last_key;
> + u32 last_type;
> u32 keyup_voltage;
> const struct adc_keys_button *map;
> };
> @@ -34,7 +36,8 @@ static void adc_keys_poll(struct input_dev *input)
> struct adc_keys_state *st = input_get_drvdata(input);
> int i, value, ret;
> u32 diff, closest = 0xffffffff;
> - int keycode = 0;
> + u32 code = 0;
> + u32 type = EV_KEY;
>
> ret = iio_read_channel_processed(st->channel, &value);
> if (unlikely(ret < 0)) {
> @@ -45,22 +48,24 @@ static void adc_keys_poll(struct input_dev *input)
> diff = abs(st->map[i].voltage - value);
> if (diff < closest) {
> closest = diff;
> - keycode = st->map[i].keycode;
> + code = st->map[i].code;
> + type = st->map[i].type;
> }
> }
> }
>
> if (abs(st->keyup_voltage - value) < closest)
> - keycode = 0;
> + code = 0;
>
> - if (st->last_key && st->last_key != keycode)
> - input_report_key(input, st->last_key, 0);
> + if (st->last_key && st->last_key != code)
> + input_event(input, st->last_type, st->last_key, 0);
>
> - if (keycode)
> - input_report_key(input, keycode, 1);
> + if (code)
> + input_event(input, type, code, 1);
>
> input_sync(input);
> - st->last_key = keycode;
> + st->last_key = code;
> + st->last_type = type;
> }
>
> static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> @@ -88,11 +93,20 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> map[i].voltage /= 1000;
>
> if (fwnode_property_read_u32(child, "linux,code",
> - &map[i].keycode)) {
> + &map[i].code)) {
> dev_err(dev, "Key with invalid or missing linux,code\n");
> return -EINVAL;
> }
>
> + if (fwnode_property_read_u32(child, "linux,input-type",
> + &map[i].type))
> + map[i].type = EV_KEY;
> +
> + if (map[i].type != EV_KEY && map[i].type != EV_SW)
> + return dev_err_probe(dev, -EINVAL,
> + "Invalid linux,input-type: 0x%x\n",
> + map[i].type);
> +
> i++;
> }
>
> @@ -156,9 +170,8 @@ static int adc_keys_probe(struct platform_device *pdev)
> input->id.product = 0x0001;
> input->id.version = 0x0100;
>
> - __set_bit(EV_KEY, input->evbit);
> for (i = 0; i < st->num_keys; i++)
> - __set_bit(st->map[i].keycode, input->keybit);
> + input_set_capability(input, st->map[i].type, st->map[i].code);
>
> if (device_property_read_bool(dev, "autorepeat"))
> __set_bit(EV_REP, input->evbit);
>
> --
> 2.52.0
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 3/4] Input: adc-keys - Use dev_err_probe in probe function
From: Alexandre Belloni @ 2025-12-16 8:45 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, kernel, linux-input, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20251215-rock4d-audio-v2-3-82a61de39b4c@collabora.com>
On 15/12/2025 13:29:31+0100, Nicolas Frattaroli wrote:
> Rework the probe function, and functions called by the probe function,
> to use dev_err_probe for error logging.
>
> While at it, also do some minor style cleanups, like not error logging
> on -ENOMEM and using ! instead of == 0.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/input/keyboard/adc-keys.c | 53 ++++++++++++++++-----------------------
> 1 file changed, 21 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> index 62376f34f7d0..6f2ddcecea99 100644
> --- a/drivers/input/keyboard/adc-keys.c
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -74,10 +74,8 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> int i;
>
> st->num_keys = device_get_child_node_count(dev);
> - if (st->num_keys == 0) {
> - dev_err(dev, "keymap is missing\n");
> - return -EINVAL;
> - }
> + if (!st->num_keys)
> + return dev_err_probe(dev, -EINVAL, "keymap is missing\n");
>
> map = devm_kmalloc_array(dev, st->num_keys, sizeof(*map), GFP_KERNEL);
> if (!map)
> @@ -86,17 +84,16 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> i = 0;
> device_for_each_child_node_scoped(dev, child) {
> if (fwnode_property_read_u32(child, "press-threshold-microvolt",
> - &map[i].voltage)) {
> - dev_err(dev, "Key with invalid or missing voltage\n");
> - return -EINVAL;
> - }
> + &map[i].voltage))
> + return dev_err_probe(dev, -EINVAL,
> + "Key with invalid or missing voltage\n");
> +
> map[i].voltage /= 1000;
>
> if (fwnode_property_read_u32(child, "linux,code",
> - &map[i].code)) {
> - dev_err(dev, "Key with invalid or missing linux,code\n");
> - return -EINVAL;
> - }
> + &map[i].code))
> + return dev_err_probe(dev, -EINVAL,
> + "Key with invalid or missing linux,code\n");
>
> if (fwnode_property_read_u32(child, "linux,input-type",
> &map[i].type))
> @@ -129,7 +126,8 @@ static int adc_keys_probe(struct platform_device *pdev)
>
> st->channel = devm_iio_channel_get(dev, "buttons");
> if (IS_ERR(st->channel))
> - return PTR_ERR(st->channel);
> + return dev_err_probe(dev, PTR_ERR(st->channel),
> + "Could not get iio channel\n");
>
> if (!st->channel->indio_dev)
> return -ENXIO;
> @@ -138,16 +136,13 @@ static int adc_keys_probe(struct platform_device *pdev)
> if (error < 0)
> return error;
>
> - if (type != IIO_VOLTAGE) {
> - dev_err(dev, "Incompatible channel type %d\n", type);
> - return -EINVAL;
> - }
> + if (type != IIO_VOLTAGE)
> + return dev_err_probe(dev, -EINVAL, "Incompatible channel type %d\n", type);
>
> if (device_property_read_u32(dev, "keyup-threshold-microvolt",
> - &st->keyup_voltage)) {
> - dev_err(dev, "Invalid or missing keyup voltage\n");
> - return -EINVAL;
> - }
> + &st->keyup_voltage))
> + return dev_err_probe(dev, -EINVAL, "Invalid or missing keyup voltage\n");
> +
> st->keyup_voltage /= 1000;
>
> error = adc_keys_load_keymap(dev, st);
> @@ -155,10 +150,8 @@ static int adc_keys_probe(struct platform_device *pdev)
> return error;
>
> input = devm_input_allocate_device(dev);
> - if (!input) {
> - dev_err(dev, "failed to allocate input device\n");
> + if (!input)
> return -ENOMEM;
> - }
>
> input_set_drvdata(input, st);
>
> @@ -178,19 +171,15 @@ static int adc_keys_probe(struct platform_device *pdev)
>
>
> error = input_setup_polling(input, adc_keys_poll);
> - if (error) {
> - dev_err(dev, "Unable to set up polling: %d\n", error);
> - return error;
> - }
> + if (error)
> + return dev_err_probe(dev, error, "Unable to set up polling\n");
>
> if (!device_property_read_u32(dev, "poll-interval", &value))
> input_set_poll_interval(input, value);
>
> error = input_register_device(input);
> - if (error) {
> - dev_err(dev, "Unable to register input device: %d\n", error);
> - return error;
> - }
> + if (error)
> + return dev_err_probe(dev, error, "Unable to register input device\n");
>
> return 0;
> }
>
> --
> 2.52.0
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 4/4] Input: stmfts - use client to make future code cleaner
From: Dmitry Torokhov @ 2025-12-16 6:13 UTC (permalink / raw)
To: david
Cc: Maxime Coquelin, Alexandre Torgue, Petr Hodina,
Javier Martinez Canillas, Rob Herring, Andi Shyti, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20251215-fts-fixes-v1-4-8c1e3a63ebf1@ixit.cz>
Hi David,
On Mon, Dec 15, 2025 at 03:30:04PM +0100, David Heidelberg via B4 Relay wrote:
> From: Petr Hodina <petr.hodina@protonmail.com>
>
> Make code cleaner, compiler will optimize it away anyway.
>
> Preparation for FTM5 support, where more steps are needed.
>
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> drivers/input/touchscreen/stmfts.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c
> index 4b166b0a9a5a6..06845a00348cc 100644
> --- a/drivers/input/touchscreen/stmfts.c
> +++ b/drivers/input/touchscreen/stmfts.c
> @@ -747,9 +747,10 @@ static int stmfts_runtime_suspend(struct device *dev)
> static int stmfts_runtime_resume(struct device *dev)
> {
> struct stmfts_data *sdata = dev_get_drvdata(dev);
> + struct i2c_client *client = sdata->client;
> int ret;
>
> - ret = i2c_smbus_write_byte(sdata->client, STMFTS_SLEEP_OUT);
> + ret = i2c_smbus_write_byte(client, STMFTS_SLEEP_OUT);
Sorry but I do not see how using a temporary cleans things up compared
to a simple structure member access, given that it happens only once
here.
> if (ret)
> dev_err(dev, "failed to resume device: %d\n", ret);
>
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] Input: stmfts - use sysfs_emit() instead of sprintf()
From: Dmitry Torokhov @ 2025-12-16 6:11 UTC (permalink / raw)
To: david
Cc: Maxime Coquelin, Alexandre Torgue, Petr Hodina,
Javier Martinez Canillas, Rob Herring, Andi Shyti, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20251215-fts-fixes-v1-3-8c1e3a63ebf1@ixit.cz>
On Mon, Dec 15, 2025 at 03:30:03PM +0100, David Heidelberg via B4 Relay wrote:
> From: Petr Hodina <petr.hodina@protonmail.com>
>
> Follow the advice in Documentation/filesystems/sysfs.rst:
> show() should only use sysfs_emit() or sysfs_emit_at() when formatting
> the value to be returned to user space.
>
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/4] Input: stmfts - Make comments correct
From: Dmitry Torokhov @ 2025-12-16 6:11 UTC (permalink / raw)
To: david
Cc: Maxime Coquelin, Alexandre Torgue, Petr Hodina,
Javier Martinez Canillas, Rob Herring, Andi Shyti, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20251215-fts-fixes-v1-2-8c1e3a63ebf1@ixit.cz>
On Mon, Dec 15, 2025 at 03:30:02PM +0100, David Heidelberg via B4 Relay wrote:
> From: Petr Hodina <petr.hodina@protonmail.com>
>
> No functional change.
>
> Fixes: 78bcac7b2ae1 ("Input: add support for the STMicroelectronics FingerTip touchscreen")
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/4] Input: stmfts - correct wording for the warning message
From: Dmitry Torokhov @ 2025-12-16 6:10 UTC (permalink / raw)
To: david
Cc: Maxime Coquelin, Alexandre Torgue, Petr Hodina,
Javier Martinez Canillas, Rob Herring, Andi Shyti, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20251215-fts-fixes-v1-1-8c1e3a63ebf1@ixit.cz>
On Mon, Dec 15, 2025 at 03:30:01PM +0100, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> We're trying to enable regulator, not disable it.
>
> Fixes: 78bcac7b2ae1 ("Input: add support for the STMicroelectronics FingerTip touchscreen")
> Suggested-by: Petr Hodina <petr.hodina@protonmail.com>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [BUG] lockdep: circular locking dependency in uinput/input_ff under Wine (ELDEN RING, gamepad)
From: Mikhail Gavrilov @ 2025-12-15 21:40 UTC (permalink / raw)
To: linux-input, Linux List Kernel Mailing
[-- Attachment #1: Type: text/plain, Size: 7898 bytes --]
Hello,
I would like to report a reproducible lockdep warning in the input subsystem,
involving uinput and force-feedback handling.
After connecting a gamepad (Flydigi Vader 5) and playing ELDEN RING under Wine,
the kernel consistently reports a possible circular locking dependency
within approximately 5 minutes of gameplay.
This issue reproduces 100% of the time on my system.
Steps to reproduce:
- Boot a kernel with CONFIG_LOCKDEP enabled
- Connect a USB gamepad
- Start Wine
- Launch ELDEN RING
- Play for approximately 5 minutes
The kernel emits the following warning:
[ 4151.300019] ======================================================
[ 4151.300023] WARNING: possible circular locking dependency detected
[ 4151.300027] 6.19.0-rc1-dirty #31 Tainted: G U
[ 4151.300031] ------------------------------------------------------
[ 4151.300034] winedevice.exe/50772 is trying to acquire lock:
[ 4151.300038] ffff8888da59b878 (&newdev->mutex){+.+.}-{4:4}, at:
uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300057]
but task is already holding lock:
[ 4151.300060] ffff8888c46040b8 (&ff->mutex){+.+.}-{4:4}, at:
input_ff_upload+0x160/0xd70
[ 4151.300075]
which lock already depends on the new lock.
[ 4151.300078]
the existing dependency chain (in reverse order) is:
[ 4151.300081]
-> #2 (&ff->mutex){+.+.}-{4:4}:
[ 4151.300091] __lock_acquire+0x56a/0xbd0
[ 4151.300099] lock_acquire.part.0+0xc7/0x270
[ 4151.300105] __mutex_lock+0x1b0/0x2290
[ 4151.300111] input_ff_flush+0x56/0x150
[ 4151.300116] input_flush_device+0x91/0xf0
[ 4151.300122] evdev_release+0x2cb/0x3a0
[ 4151.300126] __fput+0x36e/0xac0
[ 4151.300132] fput_close_sync+0xde/0x1b0
[ 4151.300137] __x64_sys_close+0x7d/0xd0
[ 4151.300142] do_syscall_64+0x9c/0x4e0
[ 4151.300148] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300153]
-> #1 (&dev->mutex#2){+.+.}-{4:4}:
[ 4151.300164] __lock_acquire+0x56a/0xbd0
[ 4151.300170] lock_acquire.part.0+0xc7/0x270
[ 4151.300175] __mutex_lock+0x1b0/0x2290
[ 4151.300179] __input_unregister_device+0x20/0x480
[ 4151.300183] input_unregister_device+0x88/0xc0
[ 4151.300188] uinput_destroy_device+0x19e/0x210 [uinput]
[ 4151.300193] uinput_ioctl_handler.isra.0+0x2b5/0x1170 [uinput]
[ 4151.300198] __x64_sys_ioctl+0x13c/0x1c0
[ 4151.300204] do_syscall_64+0x9c/0x4e0
[ 4151.300210] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300215]
-> #0 (&newdev->mutex){+.+.}-{4:4}:
[ 4151.300221] check_prev_add+0xe1/0xca0
[ 4151.300225] validate_chain+0x4cb/0x730
[ 4151.300228] __lock_acquire+0x56a/0xbd0
[ 4151.300231] lock_acquire.part.0+0xc7/0x270
[ 4151.300235] __mutex_lock+0x1b0/0x2290
[ 4151.300237] uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300241] uinput_dev_upload_effect+0x123/0x1c1 [uinput]
[ 4151.300244] input_ff_upload+0x269/0xd70
[ 4151.300247] evdev_do_ioctl+0xce6/0x14f0
[ 4151.300249] evdev_ioctl+0x12a/0x160
[ 4151.300252] __x64_sys_ioctl+0x13c/0x1c0
[ 4151.300255] do_syscall_64+0x9c/0x4e0
[ 4151.300258] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300261]
other info that might help us debug this:
[ 4151.300262] Chain exists of:
&newdev->mutex --> &dev->mutex#2 --> &ff->mutex
[ 4151.300270] Possible unsafe locking scenario:
[ 4151.300272] CPU0 CPU1
[ 4151.300274] ---- ----
[ 4151.300275] lock(&ff->mutex);
[ 4151.300279] lock(&dev->mutex#2);
[ 4151.300283] lock(&ff->mutex);
[ 4151.300286] lock(&newdev->mutex);
[ 4151.300289]
*** DEADLOCK ***
[ 4151.300291] 2 locks held by winedevice.exe/50772:
[ 4151.300294] #0: ffff888153d93128 (&evdev->mutex){+.+.}-{4:4}, at:
evdev_ioctl+0x76/0x160
[ 4151.300301] #1: ffff8888c46040b8 (&ff->mutex){+.+.}-{4:4}, at:
input_ff_upload+0x160/0xd70
[ 4151.300309]
stack backtrace:
[ 4151.300312] CPU: 14 UID: 1000 PID: 50772 Comm: winedevice.exe
Tainted: G U 6.19.0-rc1-dirty #31 PREEMPT(lazy)
[ 4151.300316] Tainted: [U]=USER
[ 4151.300317] Hardware name: ASUS System Product Name/ROG STRIX
B650E-I GAMING WIFI, BIOS 3263 06/09/2025
[ 4151.300319] Call Trace:
[ 4151.300320] <TASK>
[ 4151.300323] dump_stack_lvl+0x84/0xd0
[ 4151.300328] print_circular_bug.cold+0x38/0x46
[ 4151.300332] check_noncircular+0x148/0x170
[ 4151.300336] check_prev_add+0xe1/0xca0
[ 4151.300340] validate_chain+0x4cb/0x730
[ 4151.300343] __lock_acquire+0x56a/0xbd0
[ 4151.300347] lock_acquire.part.0+0xc7/0x270
[ 4151.300349] ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300352] ? rcu_is_watching+0x15/0xe0
[ 4151.300356] ? __pfx___might_resched+0x10/0x10
[ 4151.300359] ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300361] ? lock_acquire+0xf6/0x130
[ 4151.300364] __mutex_lock+0x1b0/0x2290
[ 4151.300366] ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300371] ? find_held_lock+0x2b/0x80
[ 4151.300375] ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300378] ? __lock_release.isra.0+0x1c9/0x340
[ 4151.300381] ? __pfx___mutex_lock+0x10/0x10
[ 4151.300384] ? do_raw_spin_unlock+0x59/0x230
[ 4151.300386] ? uinput_request_reserve_slot+0x342/0x4c0 [uinput]
[ 4151.300388] ? uinput_request_reserve_slot+0x342/0x4c0 [uinput]
[ 4151.300391] ? __pfx_uinput_request_reserve_slot+0x10/0x10 [uinput]
[ 4151.300394] ? rcu_is_watching+0x15/0xe0
[ 4151.300397] ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300399] uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300402] uinput_dev_upload_effect+0x123/0x1c1 [uinput]
[ 4151.300407] ? __pfx_uinput_dev_upload_effect+0x10/0x10 [uinput]
[ 4151.300411] ? __lock_release.isra.0+0x1c9/0x340
[ 4151.300414] input_ff_upload+0x269/0xd70
[ 4151.300418] evdev_do_ioctl+0xce6/0x14f0
[ 4151.300420] ? evdev_ioctl+0x76/0x160
[ 4151.300422] ? __pfx_evdev_do_ioctl+0x10/0x10
[ 4151.300425] ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10
[ 4151.300429] ? __lock_release.isra.0+0x1c9/0x340
[ 4151.300433] evdev_ioctl+0x12a/0x160
[ 4151.300436] __x64_sys_ioctl+0x13c/0x1c0
[ 4151.300438] ? syscall_trace_enter+0x8e/0x2b0
[ 4151.300441] do_syscall_64+0x9c/0x4e0
[ 4151.300444] ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170
[ 4151.300447] ? irqentry_exit+0x8c/0x5b0
[ 4151.300451] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300453] RIP: 0033:0x7f5dd4bfb46d
[ 4151.300474] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10
c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00
00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00
00 00
[ 4151.300476] RSP: 002b:00007f5daf8fd580 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 4151.300479] RAX: ffffffffffffffda RBX: 00007f5db40d03b0 RCX: 00007f5dd4bfb46d
[ 4151.300480] RDX: 00007f5daf8fd600 RSI: 0000000040304580 RDI: 0000000000000033
[ 4151.300482] RBP: 00007f5daf8fd5d0 R08: 0000000000000000 R09: 00000000ffffffff
[ 4151.300483] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5dd3124f60
[ 4151.300484] R13: 00007f5daf8fd5e0 R14: 00007f5db40c7360 R15: 00007f5daf8fd600
[ 4151.300488] </TASK>
[ 4368.245690] eldenring.exe (50876) used greatest stack depth: 18136 bytes left
Kernel: 6.19.0-rc1
Hardware probe: https://linux-hardware.org/?probe=2eeb9df547
Userspace:
Wine (winedevice.exe)
ELDEN RING
Could someone from the input/uinput maintainers please take a look
at the locking order between ff->mutex, dev->mutex and newdev->mutex?
This appears to be a genuine circular dependency reachable from
normal userspace activity.
--
Best Regards,
Mike Gavrilov.
[-- Attachment #2: .config.zip --]
[-- Type: application/zip, Size: 71202 bytes --]
[-- Attachment #3: dmesg-6.19.0-rc1-dirty-2.zip --]
[-- Type: application/zip, Size: 47794 bytes --]
^ permalink raw reply
* [PATCH] dt-bindings: input: touchscreen: sitronix,st1232: Add Sitronix ST1624
From: Rob Herring (Arm) @ 2025-12-15 21:25 UTC (permalink / raw)
To: Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, Bastian Hecht
Cc: linux-input, devicetree, linux-kernel
Add the Sitronix ST1624 which is compatible with ST1633.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/input/touchscreen/sitronix,st1232.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
index e7ee7a0d74c4..978afaa4fcef 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
@@ -14,9 +14,13 @@ allOf:
properties:
compatible:
- enum:
- - sitronix,st1232
- - sitronix,st1633
+ oneOf:
+ - enum:
+ - sitronix,st1232
+ - sitronix,st1633
+ - items:
+ - const: sitronix,st1624
+ - const: sitronix,st1633
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max Gen10 AMD to i8042 quirk table
From: Dmitry Torokhov @ 2025-12-15 18:15 UTC (permalink / raw)
To: Werner Sembach; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <20251124203336.64072-1-wse@tuxedocomputers.com>
On Mon, Nov 24, 2025 at 09:31:34PM +0100, Werner Sembach wrote:
> From: Christoffer Sandberg <cs@tuxedo.de>
>
> The device occasionally wakes up from suspend with missing input on the
> internal keyboard and the following suspend attempt results in an instant
> wake-up. The quirks fix both issues for this device.
>
> Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
Applied, thank you.
--
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox