* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH 3/3] Input: snvs_pwrkey - report press event in interrupt handler
From: Joy Zou @ 2026-03-31 10:46 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <acWPp7KHxv9a5Az6@lizhi-Precision-Tower-5810>
On Thu, Mar 26, 2026 at 03:57:27PM -0400, Frank Li wrote:
> On Thu, Mar 26, 2026 at 06:39:40PM +0800, Joy Zou wrote:
> > On some boards such as i.MX8MQ-EVK, the PCIe driver may take up to
> > 200ms to restore the PCIe link during the no_irq resume phase. This
> > causes key press events to be lost because the key may be released
> > before the timer starts running, as interrupts are disabled during
> > this 200ms window.
>
> if irq disable, how imx_snvs_pwrkey_interrupt get run?
>
Thank you for your comments. I might have missed some details in my commit
message. Could you please review the description below and let me know if
it's clear and comprehensive enough?
The driver implements debounce protection using a timer-based mechanism:
when a key interrupt occurs, a timer is scheduled to verify the key state
after DEBOUNCE_TIME before reporting the event. This works well during
normal operation.
However, key press events can be lost during system resume on platforms
like i.MX8MQ-EVK because:
1. During the no_irq resume phase, PCIe driver restoration can take up to
200ms with IRQs disabled.
2. The power key interrupt remains pending during the no_irq phase.
3. If the key is released before IRQs are re-enabled, the timer eventually
runs but sees the key as released and skips reporting the event.
Report key press events directly in interrupt handler to prevent event
loss during system suspend. This is safe because:
1. Only one event is reported per suspend cycle.
2. Normal operation retains the existing timer-based debounce mechanism.
BR
Joy Zou
> Frank
> >
> > Report key press events directly in interrupt handler to prevent event
> > loss during system suspend.
> >
> > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > ---
> > drivers/input/keyboard/snvs_pwrkey.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > index bab3ab57fdac77256be75a080773ea99372ec9c7..b557c1618d7369e872c6ce708a7b3017264ee385 100644
> > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > @@ -78,6 +78,16 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> >
> > pm_wakeup_event(input->dev.parent, 0);
> >
> > + /*
> > + * Report key press events directly in interrupt handler to prevent event
> > + * loss during system suspend.
> > + */
> > + if (pdev->dev.power.is_suspended) {
> > + pdata->keystate = 1;
> > + input_report_key(input, pdata->keycode, 1);
> > + input_sync(input);
> > + }
> > +
> > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > if (lp_status & SNVS_LPSR_SPO) {
> > if (pdata->minor_rev == 0) {
> >
> > --
> > 2.37.1
> >
^ permalink raw reply
* Re: [PATCH 3/3] Input: snvs_pwrkey - report press event in interrupt handler
From: Frank Li @ 2026-03-31 14:11 UTC (permalink / raw)
To: Joy Zou
Cc: Dmitry Torokhov, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <20260331104655.GA1415371@shlinux88>
On Tue, Mar 31, 2026 at 06:46:55PM +0800, Joy Zou wrote:
> On Thu, Mar 26, 2026 at 03:57:27PM -0400, Frank Li wrote:
> > On Thu, Mar 26, 2026 at 06:39:40PM +0800, Joy Zou wrote:
> > > On some boards such as i.MX8MQ-EVK, the PCIe driver may take up to
> > > 200ms to restore the PCIe link during the no_irq resume phase. This
> > > causes key press events to be lost because the key may be released
> > > before the timer starts running, as interrupts are disabled during
> > > this 200ms window.
> >
> > if irq disable, how imx_snvs_pwrkey_interrupt get run?
> >
> Thank you for your comments. I might have missed some details in my commit
> message. Could you please review the description below and let me know if
> it's clear and comprehensive enough?
>
> The driver implements debounce protection using a timer-based mechanism:
> when a key interrupt occurs, a timer is scheduled to verify the key state
> after DEBOUNCE_TIME before reporting the event. This works well during
> normal operation.
>
> However, key press events can be lost during system resume on platforms
> like i.MX8MQ-EVK because:
> 1. During the no_irq resume phase, PCIe driver restoration can take up to
> 200ms with IRQs disabled.
> 2. The power key interrupt remains pending during the no_irq phase.
> 3. If the key is released before IRQs are re-enabled, the timer eventually
> runs but sees the key as released and skips reporting the event.
>
> Report key press events directly in interrupt handler to prevent event
> loss during system suspend. This is safe because:
>
> 1. Only one event is reported per suspend cycle.
> 2. Normal operation retains the existing timer-based debounce mechanism.
much better. Thanks
Frank
> BR
> Joy Zou
> > Frank
> > >
> > > Report key press events directly in interrupt handler to prevent event
> > > loss during system suspend.
> > >
> > > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > > ---
> > > drivers/input/keyboard/snvs_pwrkey.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > > index bab3ab57fdac77256be75a080773ea99372ec9c7..b557c1618d7369e872c6ce708a7b3017264ee385 100644
> > > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > > @@ -78,6 +78,16 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> > >
> > > pm_wakeup_event(input->dev.parent, 0);
> > >
> > > + /*
> > > + * Report key press events directly in interrupt handler to prevent event
> > > + * loss during system suspend.
> > > + */
> > > + if (pdev->dev.power.is_suspended) {
> > > + pdata->keystate = 1;
> > > + input_report_key(input, pdata->keycode, 1);
> > > + input_sync(input);
> > > + }
> > > +
> > > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > > if (lp_status & SNVS_LPSR_SPO) {
> > > if (pdata->minor_rev == 0) {
> > >
> > > --
> > > 2.37.1
> > >
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 620ecc3c77ab1cad90760eec933ccf49a7bf6a8e
From: kernel test robot @ 2026-03-31 14:31 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: 620ecc3c77ab1cad90760eec933ccf49a7bf6a8e Input: usbtouchscreen - refactor endpoint lookup
elapsed time: 844m
configs tested: 179
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260331 clang-23
arc randconfig-002-20260331 clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260331 clang-23
arm randconfig-002-20260331 clang-23
arm randconfig-003-20260331 clang-23
arm randconfig-004-20260331 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260331 clang-18
arm64 randconfig-002-20260331 clang-18
arm64 randconfig-003-20260331 clang-18
arm64 randconfig-004-20260331 clang-18
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260331 clang-18
csky randconfig-002-20260331 clang-18
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260331 gcc-11.5.0
hexagon randconfig-002-20260331 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260331 clang-20
i386 buildonly-randconfig-002-20260331 clang-20
i386 buildonly-randconfig-003-20260331 clang-20
i386 buildonly-randconfig-004-20260331 clang-20
i386 buildonly-randconfig-005-20260331 clang-20
i386 buildonly-randconfig-006-20260331 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260331 gcc-14
i386 randconfig-002-20260331 gcc-14
i386 randconfig-003-20260331 gcc-14
i386 randconfig-004-20260331 gcc-14
i386 randconfig-005-20260331 gcc-14
i386 randconfig-006-20260331 gcc-14
i386 randconfig-007-20260331 gcc-14
i386 randconfig-011-20260331 clang-20
i386 randconfig-012-20260331 clang-20
i386 randconfig-013-20260331 clang-20
i386 randconfig-014-20260331 clang-20
i386 randconfig-015-20260331 clang-20
i386 randconfig-016-20260331 clang-20
i386 randconfig-017-20260331 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260331 gcc-11.5.0
loongarch randconfig-002-20260331 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip32_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260331 gcc-11.5.0
nios2 randconfig-002-20260331 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260331 clang-23
parisc randconfig-002-20260331 clang-23
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc pcm030_defconfig clang-23
powerpc randconfig-001-20260331 clang-23
powerpc randconfig-002-20260331 clang-23
powerpc64 alldefconfig clang-23
powerpc64 randconfig-001-20260331 clang-23
powerpc64 randconfig-002-20260331 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260331 gcc-15.2.0
riscv randconfig-002-20260331 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260331 gcc-15.2.0
s390 randconfig-002-20260331 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260331 gcc-15.2.0
sh randconfig-002-20260331 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260331 gcc-15.2.0
sparc randconfig-002-20260331 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260331 gcc-15.2.0
sparc64 randconfig-002-20260331 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260331 gcc-15.2.0
um randconfig-002-20260331 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260331 clang-20
x86_64 buildonly-randconfig-002-20260331 clang-20
x86_64 buildonly-randconfig-003-20260331 clang-20
x86_64 buildonly-randconfig-004-20260331 clang-20
x86_64 buildonly-randconfig-005-20260331 clang-20
x86_64 buildonly-randconfig-006-20260331 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260331 gcc-14
x86_64 randconfig-002-20260331 gcc-14
x86_64 randconfig-003-20260331 gcc-14
x86_64 randconfig-004-20260331 gcc-14
x86_64 randconfig-005-20260331 gcc-14
x86_64 randconfig-006-20260331 gcc-14
x86_64 randconfig-011-20260331 clang-20
x86_64 randconfig-012-20260331 clang-20
x86_64 randconfig-013-20260331 clang-20
x86_64 randconfig-014-20260331 clang-20
x86_64 randconfig-015-20260331 clang-20
x86_64 randconfig-016-20260331 clang-20
x86_64 randconfig-071-20260331 clang-20
x86_64 randconfig-072-20260331 clang-20
x86_64 randconfig-073-20260331 clang-20
x86_64 randconfig-074-20260331 clang-20
x86_64 randconfig-075-20260331 clang-20
x86_64 randconfig-076-20260331 clang-20
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-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260331 gcc-15.2.0
xtensa randconfig-002-20260331 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
From: kernel test robot @ 2026-03-31 16:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-6-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[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/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-6-l.scorcia%40gmail.com
patch subject: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
config: s390-randconfig-002-20260331 (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-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/202603312339.CMJpqhEq-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/mt6397-core.c:421:16: warning: cast to smaller integer type 'enum mfd_match_data' from 'const void *' [-Wvoid-pointer-to-enum-cast]
421 | device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +421 drivers/mfd/mt6397-core.c
398
399 static int mt6397_probe(struct platform_device *pdev)
400 {
401 int ret;
402 unsigned int id = 0;
403 struct mt6397_chip *pmic;
404 const struct chip_data *pmic_core;
405 enum mfd_match_data device_data;
406
407 pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
408 if (!pmic)
409 return -ENOMEM;
410
411 pmic->dev = &pdev->dev;
412
413 /*
414 * mt6397 MFD is child device of soc pmic wrapper.
415 * Regmap is set from its parent.
416 */
417 pmic->regmap = dev_get_regmap(pdev->dev.parent, NULL);
418 if (!pmic->regmap)
419 return -ENODEV;
420
> 421 device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
422 switch (device_data) {
423 case MATCH_DATA_MT6323:
424 pmic_core = &mt6323_core;
425 break;
426 case MATCH_DATA_MT6328:
427 pmic_core = &mt6328_core;
428 break;
429 case MATCH_DATA_MT6331:
430 pmic_core = &mt6331_mt6332_core;
431 break;
432 case MATCH_DATA_MT6357:
433 pmic_core = &mt6357_core;
434 break;
435 case MATCH_DATA_MT6358:
436 pmic_core = &mt6358_core;
437 break;
438 case MATCH_DATA_MT6359:
439 pmic_core = &mt6359_core;
440 break;
441 case MATCH_DATA_MT6392:
442 pmic_core = &mt6392_core;
443 break;
444 case MATCH_DATA_MT6397:
445 pmic_core = &mt6397_core;
446 break;
447 default:
448 dev_err(&pdev->dev, "Unknown device match data %u\n", device_data);
449 return -ENODEV;
450 }
451
452 ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
453 if (ret) {
454 dev_err(&pdev->dev, "Failed to read chip id: %d\n", ret);
455 return ret;
456 }
457
458 pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
459
460 platform_set_drvdata(pdev, pmic);
461
462 pmic->irq = platform_get_irq(pdev, 0);
463 if (pmic->irq <= 0)
464 return pmic->irq;
465
466 ret = pmic_core->irq_init(pmic);
467 if (ret)
468 return ret;
469
470 ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
471 pmic_core->cells, pmic_core->cell_size,
472 NULL, 0, pmic->irq_domain);
473 if (ret) {
474 irq_domain_remove(pmic->irq_domain);
475 dev_err(&pdev->dev, "failed to add child devices: %d\n", ret);
476 }
477
478 return ret;
479 }
480
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-03-31 17:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: oe-kbuild-all, Fabien Parent, Val Packett, Luca Leonardo Scorcia,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Louis-Alexis Eyraud,
Gary Bisson, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[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/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-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/202604010103.FzAGRPye-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: 'ldo_volt_table1b' defined but not used [-Wunused-const-variable=]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Dmitry Torokhov @ 2026-03-31 20:21 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <acsNayeGbU6cRw3P@google.com>
On Mon, Mar 30, 2026 at 04:55:35PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> > Use the common USB helpers for looking up bulk and interrupt endpoints
> > instead of open coding.
>
> Applied the lot, thank you.
Actually, dropped patch #4:
https://sashiko.dev/#/patchset/20260330095948.1663141-1-johan%40kernel.org
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-04-01 1:21 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Julien Massot,
Louis-Alexis Eyraud, Gary Bisson, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[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/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010924.UuETwSKZ-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010924.UuETwSKZ-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/202604010924.UuETwSKZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: unused variable 'ldo_volt_table1b' [-Wunused-const-variable]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
1 warning generated.
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/3] snvs_pwrkey - code improvements and add report event
From: Dmitry Torokhov @ 2026-04-01 4:50 UTC (permalink / raw)
To: Joy Zou
Cc: Frank Li, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <20260326-pwrkey-cleanup-v1-0-d85d7c0bf275@nxp.com>
On Thu, Mar 26, 2026 at 06:39:37PM +0800, Joy Zou wrote:
> This patch series improves the snvs_pwrkey driver with better code quality
> and add report press event.
>
> The main improvements include:
> 1. Clean up the code by using local device pointers and dev_err_probe() for
> better readability and easier debugging.
>
> 2. Fix potential event loss during system suspend by reporting key press events
> directly in the interrupt handler.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Please address comments form here:
https://sashiko.dev/#/patchset/20260326-pwrkey-cleanup-v1-0-d85d7c0bf275%40nxp.com
Majority of them seem valid.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: core: do not allow parsing 0-sized reports
From: Dmitry Torokhov @ 2026-04-01 6:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Peter Hutterer, Kees Cook, Alan Stern,
Charles Keepax, linux-input, linux-kernel
Commit d7db259bd6df ("HID: core: factor out hid_parse_collections()")
reworked collection parsing code and inadvertently allowed returning
"success" when parsing 0-sized reports where old code returned -EINVAL.
Restore the original behavior by doing an explicit check.
Note that the error message now differs from the generic "item fetching
failed at offset %u/%u" that is now used only for non-empty descriptors.
Fixes: d7db259bd6df ("HID: core: factor out hid_parse_collections()")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index b40953e0f52e..be9d2b3356c3 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1272,6 +1272,11 @@ static int hid_parse_collections(struct hid_device *device)
device->collection[i].parent_idx = -1;
ret = -EINVAL;
+ if (start == end) {
+ hid_err(device, "rejecting 0-sized report descriptor\n");
+ goto out;
+ }
+
while ((next = fetch_item(start, end, &item)) != NULL) {
start = next;
--
2.53.0.1185.g05d4b7b318-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Johan Hovold @ 2026-04-01 7:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <acwskOMBhv9yWkD7@google.com>
On Tue, Mar 31, 2026 at 01:21:05PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 04:55:35PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> > > Use the common USB helpers for looking up bulk and interrupt endpoints
> > > instead of open coding.
> >
> > Applied the lot, thank you.
>
> Actually, dropped patch #4:
>
> https://sashiko.dev/#/patchset/20260330095948.1663141-1-johan%40kernel.org
Thanks, I saw this one last night as well (after reading the LWN
article).
I'll send a v2.
Johan
^ permalink raw reply
* [PATCH v2] Input: usbtouchscreen - refactor endpoint lookup
From: Johan Hovold @ 2026-04-01 8:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
Use the common USB helpers for looking up bulk and interrupt endpoints
(and determining endpoint numbers) instead of open coding.
Note that the NEXIO data interface has two bulk endpoints (see commit
5197424cdccc ("Input: usbtouchscreen - add NEXIO (or iNexio) support")
for the descriptors).
The lookup in probe handles both bulk-in and interrupt-in endpoints and
was added to handle NEXIO devices. Replace the open coded lookup with a
lookup for the common interrupt endpoint and an explicit fallback
accepting a bulk endpoint.
This iterates over the (two) endpoints twice for NEXIO devices but makes
it more clear what is going on.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
Changes in v2
- add the missing fallback to handle bulk endpoints to probe
- amend commit message
drivers/input/touchscreen/usbtouchscreen.c | 43 ++++++++--------------
1 file changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 657555c8796c..daa28135f887 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -969,24 +969,21 @@ static int nexio_init(struct usbtouch_usb *usbtouch)
{
struct usb_device *dev = interface_to_usbdev(usbtouch->interface);
struct usb_host_interface *interface = usbtouch->interface->cur_altsetting;
+ struct usb_endpoint_descriptor *ep_in, *ep_out;
struct nexio_priv *priv = usbtouch->priv;
- int ret = -ENOMEM;
int actual_len, i;
char *firmware_ver = NULL, *device_name = NULL;
- int input_ep = 0, output_ep = 0;
+ int input_ep, output_ep;
+ int ret;
/* find first input and output endpoint */
- for (i = 0; i < interface->desc.bNumEndpoints; i++) {
- if (!input_ep &&
- usb_endpoint_dir_in(&interface->endpoint[i].desc))
- input_ep = interface->endpoint[i].desc.bEndpointAddress;
- if (!output_ep &&
- usb_endpoint_dir_out(&interface->endpoint[i].desc))
- output_ep = interface->endpoint[i].desc.bEndpointAddress;
- }
- if (!input_ep || !output_ep)
+ ret = usb_find_common_endpoints(interface, &ep_in, &ep_out, NULL, NULL);
+ if (ret)
return -ENXIO;
+ input_ep = usb_endpoint_num(ep_in);
+ output_ep = usb_endpoint_num(ep_out);
+
u8 *buf __free(kfree) = kmalloc(NEXIO_BUFSIZE, GFP_NOIO);
if (!buf)
return -ENOMEM;
@@ -1427,18 +1424,6 @@ static void usbtouch_free_buffers(struct usb_device *udev,
kfree(usbtouch->buffer);
}
-static struct usb_endpoint_descriptor *
-usbtouch_get_input_endpoint(struct usb_host_interface *interface)
-{
- int i;
-
- for (i = 0; i < interface->desc.bNumEndpoints; i++)
- if (usb_endpoint_dir_in(&interface->endpoint[i].desc))
- return &interface->endpoint[i].desc;
-
- return NULL;
-}
-
static int usbtouch_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1447,17 +1432,21 @@ static int usbtouch_probe(struct usb_interface *intf,
struct usb_endpoint_descriptor *endpoint;
struct usb_device *udev = interface_to_usbdev(intf);
const struct usbtouch_device_info *type;
- int err = -ENOMEM;
+ int err;
/* some devices are ignored */
type = (const struct usbtouch_device_info *)id->driver_info;
if (!type)
return -ENODEV;
- endpoint = usbtouch_get_input_endpoint(intf->cur_altsetting);
- if (!endpoint)
- return -ENXIO;
+ err = usb_find_int_in_endpoint(intf->cur_altsetting, &endpoint);
+ if (err) {
+ err = usb_find_bulk_in_endpoint(intf->cur_altsetting, &endpoint);
+ if (err)
+ return -ENXIO;
+ }
+ err = -ENOMEM;
usbtouch = kzalloc_obj(*usbtouch);
input_dev = input_allocate_device();
if (!usbtouch || !input_dev)
--
2.52.0
^ permalink raw reply related
* [syzbot] [input?] [usb?] KASAN: slab-use-after-free Read in hiddev_disconnect (4)
From: syzbot @ 2026-04-01 9:33 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 46b513250491 Merge tag 'v7.0-rc5-smb3-client-fix' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=177c11da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=5a3e5e8c17cc174e
dashboard link: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-46b51325.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/22fdb6baf246/vmlinux-46b51325.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a3a69d9008ed/bzImage-46b51325.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com
usb 6-1: USB disconnect, device number 25
==================================================================
BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x23b/0x260 kernel/locking/spinlock_debug.c:115
Read of size 4 at addr ffff8880289f981c by task kworker/1:3/6000
CPU: 1 UID: 0 PID: 6000 Comm: kworker/1:3 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x156/0x4c9 mm/kasan/report.c:482
kasan_report+0xdf/0x1e0 mm/kasan/report.c:595
debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
do_raw_spin_lock+0x23b/0x260 kernel/locking/spinlock_debug.c:115
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock_irqsave+0x42/0x60 kernel/locking/spinlock.c:162
__mutex_unlock_slowpath+0x18b/0x790 kernel/locking/mutex.c:963
hiddev_disconnect+0x15b/0x1d0 drivers/hid/usbhid/hiddev.c:940
hid_disconnect+0xbe/0x1b0 drivers/hid/hid-core.c:2353
hid_hw_stop drivers/hid/hid-core.c:2400 [inline]
hid_device_remove+0x1b2/0x270 drivers/hid/hid-core.c:2834
device_remove+0xcb/0x180 drivers/base/dd.c:631
__device_release_driver drivers/base/dd.c:1344 [inline]
device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1367
bus_remove_device+0x2bc/0x560 drivers/base/bus.c:657
device_del+0x376/0x9b0 drivers/base/core.c:3880
hid_remove_device drivers/hid/hid-core.c:3009 [inline]
hid_destroy_device+0x19c/0x240 drivers/hid/hid-core.c:3031
usbhid_disconnect+0xa0/0xe0 drivers/hid/usbhid/hid-core.c:1477
usb_unbind_interface+0x1dd/0x9e0 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:633 [inline]
device_remove+0x12a/0x180 drivers/base/dd.c:625
__device_release_driver drivers/base/dd.c:1344 [inline]
device_release_driver_internal+0x44e/0x620 drivers/base/dd.c:1367
bus_remove_device+0x2bc/0x560 drivers/base/bus.c:657
device_del+0x376/0x9b0 drivers/base/core.c:3880
usb_disable_device+0x367/0x810 drivers/usb/core/message.c:1476
usb_disconnect+0x2e2/0x9a0 drivers/usb/core/hub.c:2345
hub_port_connect drivers/usb/core/hub.c:5407 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
port_event drivers/usb/core/hub.c:5871 [inline]
hub_event+0x1d0c/0x4af0 drivers/usb/core/hub.c:5953
process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
process_scheduled_works kernel/workqueue.c:3359 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 24:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
hiddev_connect+0x259/0x5d0 drivers/hid/usbhid/hiddev.c:893
hid_connect+0x241/0x1750 drivers/hid/hid-core.c:2267
hid_hw_start+0xaa/0x140 drivers/hid/hid-core.c:2380
plantronics_probe+0x2b9/0x3a0 drivers/hid/hid-plantronics.c:209
__hid_device_probe drivers/hid/hid-core.c:2776 [inline]
hid_device_probe+0x50e/0x800 drivers/hid/hid-core.c:2813
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:2952
usbhid_probe+0xd57/0x1350 drivers/hid/usbhid/hid-core.c:1450
usb_probe_interface+0x303/0x8f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
usb_set_configuration+0xd97/0x1c60 drivers/usb/core/message.c:2266
usb_generic_driver_probe+0xa1/0xe0 drivers/usb/core/generic.c:250
usb_probe_device+0xef/0x400 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
usb_new_device.cold+0x685/0x115c drivers/usb/core/hub.c:2695
hub_port_connect drivers/usb/core/hub.c:5567 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
port_event drivers/usb/core/hub.c:5871 [inline]
hub_event+0x314d/0x4af0 drivers/usb/core/hub.c:5953
process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
process_scheduled_works kernel/workqueue.c:3359 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 11803:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kfree+0x1f6/0x6b0 mm/slub.c:6483
hiddev_release+0x40d/0x520 drivers/hid/usbhid/hiddev.c:232
__fput+0x3ff/0xb40 fs/file_table.c:469
task_work_run+0x150/0x240 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x100/0x4a0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x67c/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8880289f9800
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 28 bytes inside of
freed 512-byte region [ffff8880289f9800, ffff8880289f9a00)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff8880289f8c00 pfn:0x289f8
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000240(workingset|head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000240 ffff88801b842c80 ffffea0000b3f710 ffffea00015f9410
raw: ffff8880289f8c00 0000000800100008 00000000f5000000 0000000000000000
head: 00fff00000000240 ffff88801b842c80 ffffea0000b3f710 ffffea00015f9410
head: ffff8880289f8c00 0000000800100008 00000000f5000000 0000000000000000
head: 00fff00000000002 ffffea0000a27e01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 10245, tgid 10245 (udevd), ts 189371739713, free_ts 189294134261
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x111d/0x3140 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x27c/0x2ba0 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab mm/slub.c:3481 [inline]
new_slab+0xa6/0x6b0 mm/slub.c:3539
refill_objects+0x26b/0x400 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x1ab/0x660 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
__kmalloc_cache_noprof+0x493/0x6f0 mm/slub.c:5375
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
kernfs_fop_open+0x23d/0xd50 fs/kernfs/file.c:641
do_dentry_open+0x6d8/0x1660 fs/open.c:949
vfs_open+0x82/0x3f0 fs/open.c:1081
do_open fs/namei.c:4671 [inline]
path_openat+0x208c/0x31a0 fs/namei.c:4830
do_file_open+0x20e/0x430 fs/namei.c:4859
do_sys_openat2+0x10d/0x1e0 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 11125 tgid 11125 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0x7e1/0x10d0 mm/page_alloc.c:2978
stack_depot_save_flags+0x435/0x9d0 lib/stackdepot.c:735
kasan_save_stack+0x3f/0x50 mm/kasan/common.c:58
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
ida_alloc_range+0x464/0x830 lib/idr.c:420
ida_alloc include/linux/idr.h:293 [inline]
create_worker+0x99/0x750 kernel/workqueue.c:2796
maybe_create_worker kernel/workqueue.c:3075 [inline]
manage_workers kernel/workqueue.c:3152 [inline]
worker_thread+0x8e2/0xe50 kernel/workqueue.c:3415
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff8880289f9700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880289f9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8880289f9800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880289f9880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880289f9900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v4 3/4] Input: aw86938 - add driver for Awinic AW86938
From: Luca Weiss @ 2026-04-01 14:44 UTC (permalink / raw)
To: Dmitry Torokhov, Griffin Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Luca Weiss, linux-input, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <aae7fRYaoDHMptyu@google.com>
Hi Dmitry,
On Wed Mar 4, 2026 at 5:56 AM CET, Dmitry Torokhov wrote:
> On Mon, Mar 02, 2026 at 11:50:27AM +0100, Griffin Kroah-Hartman wrote:
>> Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
>>
>> The AW86938 has a similar but slightly different register layout. In
>> particular, the boost mode register values.
>> The AW86938 also has some extra features that aren't implemented
>> in this driver yet.
>>
>> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
>
> Applied, thank you.
I'm curious, where did you apply these patches? linux-next doesn't have
it and I don't see it in your kernel.org repo either.
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
Did this slip through the cracks or will these patches still appear
there?
Regards
Luca
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: fix race condition when accessing stale stack pointer
From: Benoit Sevens @ 2026-04-01 14:48 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
Benoît Sevens
From: Benoît Sevens <bsevens@google.com>
The driver uses hidpp->send_receive_buf to point to a stack-allocated
buffer in the synchronous command path (__do_hidpp_send_message_sync).
However, this pointer is not cleared when the function returns.
If an event is processed (e.g. by a different thread) while the
send_mutex is held by a new command, but before that command has
updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
observe that the mutex is locked and dereference the stale pointer.
This results in an out-of-bounds access on a different thread's kernel
stack (or a NULL pointer dereference on the very first command).
Fix this by:
1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
in the synchronous command path.
2. Moving the assignment of the local 'question' and 'answer' pointers
inside the mutex_is_locked() block in the handler, and adding
a NULL check before dereferencing.
Signed-off-by: Benoît Sevens <bsevens@google.com>
---
drivers/hid/hid-logitech-hidpp.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index e871f1729d4b..42f7ea5b25dc 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -306,21 +306,22 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
if (ret) {
dbg_hid("__hidpp_send_report returned err: %d\n", ret);
memset(response, 0, sizeof(struct hidpp_report));
- return ret;
+ goto out;
}
if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
5*HZ)) {
dbg_hid("%s:timeout waiting for response\n", __func__);
memset(response, 0, sizeof(struct hidpp_report));
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
response->rap.sub_id == HIDPP_ERROR) {
ret = response->rap.params[1];
dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
if ((response->report_id == REPORT_ID_HIDPP_LONG ||
@@ -328,10 +329,14 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
response->fap.feature_index == HIDPP20_ERROR) {
ret = response->fap.params[1];
dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
- return 0;
+ ret = 0;
+
+out:
+ hidpp->send_receive_buf = NULL;
+ return ret;
}
/*
@@ -3840,8 +3845,7 @@ static int hidpp_input_configured(struct hid_device *hdev,
static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
int size)
{
- struct hidpp_report *question = hidpp->send_receive_buf;
- struct hidpp_report *answer = hidpp->send_receive_buf;
+ struct hidpp_report *question, *answer;
struct hidpp_report *report = (struct hidpp_report *)data;
int ret;
int last_online;
@@ -3851,6 +3855,12 @@ static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
* previously sent command.
*/
if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
+ question = hidpp->send_receive_buf;
+ answer = hidpp->send_receive_buf;
+
+ if (!question)
+ return 0;
+
/*
* Check for a correct hidpp20 answer or the corresponding
* error
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
From: Werner Sembach @ 2026-04-01 15:48 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <aZzMe2-4IqzIg3HS@google.com>
Hello Dmitry
Am 23.02.26 um 22:54 schrieb Dmitry Torokhov:
> On Mon, Feb 23, 2026 at 03:20:45PM +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>
> Applied, thank you.
>
May i ask you where it was applied?
I can only find the former patch
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?id=aed3716db7fff74919cc5775ca3a80c8bb246489
for the InfinityBook Max 15 and not this one for the InfinityBook Max 16 (both
patches have a nearly identical subject line).
Also I forgot to add cc stable, if the patch is not yet applied, can you add it
before?
Best regards,
Werner
^ permalink raw reply
* Re: [PATCH v4 3/4] Input: aw86938 - add driver for Awinic AW86938
From: Dmitry Torokhov @ 2026-04-01 16:11 UTC (permalink / raw)
To: Luca Weiss
Cc: Griffin Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <DHHWDE7QEOTO.1AQ85UBLO8IQG@fairphone.com>
On Wed, Apr 01, 2026 at 04:44:47PM +0200, Luca Weiss wrote:
> Hi Dmitry,
>
> On Wed Mar 4, 2026 at 5:56 AM CET, Dmitry Torokhov wrote:
> > On Mon, Mar 02, 2026 at 11:50:27AM +0100, Griffin Kroah-Hartman wrote:
> >> Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
> >>
> >> The AW86938 has a similar but slightly different register layout. In
> >> particular, the boost mode register values.
> >> The AW86938 also has some extra features that aren't implemented
> >> in this driver yet.
> >>
> >> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
> >
> > Applied, thank you.
>
> I'm curious, where did you apply these patches? linux-next doesn't have
> it and I don't see it in your kernel.org repo either.
> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
>
> Did this slip through the cracks or will these patches still appear
> there?
My bad, I think there was a conflict with Dan Carpenter's patch and as a
result the series got stuck in my internal queue. My apologies.
Should be out in 'next' branch now.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
From: Dmitry Torokhov @ 2026-04-01 16:22 UTC (permalink / raw)
To: Werner Sembach; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <11135d8c-ef30-410a-a94a-4e11e062c27b@tuxedocomputers.com>
Hi Werner,
On Wed, Apr 01, 2026 at 05:48:20PM +0200, Werner Sembach wrote:
> Hello Dmitry
>
> Am 23.02.26 um 22:54 schrieb Dmitry Torokhov:
> > On Mon, Feb 23, 2026 at 03:20:45PM +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>
> > Applied, thank you.
> >
> May i ask you where it was applied?
>
> I can only find the former patch https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?id=aed3716db7fff74919cc5775ca3a80c8bb246489
> for the InfinityBook Max 15 and not this one for the InfinityBook Max 16
> (both patches have a nearly identical subject line).
Isn't it this:
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=5839419cffc7788a356428d321e3ec18055c0286
?
>
> Also I forgot to add cc stable, if the patch is not yet applied, can you add
> it before?
I added the tags to the commit above (unless it is not the right one,
they all look very similar).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
From: Werner Sembach @ 2026-04-01 17:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <ac1FzV9dmb_JDXxo@google.com>
Hello Dmitry,
Am 01.04.26 um 18:22 schrieb Dmitry Torokhov:
> Hi Werner,
>
> On Wed, Apr 01, 2026 at 05:48:20PM +0200, Werner Sembach wrote:
>> Hello Dmitry
>>
>> Am 23.02.26 um 22:54 schrieb Dmitry Torokhov:
>>> On Mon, Feb 23, 2026 at 03:20:45PM +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>
>>> Applied, thank you.
>>>
>> May i ask you where it was applied?
>>
>> I can only find the former patch https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?id=aed3716db7fff74919cc5775ca3a80c8bb246489
>> for the InfinityBook Max 15 and not this one for the InfinityBook Max 16
>> (both patches have a nearly identical subject line).
> Isn't it this:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=5839419cffc7788a356428d321e3ec18055c0286
>
> ?
Yes, thanks and sorry I somehow missed to search the for-linus branch.
>
>> Also I forgot to add cc stable, if the patch is not yet applied, can you add
>> it before?
> I added the tags to the commit above (unless it is not the right one,
> they all look very similar).
Yes, it's the one I was talking about. Maybe the next time I add the board name
to the subject line in the hope that it makes it a little bit more clear.
Thank you very much,
Werner
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH] HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)
From: Denis Benato @ 2026-04-01 17:40 UTC (permalink / raw)
To: Thorsten Leemhuis, honjow, Jiri Kosina, Benjamin Tissoires
Cc: linux-kernel, linux-input, Linux kernel regressions list
In-Reply-To: <6268c55d-2f1b-473c-b82d-1de1416d14b0@leemhuis.info>
On 3/31/26 08:25, Thorsten Leemhuis wrote:
> On 3/24/26 02:38, honjow wrote:
>> The OEM USB HID interface found on GPD Win handhelds (VID 2f24, registered
>> to ShenZhen HuiJiaZhi / GameSir, PID 0137) declares 63-byte Input and
>> Feature reports for Report ID 1, but the firmware only transfers 11 data
>> bytes per interrupt.
>>
>> Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
>> bogus memset()"), the HID core rejects undersized reports instead of zero-
>> padding them. This breaks the device entirely on kernels >= v7.0-rc5.
>>
>> Fix it by patching the report descriptor in report_fixup(), reducing
>> Report Count from 63 to 11 for both Input and Feature.
>>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221271
>> Signed-off-by: honjow <honjow311@gmail.com>
>> ---
>> drivers/hid/Kconfig | 10 +++++++++
>> drivers/hid/Makefile | 1 +
>> drivers/hid/hid-gpd.c | 52 +++++++++++++++++++++++++++++++++++++++++++
>> drivers/hid/hid-ids.h | 3 +++
>> 4 files changed, 66 insertions(+)
>> create mode 100644 drivers/hid/hid-gpd.c
>>
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 10c12d8e65579..20c60f5aca4c5 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -419,6 +419,16 @@ config HID_GLORIOUS
>> Support for Glorious PC Gaming Race mice such as
>> the Glorious Model O, O- and D.
>>
>> +config HID_GPD
>> + tristate "GPD Win handheld OEM HID support"
> Hmmm, why does this need to be a config option? Can't this be enabled
> unconditionally? I ask in general, as it's just another point where
> things can go wrong. But I mainly ask because it's a regression fix –
> and from my understanding wrt to what Linus wants we don't expect users
> to turn some .config on to keep their hardware running (unless it can't
> be avoided at all costs).
>
> Ciao, Thorsten
>
Perhaps the place of this, just for affected kernel series that are out
(assuming stable has the bug, I haven't checked) is to do this on hid-generic,
otherwise it's a change of driver managing the device?
>> + depends on USB_HID
>> + help
>> + Report descriptor fix for the OEM USB HID interface (GameSir
>> + 2f24:0137) found on GPD Win handhelds. The firmware declares 63-byte
>> + reports but only sends 11 bytes, which the HID core rejects.
>> +
>> + Say Y or M here if you use a GPD Win handheld with this interface.
>> +
>> config HID_HOLTEK
>> tristate "Holtek HID devices"
>> depends on USB_HID
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index 07dfdb6a49c59..03ef72ec4499f 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -53,6 +53,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
>> obj-$(CONFIG_HID_EVISION) += hid-evision.o
>> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
>> obj-$(CONFIG_HID_FT260) += hid-ft260.o
>> +obj-$(CONFIG_HID_GPD) += hid-gpd.o
>> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
>> obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
>> obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
>> diff --git a/drivers/hid/hid-gpd.c b/drivers/hid/hid-gpd.c
>> new file mode 100644
>> index 0000000000000..5b4d203e24995
>> --- /dev/null
>> +++ b/drivers/hid/hid-gpd.c
>> @@ -0,0 +1,52 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * HID report descriptor fixup for GPD Win handhelds.
>> + *
>> + * The OEM HID interface (VID 2f24 / GameSir, PID 0137) declares Report ID 1
>> + * with Report Count 63 (8-bit fields) for both Input and Feature, but the
>> + * firmware only sends 11 bytes of payload after the report ID.
>> + */
>> +
>> +#include <linux/hid.h>
>> +#include <linux/module.h>
>> +
>> +#include "hid-ids.h"
>> +
>> +#define RDESC_LEN 38
>> +#define RPT_COUNT_INPUT_OFF 21
>> +#define RPT_COUNT_FEATURE_OFF 34
>> +
>> +static const __u8 *gpd_report_fixup(struct hid_device *hdev, __u8 *rdesc,
>> + unsigned int *rsize)
>> +{
>> + if (*rsize != RDESC_LEN)
>> + return rdesc;
>> +
>> + if (rdesc[RPT_COUNT_INPUT_OFF - 1] == 0x95 &&
>> + rdesc[RPT_COUNT_INPUT_OFF] == 0x3f &&
>> + rdesc[RPT_COUNT_FEATURE_OFF - 1] == 0x95 &&
>> + rdesc[RPT_COUNT_FEATURE_OFF] == 0x3f) {
>> + hid_info(hdev, "fixing report counts (63 -> 11 bytes)\n");
>> + rdesc[RPT_COUNT_INPUT_OFF] = 11;
>> + rdesc[RPT_COUNT_FEATURE_OFF] = 11;
>> + }
>> +
>> + return rdesc;
>> +}
>> +
>> +static const struct hid_device_id gpd_devices[] = {
>> + { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137) },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(hid, gpd_devices);
>> +
>> +static struct hid_driver gpd_driver = {
>> + .name = "gpd",
>> + .id_table = gpd_devices,
>> + .report_fixup = gpd_report_fixup,
>> +};
>> +
>> +module_hid_driver(gpd_driver);
>> +
>> +MODULE_DESCRIPTION("HID report descriptor fix for GPD Win handheld (GameSir 2f24:0137)");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>> index 933b7943bdb50..d0a6c19baa660 100644
>> --- a/drivers/hid/hid-ids.h
>> +++ b/drivers/hid/hid-ids.h
>> @@ -533,6 +533,9 @@
>> #define USB_VENDOR_ID_FRUCTEL 0x25B6
>> #define USB_DEVICE_ID_GAMETEL_MT_MODE 0x0002
>>
>> +#define USB_VENDOR_ID_GAMESIR 0x2f24
>> +#define USB_DEVICE_ID_GAMESIR_0137 0x0137
>> +
>> #define USB_VENDOR_ID_GAMEVICE 0x27F8
>> #define USB_DEVICE_ID_GAMEVICE_GV186 0x0BBE
>> #define USB_DEVICE_ID_GAMEVICE_KISHI 0x0BBF
^ permalink raw reply
* [PATCH v2] HID: pulsar: add driver for Pulsar gaming mice
From: Nikolas Koesling @ 2026-04-01 18:57 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel, Leo
Add a HID driver for Pulsar wireless gaming mice (X2 V2, X2H, X2A,
Xlite V3). The driver exposes battery level, voltage, and charging
status through the power supply framework. It supports wired, 1kHz,
and 4kHz wireless dongle connections.
The driver also supports Kysona M600 ATK, VXE R1 SE+ and
VXE Dragonfly R1 Pro, which use the same protocol for reading
battery status and availibility.
The protocol used by this driver is based on findings from
python-pulsar-mouse-tool by Andrew Rabert (MIT License):
https://github.com/andrewrabert/python-pulsar-mouse-tool
ATK vendor and device IDs were provided by Leo <leo@managarm.org>.
VXE and Kysona vendor and device IDS are from hid-kysona.c by
Lode Willems <me@lodewillems.com>
Tested-by: Leo <leo@managarm.org>
Signed-off-by: Nikolas Koesling <nikolas@koesling.info>
---
Changes in v2:
- Add support for Kysona M600, ATK VXE R1 SE+, and VXE Dragonfly R1 Pro
- Add device type enum to distinguish vendors and generate proper
battery names per vendor/model
- Add mutual exclusion with HID_KYSONA in Kconfig
- Add ATK and VXE vendor/device IDs to hid-ids.h
- Refactor model name generation: extract model_pulsar() and add
model_atk() for vendor-specific battery naming
- Fall back to hdev->name for battery model when device info read
fails on non-Pulsar devices (downgrade error to debug log)
- Remove POWER_SUPPLY_PROP_MANUFACTURER property
- Pass device type via driver_data in hid_device_id table
---
MAINTAINERS | 6 +
drivers/hid/Kconfig | 15 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 15 +
drivers/hid/hid-pulsar.c | 754 +++++++++++++++++++++++++++++++++++++++
5 files changed, 791 insertions(+)
create mode 100644 drivers/hid/hid-pulsar.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c3fe46d7c4bc..207216632918 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11352,6 +11352,12 @@ L: linux-input@vger.kernel.org
S: Supported
F: drivers/hid/hid-playstation.c
+HID PULSAR DRIVER
+M: Nikolas Koesling <nikolas@koesling.info>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/hid/hid-pulsar.c
+
HID SENSOR HUB DRIVERS
M: Jiri Kosina <jikos@kernel.org>
M: Jonathan Cameron <jic23@kernel.org>
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index c1d9f7c6a5f2..333d165554ee 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -511,12 +511,15 @@ config HID_KYE
config HID_KYSONA
tristate "Kysona devices"
depends on USB_HID
+ depends on !HID_PULSAR
help
Support for Kysona mice.
Say Y here if you have a Kysona M600 mouse
and want to be able to read its battery capacity.
+ Note: The Kysona M600 is also supported by HID_PULSAR.
+
config HID_UCLOGIC
tristate "UC-Logic"
depends on USB_HID
@@ -1280,6 +1283,18 @@ config HID_UNIVERSAL_PIDFF
Supports Moza Racing, Cammus, VRS, FFBeast and more.
+config HID_PULSAR
+ tristate "Pulsar gaming mouse support"
+ depends on USB_HID
+ select POWER_SUPPLY
+ help
+ Support for Pulsar gaming mice (X2 V2, X2H, X2A, Xlite V3)
+ connected via 1kHz/4kHz USB dongle or wired.
+ Provides battery level, voltage, and charging status
+ monitoring via the power supply framework.
+
+ Additional supported devices: Kysona M600, ATK VXE R1 SE+
+
config HID_WACOM
tristate "Wacom Intuos/Graphire tablet support (USB)"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index e01838239ae6..67ad39b47df1 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -112,6 +112,7 @@ hid-picolcd-$(CONFIG_DEBUG_FS) += hid-picolcd_debugfs.o
obj-$(CONFIG_HID_PLANTRONICS) += hid-plantronics.o
obj-$(CONFIG_HID_PLAYSTATION) += hid-playstation.o
obj-$(CONFIG_HID_PRIMAX) += hid-primax.o
+obj-$(CONFIG_HID_PULSAR) += hid-pulsar.o
obj-$(CONFIG_HID_PXRC) += hid-pxrc.o
obj-$(CONFIG_HID_RAPOO) += hid-rapoo.o
obj-$(CONFIG_HID_RAZER) += hid-razer.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index afcee13bad61..5ce542150d61 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -248,6 +248,12 @@
#define USB_VENDOR_ID_ATMEL_V_USB 0x16c0
#define USB_DEVICE_ID_ATMEL_V_USB 0x05df
+#define USB_VENDOR_ID_ATK 0x373B
+#define USB_DEVICE_ID_ATK_VXE_R1_SE_WIRED 0xF58F
+
+#define USB_VENDOR_ID_ATK_ALT 0x3554
+#define USB_DEVICE_ID_ATK_VXE_R1_SE_DONGLE 0x1085
+
#define USB_VENDOR_ID_AUREAL 0x0755
#define USB_DEVICE_ID_AUREAL_W01RN 0x2626
@@ -1169,6 +1175,11 @@
#define USB_VENDOR_ID_PRODIGE 0x05af
#define USB_DEVICE_ID_PRODIGE_CORDLESS 0x3062
+#define USB_VENDOR_ID_PULSAR 0x3554
+#define USB_DEVICE_ID_PULSAR_WIRED 0xf507
+#define USB_DEVICE_ID_PULSAR_1KHZ 0xf508
+#define USB_DEVICE_ID_PULSAR_4KHZ 0xf509
+
#define I2C_VENDOR_ID_QTEC 0x6243
#define USB_VENDOR_ID_QUANTA 0x0408
@@ -1471,6 +1482,10 @@
#define USB_VENDOR_ID_VTL 0x0306
#define USB_DEVICE_ID_VTL_MULTITOUCH_FF3F 0xff3f
+#define USB_VENDOR_ID_VXE 0x3554
+#define USB_DEVICE_ID_VXE_DRAGONFLY_R1_PRO_DONGLE 0xf58a
+#define USB_DEVICE_ID_VXE_DRAGONFLY_R1_PRO_WIRED 0xf58c
+
#define USB_VENDOR_ID_WACOM 0x056a
#define USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH 0x81
#define USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH 0x00BD
diff --git a/drivers/hid/hid-pulsar.c b/drivers/hid/hid-pulsar.c
new file mode 100644
index 000000000000..1c6a4f485d76
--- /dev/null
+++ b/drivers/hid/hid-pulsar.c
@@ -0,0 +1,754 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HID driver for pulsar mice
+ *
+ * Supported pulsar devices:
+ * - Pulsar
+ * - X2 V2
+ * - X2H
+ * - X2A
+ * - Xlite V3
+ * - Kysona
+ * -M600
+ * - ATK
+ * - VXE R1 SE+
+ * - VXE
+ * - Dragonfly R1 Pro
+ *
+ * Copyright (c) 2026 Nikolas Koesling
+ */
+
+#include <linux/hid.h>
+#include <linux/usb.h>
+#include <linux/power_supply.h>
+#include "hid-ids.h"
+
+/* ----- driver settings ----- */
+#define CMD_TIMEOUT_MSEC 100
+#define MAX_BATTERY_AGE_NS 60000000000ULL /* 60s */
+#define MAX_UNAVAIL_AGE_NS 5000000000ULL /* 5s */
+#define INIT_RETRIES 1
+#define INIT_DELAY_MSEC 1000
+
+/* ----- constants ----- */
+#define USB_INTERFACE 1
+#define USB_PAYLOAD_LEN 17
+#define CMD_HID_REPORT_ID 0x08
+#define CHECKSUM_MAGIC 0x55
+#define DEV_INFO_LEN 4
+#define CON_1K 0x00
+#define CON_4K 0x01
+#define CON_WIRED 0x02
+
+/* ----- device commands ----- */
+enum pulsar_cmd {
+ CMD_NONE = 0,
+ CMD_INFO = 0x01,
+ CMD_STATUS = 0x03,
+ CMD_POWER = 0x04,
+ CMD_EVENT = 0x0a, /* recv only */
+};
+
+#define EVENT_PWR 0x40 /* power status change */
+#define EVENT_PWR_CHK 0xf9
+
+/* ----- device types ----- */
+enum dev_type {
+ TYPE_UNKNOWN,
+ TYPE_PULSAR,
+ TYPE_KYSONA,
+ TYPE_ATK,
+ TYPE_VXE,
+};
+
+/* ----- structs ----- */
+struct pulsar_battery {
+ struct power_supply *ps;
+ struct power_supply_desc desc;
+ char name[48];
+ char model[32];
+ u8 level; /* percent */
+ u16 voltage; /* millivolts */
+ bool conn;
+ bool available;
+ u64 last_read;
+ u64 last_status;
+};
+
+struct pulsar_data {
+ struct hid_device *hdev;
+
+ enum dev_type type;
+
+ spinlock_t raw_event_lock; /* protects response_buf, pending_event */
+ struct mutex lock_cmd; /* serializes device command execution */
+ struct rw_semaphore lock_bat; /* protects battery state */
+
+ struct completion response_ready;
+ u8 response_buf[USB_PAYLOAD_LEN];
+ u8 pending_event;
+ struct work_struct power_uevent_work;
+ struct delayed_work init_work;
+ unsigned int init_retries;
+ atomic_t device_verified;
+ atomic_t stopping;
+
+ struct pulsar_battery battery;
+};
+
+static u8 calc_checksum(const u8 *data, size_t len)
+{
+ u8 sum = 0;
+
+ for (size_t i = 0; i < len - 1; i++)
+ sum += data[i];
+
+ return (u8)CHECKSUM_MAGIC - sum;
+}
+
+static int send_cmd(struct hid_device *hdev, const u8 *buf, size_t len)
+{
+ int ret;
+ u8 *dmabuf;
+
+ hid_dbg(hdev, "send command: %*ph\n", (int)len, buf);
+
+ dmabuf = kmemdup(buf, len, GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ /* device listens only to control transfers */
+ ret = hid_hw_raw_request(hdev, dmabuf[0], dmabuf, len,
+ HID_OUTPUT_REPORT, HID_REQ_SET_REPORT);
+
+ kfree(dmabuf);
+
+ if (ret < 0)
+ return ret;
+ if (ret != len)
+ return -EIO;
+
+ return 0;
+}
+
+static int exec_cmd(struct pulsar_data *drvdata, const u8 *payload,
+ u8 *response, unsigned int timeout_msec)
+{
+ struct hid_device *hdev = drvdata->hdev;
+ unsigned long flags;
+ int ret;
+ unsigned long timeout;
+ u8 checksum;
+
+ if (atomic_read(&drvdata->stopping))
+ return -ENODEV;
+
+ mutex_lock(&drvdata->lock_cmd);
+
+ if (atomic_read(&drvdata->stopping)) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ reinit_completion(&drvdata->response_ready);
+ drvdata->pending_event = payload[1];
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+
+ ret = send_cmd(hdev, payload, USB_PAYLOAD_LEN);
+
+ if (ret < 0) {
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ drvdata->pending_event = CMD_NONE;
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+ hid_err(hdev, "failed to send command 0x%02x: %d\n",
+ payload[1], ret);
+ goto out;
+ }
+
+ timeout = wait_for_completion_timeout(&drvdata->response_ready,
+ msecs_to_jiffies(timeout_msec));
+
+ if (timeout == 0) {
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ drvdata->pending_event = CMD_NONE;
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ memcpy(response, drvdata->response_buf, USB_PAYLOAD_LEN);
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+
+ /* validate checksum */
+ checksum = calc_checksum(response, USB_PAYLOAD_LEN);
+
+ if (response[USB_PAYLOAD_LEN - 1] != checksum) {
+ hid_err(hdev,
+ "invalid checksum in response: 0x%02x (expected 0x%02x)\n",
+ response[USB_PAYLOAD_LEN - 1], checksum);
+ ret = -EIO;
+ goto out;
+ }
+
+ ret = 0;
+out:
+ mutex_unlock(&drvdata->lock_cmd);
+ return ret;
+}
+
+static inline void finalize_payload(u8 *payload, u8 cmd)
+{
+ payload[0] = CMD_HID_REPORT_ID;
+ payload[1] = cmd;
+ payload[USB_PAYLOAD_LEN - 1] = calc_checksum(payload, USB_PAYLOAD_LEN);
+}
+
+static int read_status(struct pulsar_data *drvdata)
+{
+ int ret;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+
+ finalize_payload(payload, CMD_STATUS);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0)
+ return ret;
+ if (response[6] > 0x01)
+ return -EIO;
+
+ return (int)response[6]; /* 1: available, 0: not available */
+}
+
+static int read_device_info(struct pulsar_data *drvdata, u8 *data)
+{
+ int ret;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+
+ payload[5] = DEV_INFO_LEN * 2;
+ get_random_bytes(payload + 6, DEV_INFO_LEN);
+ finalize_payload(payload, CMD_INFO);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0)
+ return ret;
+
+ if (data)
+ memcpy(data, response + 6 + DEV_INFO_LEN, DEV_INFO_LEN);
+
+ response[8 + DEV_INFO_LEN] = 0;
+ response[9 + DEV_INFO_LEN] = 0;
+
+ /*
+ * Verify challenge-response. Response layout from offset 6:
+ * [0..3] encoded response [4..7] device info (ID + conn type)
+ *
+ * resp[i] = challenge[i] * (i+1) + challenge[(i+1) % 4] + device_id[i]
+ *
+ * bytes 6..7 are zeroed for verification.
+ */
+ for (int i = 0; i < DEV_INFO_LEN; i++) {
+ u8 expect = response[6 + DEV_INFO_LEN + i];
+ u8 actual = response[6 + i] - (i + 1) * payload[6 + i] -
+ payload[6 + (i + 1) % DEV_INFO_LEN];
+
+ if (expect != actual) {
+ hid_warn(drvdata->hdev,
+ "device info[%d] mismatch: %02x != %02x\n",
+ i, expect, actual);
+ return -EIO;
+ }
+ }
+
+ return 0;
+}
+
+static int read_power(struct pulsar_data *drvdata)
+{
+ u64 now;
+ bool need_status, need_power;
+ int ret = 0;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+ struct pulsar_battery *battery = &drvdata->battery;
+
+ now = ktime_get_ns();
+
+ down_write(&drvdata->lock_bat);
+
+ need_status = (now - battery->last_status >= MAX_UNAVAIL_AGE_NS);
+ need_power = battery->available &&
+ (now - battery->last_read >= MAX_BATTERY_AGE_NS);
+
+ if (!need_status && !need_power)
+ goto unlock;
+
+ if (need_status) {
+ ret = read_status(drvdata);
+ if (ret < 0) {
+ hid_err(drvdata->hdev,
+ "%s: failed to read status: %d\n",
+ __func__, ret);
+ goto unlock;
+ }
+
+ battery->last_status = now;
+
+ if (!ret) {
+ battery->available = false;
+ goto unlock;
+ }
+
+ /* device just became available, force power read */
+ if (!battery->available)
+ need_power = true;
+ }
+
+ if (!need_power)
+ goto unlock;
+
+ finalize_payload(payload, CMD_POWER);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0) {
+ hid_err(drvdata->hdev, "%s: failed to read power: %d\n",
+ __func__, ret);
+ goto unlock;
+ }
+
+ if (response[6] > 100 || response[7] > 0x01) {
+ ret = -EIO;
+ goto unlock;
+ }
+
+ battery->available = true;
+ battery->level = response[6];
+ battery->conn = response[7] == 1;
+ battery->voltage = (response[8] << 8) | response[9];
+ battery->last_read = now;
+
+ hid_dbg(drvdata->hdev, "%s: level=%d, conn=%d, voltage=%d\n",
+ __func__, battery->level, battery->conn, battery->voltage);
+
+unlock:
+ up_write(&drvdata->lock_bat);
+ return ret;
+}
+
+static int battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct pulsar_data *drvdata;
+ int ret;
+
+ drvdata = power_supply_get_drvdata(psy);
+
+ ret = read_power(drvdata);
+ if (ret)
+ return ret;
+
+ down_read(&drvdata->lock_bat);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ if (!drvdata->battery.available)
+ val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+ else if (drvdata->battery.conn && drvdata->battery.level < 100)
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else if (drvdata->battery.conn && drvdata->battery.level >= 100)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = drvdata->battery.level;
+ break;
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ val->intval = drvdata->battery.voltage * 1000;
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = drvdata->battery.available;
+ break;
+ case POWER_SUPPLY_PROP_SCOPE:
+ val->intval = POWER_SUPPLY_SCOPE_DEVICE;
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = drvdata->battery.model;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ up_read(&drvdata->lock_bat);
+ return ret;
+}
+
+static void power_uevent_work_handler(struct work_struct *work)
+{
+ struct pulsar_data *drvdata;
+ int ret;
+
+ drvdata = container_of(work, struct pulsar_data, power_uevent_work);
+
+ if (atomic_read(&drvdata->stopping))
+ return;
+
+ down_write(&drvdata->lock_bat);
+ drvdata->battery.last_read = 0;
+ drvdata->battery.last_status = 0;
+ up_write(&drvdata->lock_bat);
+
+ ret = read_power(drvdata);
+ if (ret < 0) {
+ hid_err(drvdata->hdev, "%s: failed to read power: %d\n",
+ __func__, ret);
+ return;
+ }
+
+ power_supply_changed(drvdata->battery.ps);
+}
+
+static int pulsar_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ struct pulsar_data *drvdata;
+
+ drvdata = hid_get_drvdata(hdev);
+ if (!drvdata)
+ return 0;
+
+ hid_dbg(hdev, "received raw event: %*ph\n", size, data);
+
+ if (size != USB_PAYLOAD_LEN || data[0] != CMD_HID_REPORT_ID)
+ return 0;
+
+ if (data[1] != CMD_EVENT) {
+ spin_lock(&drvdata->raw_event_lock);
+ if (drvdata->pending_event != data[1]) {
+ spin_unlock(&drvdata->raw_event_lock);
+ return 0;
+ }
+ memcpy(drvdata->response_buf, data, size);
+ drvdata->pending_event = CMD_NONE;
+ complete(&drvdata->response_ready);
+ spin_unlock(&drvdata->raw_event_lock);
+ return 1;
+ }
+
+ if (!atomic_read(&drvdata->device_verified))
+ return 0;
+
+ if (data[6] == EVENT_PWR && data[USB_PAYLOAD_LEN - 1] == EVENT_PWR_CHK) {
+ schedule_work(&drvdata->power_uevent_work);
+ hid_dbg(hdev, "received power event\n");
+ return 1;
+ }
+
+ return 0;
+}
+
+static const enum power_supply_property pulsar_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS, POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW, POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_MODEL_NAME, POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_PRESENT
+};
+
+static void init_power_supply_desc(struct pulsar_data *drvdata)
+{
+ drvdata->battery.desc.name = drvdata->battery.name;
+ drvdata->battery.desc.type = POWER_SUPPLY_TYPE_BATTERY;
+ drvdata->battery.desc.properties = pulsar_battery_props;
+ drvdata->battery.desc.num_properties = ARRAY_SIZE(pulsar_battery_props);
+ drvdata->battery.desc.get_property = battery_get_property;
+}
+
+static void model_pulsar(u8 *device_id, struct pulsar_data *drvdata)
+{
+ u16 model_id;
+ const char *con_type = "unknown";
+
+ model_id = device_id[0] << 8 | device_id[1];
+
+ switch (device_id[2]) {
+ case CON_1K:
+ con_type = "1kHz";
+ break;
+ case CON_4K:
+ con_type = "4kHz";
+ break;
+ case CON_WIRED:
+ con_type = "wired";
+ break;
+ }
+
+ switch (model_id) {
+ case 0x060a:
+ case 0x060b:
+ case 0x0612:
+ case 0x0613:
+ case 0x0614:
+ case 0x0615:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2 V2 (%s)", con_type);
+ break;
+ case 0x060c:
+ case 0x060d:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2H (%s)", con_type);
+ break;
+ case 0x0607:
+ case 0x060e:
+ case 0x060f:
+ case 0x0610:
+ case 0x0611:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar Xlite V3 (%s)", con_type);
+ break;
+ case 0x0608:
+ case 0x0609:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2A (%s)", con_type);
+ break;
+ default:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar unknown (%s)", con_type);
+ }
+}
+
+static void model_atk(u8 *device_id, struct pulsar_data *drvdata)
+{
+ u16 model_id;
+ const char *con_type = "unknown";
+
+ model_id = device_id[0] << 8 | device_id[1];
+
+ switch (device_id[2]) {
+ case CON_1K:
+ con_type = "1kHz";
+ break;
+ case CON_4K:
+ con_type = "4kHz";
+ break;
+ case CON_WIRED:
+ con_type = "wired";
+ break;
+ }
+
+ switch (model_id) {
+ case 0x0220:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "ATK VXE R1 SE+ (%s)", con_type);
+ break;
+ default:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Unknown ATK (%s)", con_type);
+ }
+}
+
+static void pulsar_init_work(struct work_struct *work)
+{
+ struct pulsar_data *drvdata;
+ struct hid_device *hdev;
+ struct power_supply_config psy_cfg;
+ int ret;
+ u8 data[DEV_INFO_LEN];
+
+ drvdata = container_of(work, struct pulsar_data, init_work.work);
+ hdev = drvdata->hdev;
+
+ ret = read_device_info(drvdata, data);
+ if (ret == -ETIMEDOUT) {
+ if (drvdata->init_retries--) {
+ hid_dbg(hdev,
+ "device info read timed out, retrying (%u left)\n",
+ drvdata->init_retries);
+ schedule_delayed_work(&drvdata->init_work,
+ msecs_to_jiffies
+ (INIT_DELAY_MSEC));
+ return;
+ }
+ hid_err(hdev, "device info read timed out, giving up\n");
+ return;
+ }
+ if (ret < 0) {
+ if (drvdata->type == TYPE_PULSAR) {
+ hid_err(hdev, "failed to read device info: %d\n", ret);
+ return;
+ }
+ hid_dbg(hdev, "failed to read device info: %d\n", ret);
+ snprintf(drvdata->battery.model,
+ sizeof(drvdata->battery.model), "%s", hdev->name);
+ goto register_battery;
+ }
+
+ hid_dbg(hdev, "device info: %*ph (%d)\n", DEV_INFO_LEN, data, ret);
+
+ switch (drvdata->type) {
+ case TYPE_PULSAR:
+ model_pulsar(data, drvdata);
+ break;
+ case TYPE_ATK:
+ model_atk(data, drvdata);
+ break;
+ default:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "%s", hdev->name);
+ }
+
+register_battery:
+ init_power_supply_desc(drvdata);
+
+ psy_cfg = (struct power_supply_config) {.drv_data = drvdata };
+ drvdata->battery.ps =
+ devm_power_supply_register(&hdev->dev, &drvdata->battery.desc,
+ &psy_cfg);
+ if (IS_ERR(drvdata->battery.ps)) {
+ hid_err(hdev, "failed to register battery: %ld\n",
+ PTR_ERR(drvdata->battery.ps));
+ drvdata->battery.ps = NULL;
+ return;
+ }
+
+ atomic_set(&drvdata->device_verified, 1);
+ hid_info(hdev, "device verified, battery registered\n");
+}
+
+static int pulsar_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+ struct usb_interface *intf;
+ struct usb_device *usbdev;
+ struct pulsar_data *drvdata;
+ struct hid_report *report_in;
+ struct hid_report *report_out;
+
+ if (!hid_is_usb(hdev))
+ return -ENODEV;
+
+ ret = hid_parse(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hid_parse failed: %d\n", ret);
+ return ret;
+ }
+
+ intf = to_usb_interface(hdev->dev.parent);
+ report_in =
+ hdev->report_enum[HID_INPUT_REPORT].report_id_hash[CMD_HID_REPORT_ID];
+ report_out =
+ hdev->report_enum[HID_OUTPUT_REPORT].report_id_hash[CMD_HID_REPORT_ID];
+
+ if (!report_in || !report_out ||
+ hid_report_len(report_in) != USB_PAYLOAD_LEN ||
+ hid_report_len(report_out) != USB_PAYLOAD_LEN ||
+ intf->cur_altsetting->desc.bInterfaceNumber != USB_INTERFACE)
+ return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+
+ drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->hdev = hdev;
+ drvdata->type = id->driver_data;
+
+ mutex_init(&drvdata->lock_cmd);
+ init_rwsem(&drvdata->lock_bat);
+
+ usbdev = interface_to_usbdev(intf);
+
+ spin_lock_init(&drvdata->raw_event_lock);
+ hid_set_drvdata(hdev, drvdata);
+ init_completion(&drvdata->response_ready);
+ INIT_WORK(&drvdata->power_uevent_work, power_uevent_work_handler);
+ INIT_DELAYED_WORK(&drvdata->init_work, pulsar_init_work);
+ drvdata->init_retries = INIT_RETRIES;
+
+ snprintf(drvdata->battery.name, sizeof(drvdata->battery.name),
+ "pulsar_%s_battery", usbdev->devpath);
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret < 0) {
+ hid_err(hdev, "hw start failed\n");
+ return ret;
+ }
+
+ ret = hid_hw_open(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hw open failed\n");
+ goto err_open;
+ }
+
+ schedule_delayed_work(&drvdata->init_work, 0);
+
+ return 0;
+
+err_open:
+ cancel_work_sync(&drvdata->power_uevent_work);
+ hid_hw_stop(hdev);
+ return ret;
+}
+
+static void pulsar_remove(struct hid_device *hdev)
+{
+ struct pulsar_data *drvdata;
+
+ drvdata = hid_get_drvdata(hdev);
+ if (!drvdata) {
+ hid_hw_stop(hdev);
+ return;
+ }
+
+ atomic_set(&drvdata->stopping, 1);
+ cancel_delayed_work_sync(&drvdata->init_work);
+ cancel_work_sync(&drvdata->power_uevent_work);
+
+ /* wait for active device i/o (exec_cmd) */
+ mutex_lock(&drvdata->lock_cmd);
+ hid_hw_close(hdev);
+ mutex_unlock(&drvdata->lock_cmd);
+
+ hid_hw_stop(hdev);
+ mutex_destroy(&drvdata->lock_cmd);
+}
+
+static const struct hid_device_id pulsar_table[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_WIRED),
+ .driver_data = TYPE_PULSAR },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_1KHZ),
+ .driver_data = TYPE_PULSAR },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_4KHZ),
+ .driver_data = TYPE_PULSAR },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYSONA, USB_DEVICE_ID_KYSONA_M600_DONGLE),
+ .driver_data = TYPE_KYSONA },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYSONA, USB_DEVICE_ID_KYSONA_M600_WIRED),
+ .driver_data = TYPE_KYSONA },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATK, USB_DEVICE_ID_ATK_VXE_R1_SE_DONGLE),
+ .driver_data = TYPE_ATK },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ATK_ALT, USB_DEVICE_ID_ATK_VXE_R1_SE_WIRED),
+ .driver_data = TYPE_ATK },
+ { HID_USB_DEVICE(USB_VENDOR_ID_VXE, USB_DEVICE_ID_VXE_DRAGONFLY_R1_PRO_DONGLE),
+ .driver_data = TYPE_VXE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_VXE, USB_DEVICE_ID_VXE_DRAGONFLY_R1_PRO_WIRED),
+ .driver_data = TYPE_VXE },
+ { }
+};
+
+static struct hid_driver pulsar_driver = {
+ .name = "pulsar",
+ .id_table = pulsar_table,
+ .probe = pulsar_probe,
+ .remove = pulsar_remove,
+ .raw_event = pulsar_raw_event,
+};
+
+module_hid_driver(pulsar_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("HID driver for pulsar mice");
+MODULE_AUTHOR("Nikolas Koesling");
+MODULE_DEVICE_TABLE(hid, pulsar_table);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] Input: usbtouchscreen - refactor endpoint lookup
From: Dmitry Torokhov @ 2026-04-01 19:29 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <20260401082212.2180434-1-johan@kernel.org>
On Wed, Apr 01, 2026 at 10:22:12AM +0200, Johan Hovold wrote:
> Use the common USB helpers for looking up bulk and interrupt endpoints
> (and determining endpoint numbers) instead of open coding.
>
> Note that the NEXIO data interface has two bulk endpoints (see commit
> 5197424cdccc ("Input: usbtouchscreen - add NEXIO (or iNexio) support")
> for the descriptors).
>
> The lookup in probe handles both bulk-in and interrupt-in endpoints and
> was added to handle NEXIO devices. Replace the open coded lookup with a
> lookup for the common interrupt endpoint and an explicit fallback
> accepting a bulk endpoint.
>
> This iterates over the (two) endpoints twice for NEXIO devices but makes
> it more clear what is going on.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 00/11] Add spi-hid transport driver
From: Jingyuan Liang @ 2026-04-02 1:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, linux-doc, linux-kernel, linux-spi,
linux-trace-kernel, devicetree, hbarnor, tfiga, Jarrett Schultz,
Dmitry Antipov, Angela Czubak
In-Reply-To: <20260325-naughty-hungry-wapiti-658e83@quoll>
On Wed, Mar 25, 2026 at 1:49 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Mar 24, 2026 at 06:39:33AM +0000, Jingyuan Liang wrote:
> > This series picks up the spi-hid driver work originally started by
> > Microsoft. The patch breakdown has been modified and the implementation
> > has been refactored to address upstream feedback and testing issues. We
> > are submitting this as a new series while keeping the original sign-off
> > chain to reflect the history.
> >
> > Same as the original series, there is a change to HID documentation, some
> > HID core changes to support a SPI device, the SPI HID transport driver,
> > and HID over SPI Device Tree binding. We have added the HID over SPI ACPI
> > support, power management, panel follower, and quirks for Ilitek touch
> > controllers.
> >
> > Original authors: Jarrett Schultz <jaschultz@microsoft.com>,
> > Dmitry Antipov <dmanti@microsoft.com>
> > Link: https://lore.kernel.org/r/86b63b7b-afda-d7f4-7bfa-175085d5a8ef@gmail.com
> >
> > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > ---
> > Changes in v2:
> > - Fix style problems and remove unnecessary fields from the DT binding file
>
> Style and removal? So other comments were skipped?
>
> Please write detailed changelogs, otherwise it feels you just ignore
> parts of the feedback.
>
> Best regards,
> Krzysztof
>
Comments are either resolved or awaiting further confirmation. I will
add more details
to v2 changelog in v3.
^ permalink raw reply
* [PATCH v3 00/11] Add spi-hid transport driver
From: Jingyuan Liang @ 2026-04-02 1:59 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, linux-doc, linux-kernel, linux-spi,
linux-trace-kernel, devicetree, hbarnor, tfiga, Jingyuan Liang,
Jarrett Schultz, Dmitry Antipov, Angela Czubak
This series picks up the spi-hid driver work originally started by
Microsoft. The patch breakdown has been modified and the implementation
has been refactored to address upstream feedback and testing issues. We
are submitting this as a new series while keeping the original sign-off
chain to reflect the history.
Same as the original series, there is a change to HID documentation, some
HID core changes to support a SPI device, the SPI HID transport driver,
and HID over SPI Device Tree binding. We have added the HID over SPI ACPI
support, power management, panel follower, and quirks for Ilitek touch
controllers.
Original authors: Jarrett Schultz <jaschultz@microsoft.com>,
Dmitry Antipov <dmanti@microsoft.com>
Link: https://lore.kernel.org/r/86b63b7b-afda-d7f4-7bfa-175085d5a8ef@gmail.com
Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
---
Changes in v3:
- Add io_lock init
- Relocate tracepoints to drivers/hid/spi-hid/ and fix tracepoint macros
- Add tracepoints for sync, error handling, reset, and report processing
- Clean up internal includes and fix Makefile CFLAGS
- Add more details in v2 changelog
- Link to v2: https://lore.kernel.org/r/20260324-send-upstream-v2-0-521ce8afff86@chromium.org
Changes in v2:
- Clean up DT bindings: fix formatting and remove timing and flags properties
- Update DT binding example: use a device-specific compatible and drop
reset_assert
- Simplify ACPI/OF match tables by removing ACPI_PTR/of_match_ptr
- Refactor OF driver to use match data for timing parameters instead
of DT properties
- Switch to fsleep() for delays in ACPI and OF drivers
- Drop patch 12 as it is vendor specific
- Add a lock to fix input/output concurrency race
- Link to v1: https://lore.kernel.org/r/20260303-send-upstream-v1-0-1515ba218f3d@chromium.org
---
Angela Czubak (2):
HID: spi-hid: add transport driver skeleton for HID over SPI bus
HID: spi_hid: add ACPI support for SPI over HID
Jarrett Schultz (3):
Documentation: Correction in HID output_report callback description.
HID: Add BUS_SPI support and define HID_SPI_DEVICE macro
HID: spi_hid: add device tree support for SPI over HID
Jingyuan Liang (6):
HID: spi-hid: add spi-hid driver HID layer
HID: spi-hid: add HID SPI protocol implementation
HID: spi_hid: add spi_hid traces
dt-bindings: input: Document hid-over-spi DT schema
HID: spi-hid: add power management implementation
HID: spi-hid: add panel follower support
.../devicetree/bindings/input/hid-over-spi.yaml | 126 ++
Documentation/hid/hid-transport.rst | 4 +-
drivers/hid/Kconfig | 2 +
drivers/hid/Makefile | 2 +
drivers/hid/hid-core.c | 3 +
drivers/hid/spi-hid/Kconfig | 45 +
drivers/hid/spi-hid/Makefile | 12 +
drivers/hid/spi-hid/spi-hid-acpi.c | 254 ++++
drivers/hid/spi-hid/spi-hid-core.c | 1456 ++++++++++++++++++++
drivers/hid/spi-hid/spi-hid-core.h | 98 ++
drivers/hid/spi-hid/spi-hid-of.c | 244 ++++
drivers/hid/spi-hid/spi-hid-trace.h | 169 +++
drivers/hid/spi-hid/spi-hid.h | 46 +
include/linux/hid.h | 2 +
14 files changed, 2461 insertions(+), 2 deletions(-)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260212-send-upstream-75f6fd9ed92e
Best regards,
--
Jingyuan Liang <jingyliang@chromium.org>
^ permalink raw reply
* [PATCH v3 01/11] Documentation: Correction in HID output_report callback description.
From: Jingyuan Liang @ 2026-04-02 1:59 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, linux-doc, linux-kernel, linux-spi,
linux-trace-kernel, devicetree, hbarnor, tfiga, Jingyuan Liang,
Jarrett Schultz, Dmitry Antipov
In-Reply-To: <20260402-send-upstream-v3-0-6091c458d357@chromium.org>
From: Jarrett Schultz <jaschultz@microsoft.com>
Originally output_report callback was described as must-be asynchronous,
but that is not the case in some implementations, namely i2c-hid.
Correct the documentation to say that it may be asynchronous.
Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
---
Documentation/hid/hid-transport.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/hid/hid-transport.rst b/Documentation/hid/hid-transport.rst
index 6f1692da296c..2008cf432af1 100644
--- a/Documentation/hid/hid-transport.rst
+++ b/Documentation/hid/hid-transport.rst
@@ -327,8 +327,8 @@ The available HID callbacks are:
Send raw output report via intr channel. Used by some HID device drivers
which require high throughput for outgoing requests on the intr channel. This
- must not cause SET_REPORT calls! This must be implemented as asynchronous
- output report on the intr channel!
+ must not cause SET_REPORT calls! This call might be asynchronous, so the
+ caller should not expect an immediate response!
::
--
2.53.0.1185.g05d4b7b318-goog
^ 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