* [regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device
From: Salvatore Bonaccorso @ 2025-09-07 15:10 UTC (permalink / raw)
To: Zhang Heng, Jiri Kosina, Staffan Melin
Cc: Benjamin Tissoires, linux-input, linux-kernel, regressions,
stable, 1114557
Hi Zhang, hi Jiri,
In Debian Staffan Melin reported that after an update containing the
commit 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY"),
the input device with same idVendor and idProduct, the Jieli
Technology USB Composite Device, does not get recognized anymore.
The full Debian report is at: https://bugs.debian.org/1114557
The issue is not specific to the 6.12.y series and confirmed in 6.16.3
as well.
Staffan Melin did bisect the kernels between 6.12.38 (which was still
working) and 6.1.41 (which was not), confirming by bisection that the
offending commit is
1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
#regzbot introduced: 1a8953f4f774
#regzbot monitor: https://bugs.debian.org/1114557
So it looks that the quirk applied is unfortunately affecting
negatively as well Staffan Melin case.
Can you have a look?
Regards,
Salvatore
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS f3ebb77fce24b5573e7accc2ba593ae55bded1d9
From: kernel test robot @ 2025-09-07 16:44 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: f3ebb77fce24b5573e7accc2ba593ae55bded1d9 dt-bindings: input: touchscreen: goodix: Drop 'interrupts' requirement
elapsed time: 1449m
configs tested: 134
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.1.0
alpha allyesconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc nsim_700_defconfig gcc-15.1.0
arc randconfig-001-20250907 gcc-8.5.0
arc randconfig-002-20250907 gcc-8.5.0
arm allmodconfig gcc-15.1.0
arm allnoconfig clang-22
arm allyesconfig gcc-15.1.0
arm gemini_defconfig clang-20
arm hisi_defconfig gcc-15.1.0
arm randconfig-001-20250907 gcc-8.5.0
arm randconfig-002-20250907 clang-22
arm randconfig-003-20250907 clang-22
arm randconfig-004-20250907 gcc-10.5.0
arm sama5_defconfig gcc-15.1.0
arm vt8500_v6_v7_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 randconfig-001-20250907 clang-22
arm64 randconfig-002-20250907 gcc-14.3.0
arm64 randconfig-003-20250907 clang-22
arm64 randconfig-004-20250907 gcc-9.5.0
csky allnoconfig gcc-15.1.0
csky randconfig-001-20250907 gcc-15.1.0
csky randconfig-002-20250907 gcc-9.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon randconfig-001-20250907 clang-17
hexagon randconfig-002-20250907 clang-22
i386 allmodconfig gcc-13
i386 allnoconfig gcc-13
i386 allyesconfig gcc-13
i386 buildonly-randconfig-001-20250907 clang-20
i386 buildonly-randconfig-002-20250907 clang-20
i386 buildonly-randconfig-003-20250907 gcc-13
i386 buildonly-randconfig-004-20250907 clang-20
i386 buildonly-randconfig-005-20250907 clang-20
i386 buildonly-randconfig-006-20250907 clang-20
i386 defconfig clang-20
loongarch alldefconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch randconfig-001-20250907 clang-22
loongarch randconfig-002-20250907 clang-22
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
microblaze allmodconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips ath25_defconfig clang-22
mips omega2p_defconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20250907 gcc-11.5.0
nios2 randconfig-002-20250907 gcc-11.5.0
openrisc alldefconfig gcc-15.1.0
openrisc allnoconfig gcc-15.1.0
openrisc allyesconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250907 gcc-9.5.0
parisc randconfig-002-20250907 gcc-14.3.0
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig gcc-15.1.0
powerpc allyesconfig clang-22
powerpc eiger_defconfig clang-22
powerpc randconfig-001-20250907 gcc-9.5.0
powerpc randconfig-002-20250907 clang-22
powerpc randconfig-003-20250907 gcc-15.1.0
powerpc storcenter_defconfig gcc-15.1.0
powerpc tqm8555_defconfig gcc-15.1.0
powerpc64 randconfig-001-20250907 gcc-13.4.0
powerpc64 randconfig-002-20250907 clang-22
powerpc64 randconfig-003-20250907 clang-22
riscv allnoconfig gcc-15.1.0
riscv defconfig clang-22
riscv randconfig-001-20250907 clang-22
riscv randconfig-002-20250907 clang-22
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 randconfig-001-20250907 gcc-8.5.0
s390 randconfig-002-20250907 gcc-14.3.0
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh defconfig gcc-15.1.0
sh migor_defconfig gcc-15.1.0
sh polaris_defconfig gcc-15.1.0
sh randconfig-001-20250907 gcc-12.5.0
sh randconfig-002-20250907 gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250907 gcc-13.4.0
sparc randconfig-002-20250907 gcc-15.1.0
sparc sparc64_defconfig gcc-15.1.0
sparc64 defconfig clang-20
sparc64 randconfig-001-20250907 gcc-12.5.0
sparc64 randconfig-002-20250907 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-13
um defconfig clang-22
um i386_defconfig gcc-13
um randconfig-001-20250907 gcc-13
um randconfig-002-20250907 gcc-13
um x86_64_defconfig clang-22
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250907 gcc-13
x86_64 buildonly-randconfig-002-20250907 clang-20
x86_64 buildonly-randconfig-003-20250907 gcc-13
x86_64 buildonly-randconfig-004-20250907 gcc-13
x86_64 buildonly-randconfig-005-20250907 gcc-13
x86_64 buildonly-randconfig-006-20250907 gcc-13
x86_64 defconfig gcc-11
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250907 gcc-10.5.0
xtensa randconfig-002-20250907 gcc-9.5.0
xtensa smp_lx200_defconfig gcc-15.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 5f9efb6b7667043527d377421af2070cc0aa2ecd
From: kernel test robot @ 2025-09-07 17:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 5f9efb6b7667043527d377421af2070cc0aa2ecd Input: mtk-pmic-keys - MT6359 has a specific release irq
elapsed time: 1471m
configs tested: 98
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.1.0
alpha allyesconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc randconfig-001-20250907 gcc-8.5.0
arc randconfig-002-20250907 gcc-8.5.0
arm allnoconfig clang-22
arm jornada720_defconfig clang-22
arm randconfig-001-20250907 gcc-8.5.0
arm randconfig-002-20250907 clang-22
arm randconfig-003-20250907 clang-22
arm randconfig-004-20250907 gcc-10.5.0
arm shmobile_defconfig gcc-15.1.0
arm64 allnoconfig gcc-15.1.0
arm64 randconfig-001-20250907 clang-22
arm64 randconfig-002-20250907 gcc-14.3.0
arm64 randconfig-003-20250907 clang-22
arm64 randconfig-004-20250907 gcc-9.5.0
csky allnoconfig gcc-15.1.0
csky randconfig-001-20250907 gcc-15.1.0
csky randconfig-002-20250907 gcc-9.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon randconfig-001-20250907 clang-17
hexagon randconfig-002-20250907 clang-22
i386 buildonly-randconfig-001-20250907 clang-20
i386 buildonly-randconfig-002-20250907 clang-20
i386 buildonly-randconfig-003-20250907 gcc-13
i386 buildonly-randconfig-004-20250907 clang-20
i386 buildonly-randconfig-005-20250907 clang-20
i386 buildonly-randconfig-006-20250907 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch randconfig-001-20250907 clang-22
loongarch randconfig-002-20250907 clang-22
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig gcc-15.1.0
m68k apollo_defconfig gcc-15.1.0
microblaze allnoconfig gcc-15.1.0
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips ip28_defconfig gcc-15.1.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20250907 gcc-11.5.0
nios2 randconfig-002-20250907 gcc-11.5.0
openrisc allnoconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20250907 gcc-9.5.0
parisc randconfig-002-20250907 gcc-14.3.0
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig gcc-15.1.0
powerpc allyesconfig clang-22
powerpc ppc64e_defconfig gcc-15.1.0
powerpc randconfig-001-20250907 gcc-9.5.0
powerpc randconfig-002-20250907 clang-22
powerpc randconfig-003-20250907 gcc-15.1.0
powerpc64 randconfig-001-20250907 gcc-13.4.0
powerpc64 randconfig-002-20250907 clang-22
powerpc64 randconfig-003-20250907 clang-22
riscv allnoconfig gcc-15.1.0
riscv randconfig-001-20250907 clang-22
riscv randconfig-002-20250907 clang-22
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 randconfig-001-20250907 gcc-8.5.0
s390 randconfig-002-20250907 gcc-14.3.0
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh randconfig-001-20250907 gcc-12.5.0
sh randconfig-002-20250907 gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20250907 gcc-13.4.0
sparc randconfig-002-20250907 gcc-15.1.0
sparc64 randconfig-001-20250907 gcc-12.5.0
sparc64 randconfig-002-20250907 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-13
um randconfig-001-20250907 gcc-13
um randconfig-002-20250907 gcc-13
x86_64 buildonly-randconfig-001-20250907 gcc-13
x86_64 buildonly-randconfig-002-20250907 clang-20
x86_64 buildonly-randconfig-003-20250907 gcc-13
x86_64 buildonly-randconfig-004-20250907 gcc-13
x86_64 buildonly-randconfig-005-20250907 gcc-13
x86_64 buildonly-randconfig-006-20250907 gcc-13
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250907 gcc-10.5.0
xtensa randconfig-002-20250907 gcc-9.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 1/2] hid: intel-thc-hid: intel-quicki2c: Add WCL Device IDs
From: Even Xu @ 2025-09-08 3:26 UTC (permalink / raw)
To: xinpeng.sun
Cc: bentiss, jikos, linux-input, linux-kernel, srinivas.pandruvada,
Even Xu
In-Reply-To: <20250828021000.3299377-1-xinpeng.sun@intel.com>
> From: Xinpeng Sun <xinpeng.sun@intel.com>
> To: jikos@kernel.org, bentiss@kernel.org
> Cc: srinivas.pandruvada@linux.intel.com, linux-input@vger.kernel.org,
> linux-kernel@vger.kernel.org, Xinpeng Sun <xinpeng.sun@intel.com>
> Subject: [PATCH v2 1/2] hid: intel-thc-hid: intel-quicki2c: Add WCL Device IDs
> Date: Thu, 28 Aug 2025 10:09:58 +0800 [thread overview]
> Message-ID: <20250828021000.3299377-1-xinpeng.sun@intel.com> (raw)
>
> Add THC I2C WildcatLake device IDs.
>
> Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
Thanks for the patch!
Reviewed-by: Even Xu <even.xu@intel.com>
> ---
> drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 2 ++
> drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index f122fde879b9..17b1f2df8f8a 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -1019,6 +1019,8 @@ static const struct pci_device_id quicki2c_pci_tbl[] = {
> { PCI_DEVICE_DATA(INTEL, THC_PTL_H_DEVICE_ID_I2C_PORT2, &ptl_ddata) },
> { PCI_DEVICE_DATA(INTEL, THC_PTL_U_DEVICE_ID_I2C_PORT1, &ptl_ddata) },
> { PCI_DEVICE_DATA(INTEL, THC_PTL_U_DEVICE_ID_I2C_PORT2, &ptl_ddata) },
> + { PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_I2C_PORT1, &ptl_ddata) },
> + { PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_I2C_PORT2, &ptl_ddata) },
> { }
> };
> MODULE_DEVICE_TABLE(pci, quicki2c_pci_tbl);
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> index b78c8864d39e..240492a38c24 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> @@ -13,6 +13,8 @@
> #define PCI_DEVICE_ID_INTEL_THC_PTL_H_DEVICE_ID_I2C_PORT2 0xE34A
> #define PCI_DEVICE_ID_INTEL_THC_PTL_U_DEVICE_ID_I2C_PORT1 0xE448
> #define PCI_DEVICE_ID_INTEL_THC_PTL_U_DEVICE_ID_I2C_PORT2 0xE44A
> +#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_I2C_PORT1 0x4D48
> +#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_I2C_PORT2 0x4D4A
>
> /* Packet size value, the unit is 16 bytes */
> #define MAX_PACKET_SIZE_VALUE_LNL 256
> --
> 2.40.1
^ permalink raw reply
* Re: [PATCH v2 2/2] hid: intel-thc-hid: intel-quickspi: Add WCL Device IDs
From: Even Xu @ 2025-09-08 3:42 UTC (permalink / raw)
To: xinpeng.sun
Cc: bentiss, jikos, linux-input, linux-kernel, srinivas.pandruvada,
Even Xu
In-Reply-To: <20250828021000.3299377-2-xinpeng.sun@intel.com>
> From: Xinpeng Sun <xinpeng.sun@intel.com>
> To: jikos@kernel.org, bentiss@kernel.org
> Cc: srinivas.pandruvada@linux.intel.com, linux-input@vger.kernel.org,
> linux-kernel@vger.kernel.org, Xinpeng Sun <xinpeng.sun@intel.com>
> Subject: [PATCH v2 2/2] hid: intel-thc-hid: intel-quickspi: Add WCL Device IDs
> Date: Thu, 28 Aug 2025 10:09:59 +0800 [thread overview]
> Message-ID: <20250828021000.3299377-2-xinpeng.sun@intel.com> (raw)
> In-Reply-To: <20250828021000.3299377-1-xinpeng.sun@intel.com>
>
> Add THC SPI WildcatLake device IDs.
>
> Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
LGTM, thanks for the patch!
Reviewed-by: Even Xu <even.xu@intel.com>
> ---
> drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 2 ++
> drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> index 5e5f179dd113..84314989dc53 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> @@ -976,6 +976,8 @@ static const struct pci_device_id quickspi_pci_tbl[] = {
> {PCI_DEVICE_DATA(INTEL, THC_PTL_H_DEVICE_ID_SPI_PORT2, &ptl), },
> {PCI_DEVICE_DATA(INTEL, THC_PTL_U_DEVICE_ID_SPI_PORT1, &ptl), },
> {PCI_DEVICE_DATA(INTEL, THC_PTL_U_DEVICE_ID_SPI_PORT2, &ptl), },
> + {PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_SPI_PORT1, &ptl), },
> + {PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_SPI_PORT2, &ptl), },
> {}
> };
> MODULE_DEVICE_TABLE(pci, quickspi_pci_tbl);
> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
> index 6fdf674b21c5..f3532d866749 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
> @@ -19,6 +19,8 @@
> #define PCI_DEVICE_ID_INTEL_THC_PTL_H_DEVICE_ID_SPI_PORT2 0xE34B
> #define PCI_DEVICE_ID_INTEL_THC_PTL_U_DEVICE_ID_SPI_PORT1 0xE449
> #define PCI_DEVICE_ID_INTEL_THC_PTL_U_DEVICE_ID_SPI_PORT2 0xE44B
> +#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_SPI_PORT1 0x4D49
> +#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_SPI_PORT2 0x4D4B
>
> /* HIDSPI special ACPI parameters DSM methods */
> #define ACPI_QUICKSPI_REVISION_NUM 2
> --
> 2.40.1
^ permalink raw reply
* Re: [regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device
From: Terry Junge @ 2025-09-08 4:10 UTC (permalink / raw)
To: Salvatore Bonaccorso, Zhang Heng, Jiri Kosina, Staffan Melin
Cc: Benjamin Tissoires, linux-input, linux-kernel, regressions,
stable, 1114557
In-Reply-To: <aL2gYJaXoB6p_oyM@eldamar.lan>
On 9/7/25 8:10 AM, Salvatore Bonaccorso wrote:
> Hi Zhang, hi Jiri,
>
> In Debian Staffan Melin reported that after an update containing the
> commit 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY"),
> the input device with same idVendor and idProduct, the Jieli
> Technology USB Composite Device, does not get recognized anymore.
>
> The full Debian report is at: https://bugs.debian.org/1114557
>
The root of the issue here is that two devices have bootlegged the same VID:PID.
0x4c4a is not a valid VID that has been assigned according to the latest list from USBIF (vendor_ids072325_1.pdf) so conflicts like this could surface at any time.
[ 10.188336] usb 3-3: device descriptor read/64, error -71
[ 10.439533] usb 3-3: config 1 interface 0 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 10.451534] usb 3-3: New USB device found, idVendor=4c4a, idProduct=4155, bcdDevice= 1.00
[ 10.451540] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 10.451543] usb 3-3: Product: USB Composite Device
[ 10.451545] usb 3-3: Manufacturer: Jieli Technology
[ 10.451546] usb 3-3: SerialNumber: FFFFFFFFFFFFFFFF
Can anyone supply the Jieli descriptors, including the Report Descriptor? It clearly has problems but not bad enough to fail enumeration.
The commit 1a8953f4f774 should be reverted and SMARTLINKTECHNOLOGY should either bootleg a different PID, get a valid VID, or fix their device so a quirk is never required.
Thanks,
Terry
> The issue is not specific to the 6.12.y series and confirmed in 6.16.3
> as well.
>
> Staffan Melin did bisect the kernels between 6.12.38 (which was still
> working) and 6.1.41 (which was not), confirming by bisection that the
> offending commit is
>
> 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
>
> #regzbot introduced: 1a8953f4f774
> #regzbot monitor: https://bugs.debian.org/1114557
>
> So it looks that the quirk applied is unfortunately affecting
> negatively as well Staffan Melin case.
>
> Can you have a look?
>
> Regards,
> Salvatore
>
^ permalink raw reply
* Re: [regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device
From: Staffan Melin @ 2025-09-08 9:00 UTC (permalink / raw)
To: Terry Junge
Cc: Salvatore Bonaccorso, Zhang Heng, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel, regressions, stable, 1114557
In-Reply-To: <36f58d1b-8afe-4895-bef6-59edc791ef0d@cosmicgizmosystems.com>
Hi Terry,
I am the one with the Jieli touchscreen.
On 2025-09-08 06:10, Terry Junge wrote:
>
> The root of the issue here is that two devices have bootlegged the same
> VID:PID.
>
> 0x4c4a is not a valid VID that has been assigned according to the
> latest list from USBIF (vendor_ids072325_1.pdf) so conflicts like this
> could surface at any time.
>
> [ 10.188336] usb 3-3: device descriptor read/64, error -71
> [ 10.439533] usb 3-3: config 1 interface 0 altsetting 0 has 2
> endpoint descriptors, different from the interface descriptor's value:
> 1
> [ 10.451534] usb 3-3: New USB device found, idVendor=4c4a,
> idProduct=4155, bcdDevice= 1.00
> [ 10.451540] usb 3-3: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 10.451543] usb 3-3: Product: USB Composite Device
> [ 10.451545] usb 3-3: Manufacturer: Jieli Technology
> [ 10.451546] usb 3-3: SerialNumber: FFFFFFFFFFFFFFFF
>
> Can anyone supply the Jieli descriptors, including the Report
> Descriptor? It clearly has problems but not bad enough to fail
> enumeration.
>
> The commit 1a8953f4f774 should be reverted and SMARTLINKTECHNOLOGY
> should either bootleg a different PID, get a valid VID, or fix their
> device so a quirk is never required.
>
> Thanks,
> Terry
In /sys/bus/hid/devices/0003:4C4A:4155.0003 i have the report_descriptor
file:
00000000 05 0d 09 04 a1 01 85 aa 09 22 a1 00 09 42 15 00
|........."...B..|
00000010 25 01 75 01 95 01 81 02 75 03 81 03 09 51 75 04
|%.u.....u....Qu.|
00000020 25 0a 81 02 75 08 95 01 81 03 05 01 75 10 55 00
|%...u.......u.U.|
00000030 65 00 09 30 35 00 26 00 10 46 00 10 81 02 09 31
|e..05.&..F.....1|
00000040 26 00 10 46 00 10 81 02 c0 a1 00 05 0d 09 42 15
|&..F..........B.|
00000050 00 25 01 75 01 95 01 81 02 75 03 81 03 09 51 75
|.%.u.....u....Qu|
00000060 04 25 0a 81 02 75 08 95 01 81 03 05 01 75 10 55
|.%...u.......u.U|
00000070 00 65 00 09 30 35 00 26 00 10 46 00 10 81 02 09
|.e..05.&..F.....|
00000080 31 26 00 10 46 00 10 81 02 c0 a1 00 05 0d 09 42
|1&..F..........B|
00000090 15 00 25 01 75 01 95 01 81 02 75 03 81 03 09 51
|..%.u.....u....Q|
000000a0 75 04 25 0a 81 02 75 08 95 01 81 03 05 01 75 10
|u.%...u.......u.|
000000b0 55 00 65 00 09 30 35 00 26 00 10 46 00 10 81 02
|U.e..05.&..F....|
000000c0 09 31 26 00 10 46 00 10 81 02 c0 a1 00 05 0d 09
|.1&..F..........|
000000d0 42 15 00 25 01 75 01 95 01 81 02 75 03 81 03 09
|B..%.u.....u....|
000000e0 51 75 04 25 0a 81 02 75 08 95 01 81 03 05 01 75
|Qu.%...u.......u|
000000f0 10 55 00 65 00 09 30 35 00 26 00 10 46 00 10 81
|.U.e..05.&..F...|
00000100 02 09 31 26 00 10 46 00 10 81 02 c0 a1 00 05 0d
|..1&..F.........|
00000110 09 42 15 00 25 01 75 01 95 01 81 02 75 03 81 03
|.B..%.u.....u...|
00000120 09 51 75 04 25 0a 81 02 75 08 95 01 81 03 05 01
|.Qu.%...u.......|
00000130 75 10 55 00 65 00 09 30 35 00 26 00 10 46 00 10
|u.U.e..05.&..F..|
00000140 81 02 09 31 26 00 10 46 00 10 81 02 c0 05 0d 09
|...1&..F........|
00000150 54 95 01 75 08 15 00 25 0a 81 02 09 55 b1 02 95
|T..u...%....U...|
00000160 3e b1 03 c0 05 0d 09 02 a1 01 85 cc 09 20 a1 00
|>............ ..|
00000170 09 42 09 44 09 3c 09 45 15 00 25 01 75 01 95 04
|.B.D.<.E..%.u...|
00000180 81 02 95 01 09 32 81 02 95 03 81 03 05 01 09 30
|.....2.........0|
00000190 75 10 95 01 a4 55 0d 65 13 35 00 26 00 10 46 00
|u....U.e.5.&..F.|
000001a0 10 81 02 09 31 26 00 10 46 00 10 81 02 b4 05 0d
|....1&..F.......|
000001b0 09 30 26 ff 00 81 02 75 08 09 3d 15 81 25 7f 81
|.0&....u..=..%..|
000001c0 02 09 3e 15 81 25 7f 81 02 c0 c0 05 01 09 02 a1
|..>..%..........|
000001d0 01 85 58 09 01 a1 00 05 09 19 01 29 02 15 00 25
|..X........)...%|
000001e0 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 15
|.u............0.|
000001f0 00 26 00 10 09 31 26 00 10 75 10 95 02 55 0e 65
|.&...1&..u...U.e|
00000200 11 35 00 46 00 10 81 02 09 38 15 81 25 7f 75 08
|.5.F.....8..%.u.|
00000210 95 01 81 06 c0 c0 |......|
And here is the output from lsusb -c:
Bus 003 Device 003: ID 4c4a:4155 Jieli Technology USB Composite Device
Couldn't open device, some information will be missing
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x4c4a Jieli Technology
idProduct 0x4155 USB Composite Device
bcdDevice 1.00
iManufacturer 1 Jieli Technology
iProduct 2 USB Composite Device
iSerial 3 FFFFFFFFFFFFFFFF
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 33 Unknown
bNumDescriptors 1
bDescriptorType 34 (null)
wDescriptorLength 534
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Best regards,
Staffan
>
>> The issue is not specific to the 6.12.y series and confirmed in 6.16.3
>> as well.
>>
>> Staffan Melin did bisect the kernels between 6.12.38 (which was still
>> working) and 6.1.41 (which was not), confirming by bisection that the
>> offending commit is
>>
>> 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
>>
>> #regzbot introduced: 1a8953f4f774
>> #regzbot monitor: https://bugs.debian.org/1114557
>>
>> So it looks that the quirk applied is unfortunately affecting
>> negatively as well Staffan Melin case.
>>
>> Can you have a look?
>>
>> Regards,
>> Salvatore
>>
^ permalink raw reply
* Re: [PATCH v3 1/3] Input: mtk-pmic-keys - MT6359 has a specific release irq
From: AngeloGioacchino Del Regno @ 2025-09-08 11:36 UTC (permalink / raw)
To: Julien Massot, kernel, Dmitry Torokhov, Matthias Brugger,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Louis-Alexis Eyraud
Cc: linux-input, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-1-40f11377fb55@collabora.com>
Il 05/09/25 13:51, Julien Massot ha scritto:
> Support for MT6359 PMIC keys has been added recently.
> However, the key release event is not properly handled:
> only key press events are generated, leaving key states
> stuck in "pressed".
>
> This patch ensures that both key press and key release events
> are properly emitted by handling the release logic correctly.
>
> Introduce a 'key_release_irq' member to the 'mtk_pmic_regs',
> to identify the devices that have a separate irq for the
> release event.
>
> Fixes: bc25e6bf032e ("Input: mtk-pmic-keys - add support for MT6359 PMIC keys")
> Signed-off-by: Julien Massot <julien.massot@collabora.com>
Please clarify the commit title.
Input: mtk-pmic-keys - Use platform data for release irq support
...or something like that.
After which:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v1 01/14] media: dt-bindings: Convert MediaTek mt8173-mdp bindings to YAML
From: Ariel D'Alessandro @ 2025-09-08 17:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250821-silky-slug-of-novelty-e4bb64@kuoka>
Krzysztof,
On 8/21/25 3:46 AM, Krzysztof Kozlowski wrote:
> On Wed, Aug 20, 2025 at 02:12:49PM -0300, Ariel D'Alessandro wrote:
>> Convert the existing text-based DT bindings for MediaTek MT8173 Media Data Path
>> to a YAML schema.
>
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
Thanks. Looks like my editor was misconfigured, sorry. Will fix in v2.
>
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../bindings/media/mediatek,mt8173-mdp.yaml | 174 ++++++++++++++++++
>> .../bindings/media/mediatek-mdp.txt | 95 ----------
>> 2 files changed, 174 insertions(+), 95 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>> delete mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>> new file mode 100644
>> index 0000000000000..f3a08afc305b1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>> @@ -0,0 +1,174 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/mediatek,mt8173-mdp.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: MediaTek MT8173 Media Data Path
>> +
>> +maintainers:
>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> +
>> +description:
>> + Media Data Path is used for scaling and color space conversion.
>> +
>> +properties:
>> + compatible:
>> + oneOf:
>> + - items:
>
> Just enum, no items here
See below.
>
>
>> + - enum:
>> + - mediatek,mt8173-mdp-rdma
>> + - mediatek,mt8173-mdp-rsz
>> + - mediatek,mt8173-mdp-wdma
>> + - mediatek,mt8173-mdp-wrot
>> + - items:
>> + - enum:
>> + - mediatek,mt8173-mdp-rdma
>> + - mediatek,mt8173-mdp-rsz
>> + - mediatek,mt8173-mdp-wdma
>> + - mediatek,mt8173-mdp-wrot
>> + - const: mediatek,mt8173-mdp
>
> This makes no sense. How devices can be compatible and can not be
> compatible.
According to the driver source code (and the previous txt mt8173-mdp
bindings), there must be a "controller node" with compatible
`mediatek,mt8173-mdp`. Then its sibling nodes (including itself) should
be one of the component node ids, listed in `struct of_device_id
mtk_mdp_comp_dt_ids[]`.
Is there a proper/different way to describe this compatible binding in
the yaml? Or you're saying the driver doesn't make sense here?
[0] drivers/media/platform/mediatek/mdp/mtk_mdp_core.c
>
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks: true
>
> No, there's no such syntax. Look at other bindings.
Ack.
>
>
>> +
>> + power-domains:
>> + maxItems: 1
>> +
>> + iommus:
>> + description: |
>
> Drop |
Ack.
>
>> + This property should point to the respective IOMMU block with master port as argument,
>> + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
>
> Drop entire description, completely redundant. I don't know why my patch
> fixing this was not applied, so you keep repeating same mistakes...
Ack.
>
>> + maxItems: 1
>> +
>> + mediatek,vpu:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Describes point to vpu.
>
> Useless description. We see that from the property name. Explain the
> purpose in the hardware.
Ack.
>
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - power-domains
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: mediatek,mt8173-mdp-rdma
>> + then:
>> + properties:
>> + clocks:
>> + items:
>> + - description: Main clock
>> + - description: Mutex clock
>> + else:
>> + properties:
>> + clocks:
>> + items:
>> + - description: Main clock
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - mediatek,mt8173-mdp-rdma
>> + - mediatek,mt8173-mdp-wdma
>> + - mediatek,mt8173-mdp-wrot
>> + then:
>> + required:
>> + - iommus
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: mediatek,mt8173-mdp
>
> This makes no sense either.
Same question above about compatibles.
>
>> + then:
>> + required:
>> + - mediatek,vpu
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/mt8173-clk.h>
>> + #include <dt-bindings/memory/mt8173-larb-port.h>
>> + #include <dt-bindings/power/mt8173-power.h>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + mdp_rdma0: rdma@14001000 {
>
> One example is enough. Two could be fine if they differ significantly.
Sounds good. Will keep just a single example, including a node for the
controller node and one for each of the components.
Thanks a lot for the feedback!
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 02/14] media: dt-bindings: Convert MediaTek mt8173-vpu bindings to YAML
From: Ariel D'Alessandro @ 2025-09-08 18:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250821-piquant-rapid-bear-8cedc0@kuoka>
Krzysztof,
On 8/21/25 3:47 AM, Krzysztof Kozlowski wrote:
> On Wed, Aug 20, 2025 at 02:12:50PM -0300, Ariel D'Alessandro wrote:
>> Convert the existing text-based DT bindings for Mediatek MT8173 Video Processor
>> Unit to a YAML schema.
>
> DT schema, not YAML. Don't say YAML at all, neither here nor in subject.
Ack.
>
> Also looks not wrapped...
Ack.
>
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../bindings/media/mediatek,mt8173-vpu.yaml | 76 +++++++++++++++++++
>> .../bindings/media/mediatek-vpu.txt | 31 --------
>> 2 files changed, 76 insertions(+), 31 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
>> delete mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
>> new file mode 100644
>> index 0000000000000..44f5d7cc44042
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
>> @@ -0,0 +1,76 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/mediatek,mt8173-vpu.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Mediatek MT8173 Video Processor Unit
>> +
>> +maintainers:
>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> +
>> +description:
>> + Video Processor Unit is a HW video controller. It controls HW Codec including
>> + H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color convert).
>
> Please wrap code according to the preferred limit expressed in Kernel
> coding style (checkpatch is not a coding style description, but only a
> tool). However don't wrap blindly (see Kernel coding style).
Thanks for the comment. Wrapped to 80 column width.
>
>> +
>> +properties:
>> + compatible:
>> + const: mediatek,mt8173-vpu
>> +
>> + reg:
>> + minItems: 2
>
> No, from where do you get such syntax?
IIUC, what you mean is s/minItems/maxItems.
>
>> +
>> + reg-names:
>> + items:
>> + - const: tcm
>> + - const: cfg_reg
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + clock-names:
>> + items:
>> + - const: main
>> +
>> + memory-region:
>> + description:
>> + phandle to a node describing reserved memory used by VPU
>> + (see bindings/reserved-memory/reserved-memory.txt)
>
> Drop, redundant description.
Ack.
Thanks a lot!
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 03/14] dt-bindings: arm: mediatek: mmsys: Add assigned-clocks/rates properties
From: Ariel D'Alessandro @ 2025-09-08 19:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250821-electric-kestrel-of-awe-cb89dc@kuoka>
Krzysztof,
On 8/21/25 3:43 AM, Krzysztof Kozlowski wrote:
> On Wed, Aug 20, 2025 at 02:12:51PM -0300, Ariel D'Alessandro wrote:
>> Current, the DT bindings for MediaTek mmsys controller is missing the
>> assigned-clocks and assigned-clocks-rates properties. Add these and
>
> No, they do not miss them. I don't understand why you are adding these.
The reason I added these is due to the following check error:
$ make -j$(nproc) CHECK_DTBS=y mediatek/mt8173-elm.dtb
DTC [C] arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
[...]
arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: syscon@14000000
(mediatek,mt8173-mmsys): 'assigned-clock-rates', 'assigned-clocks' do
not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id:
http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
>
>> update the example as well.
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> index 3f4262e93c789..d045d366eb8e2 100644
>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> @@ -68,6 +68,12 @@ properties:
>> of the power controller specified by phandle. See
>> Documentation/devicetree/bindings/power/power-domain.yaml for details.
>>
>> + assigned-clocks:
>> + maxItems: 1
>> +
>> + assigned-clock-rates:
>> + maxItems: 1
>> +
>
> Drop both, completely redundant and not actually in the scope of the binding.
Ack. Will fix accordingly in v2 based on the discussion above.
Thanks!
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 04/14] net: dt-bindings: Convert Marvell 8897/8997 bindings to YAML
From: Ariel D'Alessandro @ 2025-09-08 19:54 UTC (permalink / raw)
To: Rob Herring
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
sean.wang, simona, support.opensource, tiffany.lin, tzimmermann,
yunfei.dong, devicetree, dri-devel, linux-arm-kernel, linux-clk,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <CAL_Jsq+K72Kof-Z3q2DSh3FKO64npLF6hDJnqnTzNBUoOoVQFA@mail.gmail.com>
Hi Rob,
On 8/21/25 11:28 AM, Rob Herring wrote:
> On Wed, Aug 20, 2025 at 12:15 PM Ariel D'Alessandro
> <ariel.dalessandro@collabora.com> wrote:
>>
>> Convert the existing text-based DT bindings for Marvell 8897/8997
>> (sd8897/sd8997) bluetooth devices controller to a YAML schema.
>>
>> While here, bindings for "usb1286,204e" (USB interface) are dropped from
>> the YAML definition as these are currently documented in file:
>>
>> - Documentation/devicetree/bindings/net/btusb.txt
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../bindings/net/marvell,sd8897-bt.yaml | 91 +++++++++++++++++++
>
> This needs to move to net/bluetooth/
Ack.
>
>> .../bindings/net/marvell-bt-8xxx.txt | 83 -----------------
>> 2 files changed, 91 insertions(+), 83 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/net/marvell,sd8897-bt.yaml
>> delete mode 100644 Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/marvell,sd8897-bt.yaml b/Documentation/devicetree/bindings/net/marvell,sd8897-bt.yaml
>> new file mode 100644
>> index 0000000000000..6539868c08b8a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/marvell,sd8897-bt.yaml
>> @@ -0,0 +1,91 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/marvell,sd8897-bt.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO)
>> +
>> +maintainers:
>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> +
>
> Needs a $ref to bluetooth-controller.yaml
Ack.
>
>> +properties:
>> + compatible:
>> + enum:
>> + - marvell,sd8897-bt
>> + - marvell,sd8997-bt
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + marvell,cal-data:
>> + $ref: /schemas/types.yaml#/definitions/uint8-array
>> + description:
>> + Calibration data downloaded to the device during initialization.
>> + minItems: 28
>
> Just: maxItems: 28
Ack.
>
>> +
>> + marvell,wakeup-pin:
>> + $ref: /schemas/types.yaml#/definitions/uint16
>> + description:
>> + Wakeup pin number of the bluetooth chip. Used by firmware to wakeup host
>> + system.
>> +
>> + marvell,wakeup-gap-ms:
>
> This unfortunately needs a uint16 type. That will cause a warning
> which has to be fixed on the dtschema side.
Yeah, that's what I thought but wasn't sure on the proper solution. Will
fix in v2.
>
>> + description:
>> + Wakeup latency of the host platform. Required by the chip sleep feature.
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/irq.h>
>> + #include <dt-bindings/pinctrl/rockchip.h>
>
> Please drop this and just use a number below.
Ack.
>
>> +
>> + sdio0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + btmrvl: btmrvl@2 {
>> + compatible = "marvell,sd8897-bt";
>> + reg = <2>;
>> + interrupt-parent = <&gpio4>;
>> + interrupts = <RK_PD7 IRQ_TYPE_LEVEL_LOW>;
>> + marvell,wakeup-pin = /bits/ 16 <13>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&bt_host_wake_l>;
>> + };
>> + };
>
> I would drop this example.
Agreed.
>
>> +
>> + mmc3 {
>
> mmc {
Ack.
>
>> + vmmc-supply = <&wlan_en_reg>;
>> + bus-width = <4>;
>> + cap-power-off-card;
>> + keep-power-in-suspend;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + bluetooth: bluetooth@2 {
>
> Drop the label.
Ack.
Thanks a lot for your feedback and help!
Regards,
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 05/14] sound: dt-bindings: Convert MediaTek RT5650 codecs bindings to YAML
From: Ariel D'Alessandro @ 2025-09-08 20:04 UTC (permalink / raw)
To: Rob Herring
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
sean.wang, simona, support.opensource, tiffany.lin, tzimmermann,
yunfei.dong, devicetree, dri-devel, linux-arm-kernel, linux-clk,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <20250822151415.GA3819434-robh@kernel.org>
Rob,
On 8/22/25 12:14 PM, Rob Herring wrote:
> On Wed, Aug 20, 2025 at 02:12:53PM -0300, Ariel D'Alessandro wrote:
>> Convert the existing text-based DT bindings for Mediatek MT8173 RT5650
>> codecs to a YAML schema.
>>
>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> ---
>> .../sound/mediatek,mt8173-rt5650.yaml | 73 +++++++++++++++++++
>> .../bindings/sound/mt8173-rt5650.txt | 31 --------
>> 2 files changed, 73 insertions(+), 31 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650.yaml
>> delete mode 100644 Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
>>
>> diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650.yaml
>> new file mode 100644
>> index 0000000000000..36e4f9c4c3d62
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650.yaml
>> @@ -0,0 +1,73 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/sound/mediatek,mt8173-rt5650.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Mediatek MT8173 with RT5650 codecs and HDMI via I2S
>> +
>> +maintainers:
>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>> +
>> +properties:
>> + compatible:
>> + const: "mediatek,mt8173-rt5650"
>
> Drop quotes.
Ack.
>
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + mediatek,audio-codec:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + description:
>> + The phandles of rt5650 codecs and of the HDMI encoder node.
>> + minItems: 2
>> +
>> + mediatek,platform:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + The phandle of MT8173 ASoC platform.
>> +
>> + mediatek,mclk:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + The MCLK source.
>> + 0: external oscillator, MCLK = 12.288M
>> + 1: internal source from mt8173, MCLK = sampling rate * 256
>> +
>> + codec-capture:
>> + description: Subnode of rt5650 codec capture.
>> + type: object
>> +
>> + properties:
>> + sound-dai:
>> + maxItems: 1
>> + description: phandle of the CPU DAI
>> +
>> + additionalProperties: false
>> +
>> +required:
>> + - compatible
>> + - mediatek,audio-codec
>> + - mediatek,platform
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + sound: sound {
>
> Drop unused label.
Ack.
Thanks!
--
Ariel D'Alessandro
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh R @ 2025-09-08 21:01 UTC (permalink / raw)
To: Greg KH
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <2025090621-rumble-cost-2c0d@gregkh>
On 9/6/25 04:36, Greg KH wrote:
> On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
>> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
>> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
>> hypervisor support, such as hypercalls, clocks/timers, Confidential
>> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
>> devices.
>
> But why are you making it so that this can not be a module anymore? You
> are now forcing ALL Linux distro users to always have this code in their
> system, despite not ever using the feature. That feels like a waste to
> me.
>
> What is preventing this from staying as a module? Why must you always
> have this code loaded at all times for everyone?
This is currently not a module. I assume it was at the beginning. In
drivers/Makefile today:
obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
More context: CONFIG_HYPERV doesn't really reflect one module. It is
both for kernel built in code and building of stuff in drivers/hv.
drivers/hv then builds 4 modules:
obj-$(CONFIG_HYPERV) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
Notice vmbus is using CONFIG_HYPERV because there is no
CONFIG_HYPERV_VMBUS. We are trying to fix that here.
Thanks,
-Mukesh
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v3] HID: lg-g15 - Add support for Logitech G13.
From: Hans de Goede @ 2025-09-08 21:08 UTC (permalink / raw)
To: Leo L. Schwab
Cc: Kate Hsuan, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <aLiZbkKgIC8jIqE9@ewhac.org>
[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]
Hi Leo,
On 3-Sep-25 9:39 PM, Leo L. Schwab wrote:
> For some reason, your replies aren't making it to me directly -- I
> had to find and scrape your reply off the LKML web site:
>
> On Tue, 2 Sep 2025 23:05:06 +0200, Hans de Goede wrote:
>> On 2-Sep-25 22:41, Leo L. Schwab wrote:
>>> This does not happen. The G13 accepts and remembers backlight color
>>> settings even when the LEDs have been toggled off locally.
>>> [ ... ]
>>
>> I see, interesting.
>>
>> So what happens if you turn off the backlight with the toggle button on the G13
>> and then write 0 to brightness in sysfs and then press the toggle button again?
>>
> It's a little difficult to see, but the backlight turns back on with
> minimal brightness. To my eye, it looks like it's displaying #000001.
Ok.
>> Right it does seem that using cdev.brightness_hw_changed is valid in
>> this case.
>>
>> But the LED API is supposed to have the brightness attribute present
>> the actual current brightness of the device.
>>
>> I'm not sure how upower will react if the poll() on brightness_hw_changed
>> wakes upower up and then the reported brightness is unchanged...
>>
>> I need to think about this a bit and check the upower code, let me
>> get back to you on this in a day or 2 ...
>>
> Certainly.
Thank you for waiting. After looking at the upower code + running some
tests with a G510 I think that your hw_brightness_changed support
is pretty good as is.
There are 2 improvements which I would like to see:
1. When the backlight is turned on through the button, you
should pass g15_led->brightness to the notify() call rather
then LED_FULL. GNOME will show an OSD with the new brightness
value shown as a mini progress bar similar to how it shows
speaker volume when doing mute/unmute. This mini progress
bar should show the actual brightness being restored, not
always full brightness.
2. ATM if the backlight is turned off on the G13 when
the driver loads and then one of the buttons gets pressed
then a notify() will happen because the led_cdev.hw_brightness_changed
value of -1 will be different from the value of 0 in the
input-report. This notify will lead to an unwanted OSD
notification in GNOME, so this needs to be fixed.
IMHO the best fix would be to use:
hid_hw_raw_request(..., HID_INPUT_REPORT, HID_REQ_GET_REPORT);
at probe to get the input-report so that the driver will
actually now the backlight state at probe() time without
needing to wait for the first time the input-report is send.
You have inspired me to add hw_brightness_changed support
to the G510 code, see the attached patch. This patch can
also be used as an example how to get the input report
on the G13 during probe().
Note this also adds a variable at the driver level to
track the backlight state also fixing the compile issue
you hit without needing to use #ifdef-ery.
I'll wait for your G13 support to land first and then
rebase the G510 patch on top.
Regards,
Hans
[-- Attachment #2: 0001-HID-hid-lg-g15-Add-hw_brightness_changed-support-for.patch --]
[-- Type: text/x-patch, Size: 3783 bytes --]
From 1c735e5ddba814acc57a9d268ed7852bd4aa5887 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hansg@kernel.org>
Date: Mon, 8 Sep 2025 22:55:12 +0200
Subject: [PATCH] HID: hid-lg-g15: Add hw_brightness_changed support for the
G510 keyboard
Add hw_brightness_changed support for the G510 keyboard, so that e.g.
GNOME will show an OSD notification when toggling the backlight on/off
with the button the keyboard.
Note that it is not possible to turn the backlight back on by writing
/sys/class/leds/.../brightness it can only be turned on by pressing
the button on the keyboard. To reflect this /sys/class/leds/.../brightness
will always report the last brightness value independent of the on/off
toggle built into the keyboard.
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
drivers/hid/hid-lg-g15.c | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-lg-g15.c b/drivers/hid/hid-lg-g15.c
index f8605656257b..e5be2a5dfa67 100644
--- a/drivers/hid/hid-lg-g15.c
+++ b/drivers/hid/hid-lg-g15.c
@@ -26,6 +26,9 @@
#define LG_G510_FEATURE_BACKLIGHT_RGB 0x05
#define LG_G510_FEATURE_POWER_ON_RGB 0x06
+#define LG_G510_INPUT_MACRO_KEYS 0x03
+#define LG_G510_INPUT_KBD_BACKLIGHT 0x04
+
enum lg_g15_model {
LG_G15,
LG_G15_V2,
@@ -67,6 +70,7 @@ struct lg_g15_data {
enum lg_g15_model model;
struct lg_g15_led leds[LG_G15_LED_MAX];
bool game_mode_enabled;
+ bool backlight_disabled;
};
/******** G15 and G15 v2 LED functions ********/
@@ -227,6 +231,20 @@ static int lg_g510_get_initial_led_brightness(struct lg_g15_data *g15, int i)
g15->leds[i].brightness = 0;
}
+ if (i)
+ return 0;
+
+ ret = hid_hw_raw_request(g15->hdev, LG_G510_INPUT_KBD_BACKLIGHT,
+ g15->transfer_buf, 2,
+ HID_INPUT_REPORT, HID_REQ_GET_REPORT);
+ if (ret != 2) {
+ /* This can happen when a KVM switch is used, so only warn. */
+ hid_warn(g15->hdev, "Error getting backlight state: %d\n", ret);
+ return 0;
+ }
+
+ g15->backlight_disabled = g15->transfer_buf[1] & 0x04;
+
return 0;
}
@@ -549,14 +567,24 @@ static int lg_g510_event(struct lg_g15_data *g15, u8 *data)
static int lg_g510_leds_event(struct lg_g15_data *g15, u8 *data)
{
+ struct lg_g15_led *g15_led = &g15->leds[LG_G15_KBD_BRIGHTNESS];
bool backlight_disabled;
+ backlight_disabled = data[1] & 0x04;
+ if (backlight_disabled == g15->backlight_disabled)
+ return 0;
+
+ led_classdev_notify_brightness_hw_changed(
+ &g15_led->mcdev.led_cdev,
+ backlight_disabled ? 0 : g15_led->brightness);
+
+ g15->backlight_disabled = backlight_disabled;
+
/*
* The G510 ignores backlight updates when the backlight is turned off
* through the light toggle button on the keyboard, to work around this
* we queue a workitem to sync values when the backlight is turned on.
*/
- backlight_disabled = data[1] & 0x04;
if (!backlight_disabled)
schedule_work(&g15->work);
@@ -588,9 +616,9 @@ static int lg_g15_raw_event(struct hid_device *hdev, struct hid_report *report,
break;
case LG_G510:
case LG_G510_USB_AUDIO:
- if (data[0] == 0x03 && size == 5)
+ if (data[0] == LG_G510_INPUT_MACRO_KEYS && size == 5)
return lg_g510_event(g15, data);
- if (data[0] == 0x04 && size == 2)
+ if (data[0] == LG_G510_INPUT_KBD_BACKLIGHT && size == 2)
return lg_g510_leds_event(g15, data);
break;
}
@@ -624,6 +652,9 @@ static void lg_g15_setup_led_rgb(struct lg_g15_data *g15, int index)
g15->leds[index].mcdev.led_cdev.max_brightness = 255;
g15->leds[index].mcdev.num_colors = 3;
+ if (index == LG_G15_KBD_BRIGHTNESS)
+ g15->leds[index].mcdev.led_cdev.flags = LED_BRIGHT_HW_CHANGED;
+
subled_info = devm_kcalloc(&g15->hdev->dev, 3, sizeof(*subled_info), GFP_KERNEL);
if (!subled_info)
return;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-08 21:30 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <CALTg27=uP+jCU7oog41GiZrw7LX_mSfrQtKbDW+xpAHzN7_6cQ@mail.gmail.com>
On 04/09/2025 16.12, Stuart wrote:
>> Hm. It appears I may have misunderstood how this works. Please undo the
>> previous diff and apply the following on top instead:
>
> Done, still no change :(
Unfortunately I'm out of ideas for now. Looking at it again, I think the
first approach seemed more promising. Perhaps I missed something.
>> I think it happens when the devices paired to it disconnect/reconnect.
>
> Yep, that matches
>
>> Can you also dump the HID report descriptors when the keyboard is
>> plugged in directly via USB?
>
> Sure (046d:c343):
>
> 003:007:002:DESCRIPTOR 1756991366.823468
> 06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
> FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
> A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
> 00 09 02 91 00 C0
>
> 003:007:001:DESCRIPTOR 1756991366.827464
> 05 01 09 02 A1 01 85 02 09 01 A1 00 95 10 75 01
> 15 00 25 01 05 09 19 01 29 10 81 02 95 02 75 10
> 16 01 80 26 FF 7F 05 01 09 30 09 31 81 06 95 01
> 75 08 15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38
> 02 81 06 C0 C0 05 0C 09 01 A1 01 85 03 95 02 75
> 10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
> 09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
> 09 81 09 83 81 00 75 06 81 03 C0
>
> 003:007:000:DESCRIPTOR 1756991366.831465
> 05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
> 75 01 95 08 81 02 95 05 05 08 19 01 29 05 91 02
> 95 01 75 03 91 03 95 70 75 01 05 07 19 04 29 73
> 81 02 95 05 19 87 29 8B 81 02 95 03 19 90 29 92
> 81 02 C0
I was hoping that would give me a clue, but unfortunately it did not.
I suspect simply sending the LED report to the receiver itself with
Report ID 1 is not enough, which is what the first diff does.
Perhaps you could try a packet capture with the Logitech provided driver
in a VM running a well known commercial operating system + usbmon on the
host to see what HID report actually gets sent.
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Stuart @ 2025-09-08 23:59 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <93bf9cfc-29ca-40e4-baef-47c5bd0e9cee@protonmail.com>
What does logitech-dj do differently to the generic HID driver around the LEDs?
The caps lock LED works perfectly fine with the generic driver.
If that goes nowhere, surely I could do a packet capture from Linux, with and
without the logitech-dj driver active?
Stuart
^ permalink raw reply
* Plain text ver. libinput issue 318 について / Regarding libinput issue 318
From: demetriatemp @ 2025-09-09 4:38 UTC (permalink / raw)
To: masaki.ota@jp.alps.com
Cc: linux-input@vger.kernel.org, benjamin.tissoires@redhat.com
There is an English version below.
---
こんにちは。
Linuxの初心者で、ハードウェアが正常に動作しません。
libinput#318 についてです。
https://gitlab.freedesktop.org/libinput/libinput/-/issues/318
そこには問題の説明と役立つファイルがあります。
あたしのモデルはX2ですけど、Jon Westさんが修正したファイルは動作すると思います。
カーネル 6.16.5 との diff を作成しましたが、パッチは古くて、カーネルの新しい変更が元に戻ってしまいます。
必要の変更は分からないので、アップロードしませんでした。
アップストリームで修正していただけないでしょうか？
あたしプログラマーではないので、この問題を報告するしかできません。
ご苦労様でした。
日本語が下手でごめんなさい。
---
Hello.
I'm new to Linux and my hardware isn't working properly.
I'm referring to libinput#318
https://gitlab.freedesktop.org/libinput/libinput/-/issues/318
It has a description of the problem and helpful files.
My model is an X2, but I think Jon West's modified file will work.
I created a diff with kernel 6.16.5, but the patch is old and reverts the new kernel changes.
I don't know what changes are necessary so I didn't upload it.
Could this please be fixed upstream?
I'm not a programmer, so all I can do is report this issue.
Thank you all for your hard work.
^ permalink raw reply
* [PATCH v2 0/2] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Svyatoslav Ryhel @ 2025-09-09 5:49 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, Svyatoslav Ryhel, Linus Walleij
Cc: linux-input, devicetree, linux-kernel
This provides support for generic touchscreen configuration options like
swapped-x-y, min-x, min-y, size-x, size-y, etc.
---
Changes in v2:
- added schema adjustment
---
Svyatoslav Ryhel (2):
dt-bindings: input: maxtouch: add common touchscreen properties
input: touchscreen: atmel_mxt_ts: add support for generic touchscreen
configurations
.../devicetree/bindings/input/atmel,maxtouch.yaml | 3 ++-
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++----
2 files changed, 9 insertions(+), 5 deletions(-)
--
2.48.1
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: input: maxtouch: add common touchscreen properties
From: Svyatoslav Ryhel @ 2025-09-09 5:49 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, Svyatoslav Ryhel, Linus Walleij
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20250909054903.11519-1-clamor95@gmail.com>
Since atmel,maxtouch describes touchscreens too, it should include common
touchscreen properties.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index c40799355ed7..d79b254f1cde 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -16,6 +16,7 @@ description: |
allOf:
- $ref: input.yaml#
+ - $ref: touchscreen/touchscreen.yaml#
properties:
compatible:
@@ -95,7 +96,7 @@ required:
- reg
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.48.1
^ permalink raw reply related
* [PATCH v2 2/2] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Svyatoslav Ryhel @ 2025-09-09 5:49 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, Svyatoslav Ryhel, Linus Walleij
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20250909054903.11519-1-clamor95@gmail.com>
This provides support for generic touchscreen configuration options like
swapped-x-y, min-x, min-y, size-x, size-y, etc.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 322d5a3d40a0..fc624101147e 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -19,6 +19,7 @@
#include <linux/firmware.h>
#include <linux/i2c.h>
#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/of.h>
@@ -355,6 +356,8 @@ struct mxt_data {
enum mxt_suspend_mode suspend_mode;
u32 wakeup_method;
+
+ struct touchscreen_properties prop;
};
struct mxt_vb2_buffer {
@@ -888,8 +891,7 @@ static void mxt_proc_t9_message(struct mxt_data *data, u8 *message)
/* Touch active */
input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, 1);
- input_report_abs(input_dev, ABS_MT_POSITION_X, x);
- input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
+ touchscreen_report_pos(input_dev, &data->prop, x, y, true);
input_report_abs(input_dev, ABS_MT_PRESSURE, amplitude);
input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, area);
} else {
@@ -1010,8 +1012,7 @@ static void mxt_proc_t100_message(struct mxt_data *data, u8 *message)
id, type, x, y, major, pressure, orientation);
input_mt_report_slot_state(input_dev, tool, 1);
- input_report_abs(input_dev, ABS_MT_POSITION_X, x);
- input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
+ touchscreen_report_pos(input_dev, &data->prop, x, y, true);
input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, major);
input_report_abs(input_dev, ABS_MT_PRESSURE, pressure);
input_report_abs(input_dev, ABS_MT_DISTANCE, distance);
@@ -2212,6 +2213,8 @@ static int mxt_initialize_input_device(struct mxt_data *data)
0, 255, 0, 0);
}
+ touchscreen_parse_properties(input_dev, true, &data->prop);
+
/* For T15 and T97 Key Array */
if (data->T15_reportid_min || data->T97_reportid_min) {
for (i = 0; i < data->t15_num_keys; i++)
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-09 6:23 UTC (permalink / raw)
To: Mukesh R
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <d7d7b23f-eaea-2dbc-9c9d-4bee082f6fe7@linux.microsoft.com>
On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote:
> On 9/6/25 04:36, Greg KH wrote:
> > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
> >> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
> >> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
> >> hypervisor support, such as hypercalls, clocks/timers, Confidential
> >> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
> >> devices.
> >
> > But why are you making it so that this can not be a module anymore? You
> > are now forcing ALL Linux distro users to always have this code in their
> > system, despite not ever using the feature. That feels like a waste to
> > me.
> >
> > What is preventing this from staying as a module? Why must you always
> > have this code loaded at all times for everyone?
>
> This is currently not a module. I assume it was at the beginning. In
> drivers/Makefile today:
>
> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
>
>
> More context: CONFIG_HYPERV doesn't really reflect one module. It is
> both for kernel built in code and building of stuff in drivers/hv.
>
> drivers/hv then builds 4 modules:
>
> obj-$(CONFIG_HYPERV) += hv_vmbus.o
> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
>
> Notice vmbus is using CONFIG_HYPERV because there is no
> CONFIG_HYPERV_VMBUS. We are trying to fix that here.
Ah, I missed that this was getting changed in the Makefile in patch 1,
that is what I was worried about.
Nevermind, this should be fine, sorry for the noise. I'll go queue it
up later today.
greg k-h
^ permalink raw reply
* Re: [PATCH v1 03/14] dt-bindings: arm: mediatek: mmsys: Add assigned-clocks/rates properties
From: Krzysztof Kozlowski @ 2025-09-09 6:29 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <1cf0b296-adaa-4c80-864c-9b78f09cd3e3@collabora.com>
On 08/09/2025 21:19, Ariel D'Alessandro wrote:
> Krzysztof,
>
> On 8/21/25 3:43 AM, Krzysztof Kozlowski wrote:
>> On Wed, Aug 20, 2025 at 02:12:51PM -0300, Ariel D'Alessandro wrote:
>>> Current, the DT bindings for MediaTek mmsys controller is missing the
>>> assigned-clocks and assigned-clocks-rates properties. Add these and
>>
>> No, they do not miss them. I don't understand why you are adding these.
>
> The reason I added these is due to the following check error:
>
> $ make -j$(nproc) CHECK_DTBS=y mediatek/mt8173-elm.dtb
> DTC [C] arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
> [...]
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: syscon@14000000
> (mediatek,mt8173-mmsys): 'assigned-clock-rates', 'assigned-clocks' do
> not match any of the regexes: '^pinctrl-[0-9]+$'
> from schema $id:
> http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
This is looking like missing clocks or other unevaluated property by the
binding.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 01/14] media: dt-bindings: Convert MediaTek mt8173-mdp bindings to YAML
From: Krzysztof Kozlowski @ 2025-09-09 6:32 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, ck.hu, conor+dt,
davem, dmitry.torokhov, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
linus.walleij, louisalexis.eyraud, maarten.lankhorst,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-clk, linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-sound, netdev
In-Reply-To: <d286ec0b-c8dc-4103-9aa3-2f40e0ade4a3@collabora.com>
On 08/09/2025 19:52, Ariel D'Alessandro wrote:
> Krzysztof,
>
> On 8/21/25 3:46 AM, Krzysztof Kozlowski wrote:
>> On Wed, Aug 20, 2025 at 02:12:49PM -0300, Ariel D'Alessandro wrote:
>>> Convert the existing text-based DT bindings for MediaTek MT8173 Media Data Path
>>> to a YAML schema.
>>
>> Please wrap commit message according to Linux coding style / submission
>> process (neither too early nor over the limit):
>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
> Thanks. Looks like my editor was misconfigured, sorry. Will fix in v2.
>
>>
>>>
>>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>>> ---
>>> .../bindings/media/mediatek,mt8173-mdp.yaml | 174 ++++++++++++++++++
>>> .../bindings/media/mediatek-mdp.txt | 95 ----------
>>> 2 files changed, 174 insertions(+), 95 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>>> delete mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>>> new file mode 100644
>>> index 0000000000000..f3a08afc305b1
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>>> @@ -0,0 +1,174 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/media/mediatek,mt8173-mdp.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: MediaTek MT8173 Media Data Path
>>> +
>>> +maintainers:
>>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>>> +
>>> +description:
>>> + Media Data Path is used for scaling and color space conversion.
>>> +
>>> +properties:
>>> + compatible:
>>> + oneOf:
>>> + - items:
>>
>> Just enum, no items here
>
> See below.
>
>>
>>
>>> + - enum:
>>> + - mediatek,mt8173-mdp-rdma
>>> + - mediatek,mt8173-mdp-rsz
>>> + - mediatek,mt8173-mdp-wdma
>>> + - mediatek,mt8173-mdp-wrot
>>> + - items:
>>> + - enum:
>>> + - mediatek,mt8173-mdp-rdma
>>> + - mediatek,mt8173-mdp-rsz
>>> + - mediatek,mt8173-mdp-wdma
>>> + - mediatek,mt8173-mdp-wrot
>>> + - const: mediatek,mt8173-mdp
>>
>> This makes no sense. How devices can be compatible and can not be
>> compatible.
>
> According to the driver source code (and the previous txt mt8173-mdp
> bindings), there must be a "controller node" with compatible
> `mediatek,mt8173-mdp`. Then its sibling nodes (including itself) should
But you did not define "mediatek,mt8173-mdp" here, so what are you
talking about?
I talk here about "wrot" and others, I thought it is obvious from the
mistake in the schema.
> be one of the component node ids, listed in `struct of_device_id
> mtk_mdp_comp_dt_ids[]`.
>
> Is there a proper/different way to describe this compatible binding in
> the yaml? Or you're saying the driver doesn't make sense here?
>
> [0] drivers/media/platform/mediatek/mdp/mtk_mdp_core.c
>
>>
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + clocks: true
>>
>> No, there's no such syntax. Look at other bindings.
>
> Ack.
>
>>
>>
>>> +
>>> + power-domains:
>>> + maxItems: 1
>>> +
>>> + iommus:
>>> + description: |
>>
>> Drop |
>
> Ack.
>
>>
>>> + This property should point to the respective IOMMU block with master port as argument,
>>> + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
>>
>> Drop entire description, completely redundant. I don't know why my patch
>> fixing this was not applied, so you keep repeating same mistakes...
>
> Ack.
>
>>
>>> + maxItems: 1
>>> +
>>> + mediatek,vpu:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description:
>>> + Describes point to vpu.
>>
>> Useless description. We see that from the property name. Explain the
>> purpose in the hardware.
>
> Ack.
>
>>
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - clocks
>>> + - power-domains
>>> +
>>> +allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: mediatek,mt8173-mdp-rdma
>>> + then:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: Main clock
>>> + - description: Mutex clock
>>> + else:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: Main clock
>>> +
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - mediatek,mt8173-mdp-rdma
>>> + - mediatek,mt8173-mdp-wdma
>>> + - mediatek,mt8173-mdp-wrot
>>> + then:
>>> + required:
>>> + - iommus
>>> +
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: mediatek,mt8173-mdp
>>
>> This makes no sense either.
>
> Same question above about compatibles.
How same question? Do you understand this code? It is nothing the same -
you have here contains!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 13/14] dt-bindings: input/touchscreen: Convert MELFAS MIP4 Touchscreen to YAML
From: Krzysztof Kozlowski @ 2025-09-09 6:56 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov
Cc: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, angelogioacchino.delregno, broonie, chunkuang.hu,
ck.hu, conor+dt, davem, edumazet, flora.fu, houlong.wei, jeesw,
jmassot, kernel, krzk+dt, kuba, kyrie.wu, lgirdwood,
louisalexis.eyraud, maarten.lankhorst, matthias.bgg, mchehab,
minghsiu.tsai, mripard, p.zabel, pabeni, robh, sean.wang, simona,
support.opensource, tiffany.lin, tzimmermann, yunfei.dong,
devicetree, dri-devel, linux-arm-kernel, linux-clk, linux-gpio,
linux-input, linux-kernel, linux-media, linux-mediatek,
linux-sound, netdev
In-Reply-To: <CACRpkdZRHQ6vuchN8x8d0uPCVMPPHOdBVWiUhzFJNs2paHGbYw@mail.gmail.com>
On 05/09/2025 13:33, Linus Walleij wrote:
> On Fri, Sep 5, 2025 at 12:02 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Thu, Aug 21, 2025 at 01:56:24PM +0200, Linus Walleij wrote:
>>> Hi Ariel,
>>>
>>> thanks for your patch!
>>>
>>> On Wed, Aug 20, 2025 at 7:17 PM Ariel D'Alessandro
>>> <ariel.dalessandro@collabora.com> wrote:
>>>
>>>> + ce-gpios:
>>>> + description: GPIO connected to the CE (chip enable) pin of the chip
>>>> + maxItems: 1
>>>
>>> Mention that this should always have the flag GPIO_ACTIVE_HIGH
>>> as this is required by the hardware.
>>>
>>> Unfortunately we have no YAML syntax for enforcing flags :/
>>
>> Theoretically there can be an inverter on the line, so from the AP point
>> of view the line is active low while from the peripheral POV the pin is
>> active high...
>
> Yes, I think someone even proposed adding inverters to the
> device tree and was nixed.
It's not about DT, it's about board design - you can (almost?) always
invert the logical signal, so this should match what hardware requires
plus any inverter on the board.
>
> It's a matter of phrasing I would say:
>
> "Mention that this should nominally have the flag GPIO_ACTIVE_HIGH
No, please do not, it is wrong. If hardware requires active high, then
just say this is active high. But the actual GPIO flag depends on the
board design if signal is inverted.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox