* Re: [PATCH v3 0/3] Radxa NIO 12L: Add GPIO keys and LED support
From: Rob Herring (Arm) @ 2025-09-05 17:45 UTC (permalink / raw)
To: Julien Massot
Cc: Louis-Alexis Eyraud, kernel, linux-mediatek,
AngeloGioacchino Del Regno, linux-kernel, linux-input,
Matthias Brugger, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, Dmitry Torokhov, devicetree
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com>
On Fri, 05 Sep 2025 13:51:57 +0200, Julien Massot wrote:
> This patchset adds support for the GPIO-connected red and blue LEDs,
> as well as the various hardware buttons present on the Radxa NIO 12L
> board.
>
> It also includes a fix for the missing release (key-up) interrupt
> handling for PMIC-managed GPIO keys.
>
> Signed-off-by: Julien Massot <julien.massot@collabora.com>
> ---
> Changes in v3:
> Patch 3/3: drop the deprecated LEDs label property
> - Link to v2: https://lore.kernel.org/r/20250826-radxa-nio-12-l-gpio-v2-0-7f18fa3fbfc8@collabora.com
>
> Changes in v2:
> PATCH 1/3
> - Add Fixes tag
> - Drop Angelo's Reviewed-By since I'm now introducing the
> 'key_release_irq' member that was missing in v1.
> - Link to v1: https://lore.kernel.org/r/20250801-radxa-nio-12-l-gpio-v1-0-d0840f85d2c8@collabora.com
>
> ---
> Julien Massot (3):
> Input: mtk-pmic-keys - MT6359 has a specific release irq
> arm64: dts: mediatek: mt8395-nio-12l: add PMIC and GPIO keys support
> arm64: dts: mediatek: mt8395-nio-12l: add support for blue and red LEDs
>
> .../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 65 ++++++++++++++++++++++
> drivers/input/keyboard/mtk-pmic-keys.c | 5 +-
> 2 files changed, 69 insertions(+), 1 deletion(-)
> ---
> base-commit: 6c68f4c0a147c025ae0b25fab688c7c47964a02f
> change-id: 20250801-radxa-nio-12-l-gpio-54f208c25333
>
> Best regards,
> --
> Julien Massot <julien.massot@collabora.com>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
This patch series was applied (using b4) to base:
Base: using specified base-commit 6c68f4c0a147c025ae0b25fab688c7c47964a02f
If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)
New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/mediatek/' for 20250905-radxa-nio-12-l-gpio-v3-0-40f11377fb55@collabora.com:
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: gpio-leds (gpio-leds): 'rgb-blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: input: exc3000: move eeti,egalax_ts from egalax-ts.txt to eeti,exc3000.yaml
From: Rob Herring (Arm) @ 2025-09-05 18:12 UTC (permalink / raw)
To: Frank Li
Cc: Krzysztof Kozlowski, devicetree, linux-kernel, imx, linux-input,
Dmitry Torokhov, Conor Dooley
In-Reply-To: <20250904171543.517650-1-Frank.Li@nxp.com>
On Thu, 04 Sep 2025 13:15:41 -0400, Frank Li wrote:
> Remove legacy binding egalax-ts.txt file. And add compatible string
> eeti,egalax_ts and wakeup-gpios to eeti,exc3000.yaml. "eeti,egalax_ts" is
> general compatible string, which is not preferred. But it is compatible
> with old devices (older than 10 years) and existing driver in
> drivers/input/touchscreen/egalax_ts.c.
>
> Allow address 0x4 for eeti,egalax_ts.
>
> Don't require touchscreen-size-x(y) for eeti,egalax_ts.
>
> Keep the same restriction for existing compatible string.
>
> Fix below DTB_CHECKS warnings:
> arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dtb: /soc/bus@2100000/i2c@21a8000/egalax_ts@4: failed to match any schema with compatible: ['eeti,egalax_ts']
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v2
> - sorry missed one local change at v1
> - allow address 0x4 for eeti,egalax_ts.
> - move out touchscreen-size-x(y) from required.
> ---
> .../input/touchscreen/eeti,exc3000.yaml | 30 +++++++++++++++----
> .../bindings/input/touchscreen/egalax-ts.txt | 18 -----------
> 2 files changed, 24 insertions(+), 24 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Seeking help debugging a crash in hid-magicmouse
From: Andrew Rodland @ 2025-09-05 18:17 UTC (permalink / raw)
To: linux-input
Hi,
I use an Apple Magic Trackpad 2 (2024 USB-C model) on my Linux desktop.
After upgrading from Linux 6.16.3 to 6.16.4 (6.16.4-arch1-1:
https://github.com/archlinux/linux/releases/tag/v6.16.4-arch1 -- I don't
think there's anything terrible in the patchset), I was suffering from
periodic crashes.
I rebuilt the kernel with debug symbols and enabled kdump and captured
this dmesg:
[32607.193629] [ C7] BUG: kernel NULL pointer dereference, address:
000000000000001c
[32607.193636] [ C7] #PF: supervisor read access in kernel mode
[32607.193637] [ C7] #PF: error_code(0x0000) - not-present page
[32607.193638] [ C7] PGD 910ad3067 P4D 910ad3067 PUD 9a49a3067 PMD
6e1bc2067 PTE 0
[32607.193641] [ C7] Oops: Oops: 0000 [#1] SMP NOPTI
[32607.193644] [ C7] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump:
loaded Tainted: P S OE 6.16.4-arch1-1-kdump #2
PREEMPT(lazy) a4265b7ab8b2a583c4532d85e7773a521cc6f594
[32607.193647] [ C7] Tainted: [P]=PROPRIETARY_MODULE,
[S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[32607.193648] [ C7] Hardware name: Micro-Star International Co.,
Ltd. MS-7E59/MAG X870E TOMAHAWK WIFI (MS-7E59), BIOS 2.A84 08/05/2025
[32607.193649] [ C7] RIP: 0010:magicmouse_event+0x13/0x40
[hid_magicmouse]
[32607.193654] [ C7] Code: 0f 1f 80 00 00 00 00 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 87 50 19
00 00 48 8b 00 <0f> b7 40 1c 66 3d 69 02 74 0f 31 d2 66 3d 23 03 74 07
89 d0 c3 cc
[32607.193655] [ C7] RSP: 0018:ffffd26900454d50 EFLAGS: 00010246
[32607.193656] [ C7] RAX: 0000000000000000 RBX: 0000000000000001
RCX: 0000000000000001
[32607.193656] [ C7] RDX: ffff8ad502029e88 RSI: ffff8ad502029e00
RDI: ffff8ad50cb9a000
[32607.193657] [ C7] RBP: 0000000000000001 R08: ffffffffc0431950
R09: 0000000000000002
[32607.193657] [ C7] R10: ffff8ad50a101000 R11: 0000000000000064
R12: ffff8ad50cb9a000
[32607.193658] [ C7] R13: ffff8ad502029e88 R14: ffffffffc03fd080
R15: ffff8ad502029e00
[32607.193659] [ C7] FS: 0000000000000000(0000)
GS:ffff8aebe30ea000(0000) knlGS:0000000000000000
[32607.193659] [ C7] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[32607.193660] [ C7] CR2: 000000000000001c CR3: 000000074f246000
CR4: 0000000000f50ef0
[32607.193661] [ C7] DR0: 0000000141952b70 DR1: 0000000000000000
DR2: 0000000000000000
[32607.193661] [ C7] DR3: 0000000000000000 DR6: 00000000ffff0ff0
DR7: 0000000000000600
[32607.193662] [ C7] PKRU: 55555554
[32607.193662] [ C7] Call Trace:
[32607.193664] [ C7] <IRQ>
[32607.193665] [ C7] hid_process_event+0xb4/0x130
[32607.193671] [ C7] hid_report_raw_event+0x323/0x4c0
[32607.193674] [ C7] __hid_input_report+0x14d/0x200
[32607.193676] [ C7] hid_input_report+0x15/0x20
[32607.193677] [ C7] hid_irq_in+0x1a1/0x1d0
[32607.193679] [ C7] __usb_hcd_giveback_urb+0x9d/0x120
[32607.193682] [ C7] usb_giveback_urb_bh+0xc3/0x150
[32607.193684] [ C7] process_one_work+0x190/0x350
[32607.193686] [ C7] bh_worker+0x1ac/0x210
[32607.193688] [ C7] ? sched_clock_cpu+0xf/0x200
[32607.193691] [ C7] tasklet_hi_action+0x13/0x30
[32607.193693] [ C7] handle_softirqs+0xe3/0x2a0
[32607.193694] [ C7] __irq_exit_rcu+0xcb/0xf0
[32607.193696] [ C7] common_interrupt+0x85/0xa0
[32607.193699] [ C7] </IRQ>
[32607.193699] [ C7] <TASK>
[32607.193699] [ C7] asm_common_interrupt+0x26/0x40
[32607.193701] [ C7] RIP: 0010:cpuidle_enter_state+0xbb/0x410
[32607.193703] [ C7] Code: 00 00 e8 d8 86 0b ff e8 e3 f2 ff ff 48
89 c5 0f 1f 44 00 00 31 ff e8 c4 ff 09 ff 45 84 ff 0f 85 33 02 00 00 fb
0f 1f 44 00 00 <45> 85 f6 0f 88 7c 01 00 00 49 63 ce 48 2b 2c 24 48 6b
d1 68 48 89
[32607.193704] [ C7] RSP: 0018:ffffd2690025fe78 EFLAGS: 00000246
[32607.193704] [ C7] RAX: ffff8aebe30ea000 RBX: 0000000000000002
RCX: 0000000000000000
[32607.193705] [ C7] RDX: 00001da7f4314dff RSI: fffffff7ee2390e5
RDI: 0000000000000000
[32607.193705] [ C7] RBP: 00001da7f4314dff R08: 0000000000000002
R09: 000000000000adcb
[32607.193705] [ C7] R10: 00000000000002dd R11: ffffffffffffffff
R12: ffff8ad501313400
[32607.193706] [ C7] R13: ffffffff9bffc440 R14: 0000000000000002
R15: 0000000000000000
[32607.193708] [ C7] ? cpuidle_enter_state+0xac/0x410
[32607.193709] [ C7] cpuidle_enter+0x31/0x50
[32607.193711] [ C7] do_idle+0x1b1/0x210
[32607.193714] [ C7] cpu_startup_entry+0x29/0x30
[32607.193715] [ C7] start_secondary+0x119/0x140
[32607.193718] [ C7] common_startup_64+0x13e/0x141
[32607.193720] [ C7] </TASK>
[32607.193721] [ C7] Modules linked in: xpad hid_playstation
ff_memless led_class_multicolor uinput xt_MASQUERADE xt_tcpudp xt_mark
snd_seq_dummy rfcomm snd_hrtimer snd_seq tun nf_tables ip6table_nat
ip6table_filter ip6_tables iptable_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter uhid cmac algif_hash
algif_skcipher af_alg bnep nct6683 amd_atl intel_rapl_msr
intel_rapl_common btusb snd_usb_audio btrtl btintel snd_usbmidi_lib
kvm_amd snd_ump btbcm snd_rawmidi btmtk apple_mfi_fastcharge kvm
snd_seq_device bluetooth mousedev joydev mc irqbypass polyval_clmulni
ghash_clmulni_intel rfkill snd_hda_codec_hdmi sha512_ssse3 snd_hda_intel
sha1_ssse3 aesni_intel snd_intel_dspcfg spd5118 snd_intel_sdw_acpi
wmi_bmof rapl pcspkr sp5100_tco snd_hda_codec zfs(POE) thunderbolt
snd_hda_core i2c_piix4 k10temp ccp snd_hwdep r8169 i2c_smbus snd_pcm
realtek mdio_devres snd_timer libphy snd soundcore spl(OE) mdio_bus
gpio_amdpt gpio_generic mac_hid sg i2c_dev crypto_user dm_mod loop
nfnetlink ip_tables x_tables amdgpu amdxcp
[32607.193749] [ C7] i2c_algo_bit drm_ttm_helper ttm drm_exec
gpu_sched drm_suballoc_helper drm_panel_backlight_quirks nvme uas
drm_buddy nvme_core usb_storage hid_magicmouse drm_display_helper
nvme_keyring cec nvme_auth video wmi
[32607.193755] [ C7] CR2: 000000000000001c
Unfortunately the core file itself was too large and was truncated, and
can't be loaded.
If I rebuild with the following patch applied:
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index 226682762db3..7be2daffc6fb 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -522,6 +522,11 @@ static int magicmouse_event(struct hid_device
*hdev, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
struct magicmouse_sc *msc = hid_get_drvdata(hdev);
+ if (!msc || !msc->input) {
+ hid_warn(hdev, "this would have crashed\n");
+ return 0;
+ }
+
if ((msc->input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE2 ||
msc->input->id.product ==
USB_DEVICE_ID_APPLE_MAGICMOUSE2_USBC) &&
field->report->id == MOUSE2_REPORT_ID) {
then I receive
[45398.145218] magicmouse 0003:05AC:0324.0003: this would have crashed
and the system does, in fact, not crash.
I have no idea what the cause is; in this instance the message appeared
for the first time about 12 hours after system boot (but sometimes it's
much faster), it printed several times a second for 42 minutes (I guess
I should have used hid_warn_ratelimited), and then stopped again. The
trackpad remained usable throughout.
Please let me know if there's anything I can do to help debug further. I
know my way around the kernel tolerably well, but I don't have any
particular knowledge of the HID subsystem.
Thanks,
Andrew
^ permalink raw reply related
* Re: [PATCH] dt-bindings: input: touchscreen: goodix: Drop 'interrupts' requirement
From: Conor Dooley @ 2025-09-05 18:47 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-input, Conor Dooley, Dmitry Torokhov, Krzysztof Kozlowski,
Rob Herring, devicetree, linux-renesas-soc
In-Reply-To: <20250904195727.168152-1-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v2] hid: intel-thc-hid: intel-quicki2c: support ACPI config for advanced features
From: srinivas pandruvada @ 2025-09-05 16:54 UTC (permalink / raw)
To: Xinpeng Sun, jikos, bentiss; +Cc: linux-input, linux-kernel, Rui Zhang
In-Reply-To: <20250905013935.1356008-1-xinpeng.sun@intel.com>
On Fri, 2025-09-05 at 09:39 +0800, Xinpeng Sun wrote:
> There is a new BIOS enhancement that adds the capability to configure
> the
> following two features of I2C subsystem introduced in commit 1ed0b48
> ("Intel-thc: Introduce max input size control") and commit 3f2a921
> ("Intel-thc: Introduce interrupt delay control"):
> - Max input size control
> - Interrupt delay control
>
> As BIOS is used for the configuration of these two features, change
> driver
> data usage to indicate hardware capability, and add corresponding
> ACPI
> configuration support in QuickI2C driver.
>
> Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>
> Tested-by: Rui Zhang <rui1.zhang@intel.com>
> ---
>
Why the patch was resent?
If maintainer didn't review, just remind them after atleast 2 weeks
instead of sending again.
For any other reason add some change log here.
Thanks,
Srinivas
> .../intel-quicki2c/pci-quicki2c.c | 43 ++++++++++++++---
> --
> .../intel-quicki2c/quicki2c-dev.h | 24 ++++++++++-
> 2 files changed, 55 insertions(+), 12 deletions(-)
>
> 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 854926b3cfd4..787c32557d24 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -23,6 +23,7 @@
>
> static struct quicki2c_ddata ptl_ddata = {
> .max_detect_size = MAX_RX_DETECT_SIZE_PTL,
> + .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
> };
>
> /* THC QuickI2C ACPI method to get device properties */
> @@ -123,8 +124,8 @@ static int quicki2c_acpi_get_dsd_property(struct
> acpi_device *adev, acpi_string
> static int quicki2c_get_acpi_resources(struct quicki2c_device
> *qcdev)
> {
> struct acpi_device *adev = ACPI_COMPANION(qcdev->dev);
> - struct quicki2c_subip_acpi_parameter i2c_param;
> - struct quicki2c_subip_acpi_config i2c_config;
> + struct quicki2c_subip_acpi_parameter i2c_param = {0};
> + struct quicki2c_subip_acpi_config i2c_config = {0};
> u32 hid_desc_addr;
> int ret = -EINVAL;
>
> @@ -200,6 +201,21 @@ static int quicki2c_get_acpi_resources(struct
> quicki2c_device *qcdev)
> return -EOPNOTSUPP;
> }
>
> + if (qcdev->ddata) {
> + qcdev->i2c_max_frame_size_enable = i2c_config.FSEN;
> + qcdev->i2c_int_delay_enable = i2c_config.INDE;
> +
> + if (i2c_config.FSVL <= qcdev->ddata-
> >max_detect_size)
> + qcdev->i2c_max_frame_size = i2c_config.FSVL;
> + else
> + qcdev->i2c_max_frame_size = qcdev->ddata-
> >max_detect_size;
> +
> + if (i2c_config.INDV <= qcdev->ddata-
> >max_interrupt_delay)
> + qcdev->i2c_int_delay = i2c_config.INDV;
> + else
> + qcdev->i2c_int_delay = qcdev->ddata-
> >max_interrupt_delay;
> + }
> +
> return 0;
> }
>
> @@ -441,17 +457,24 @@ static void quicki2c_dma_adv_enable(struct
> quicki2c_device *qcdev)
> * max input length <= THC detect capability, enable the
> feature with device
> * max input length.
> */
> - if (qcdev->ddata->max_detect_size >=
> - le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> - thc_i2c_set_rx_max_size(qcdev->thc_hw,
> - le16_to_cpu(qcdev-
> >dev_desc.max_input_len));
> + if (qcdev->i2c_max_frame_size_enable) {
> + if (qcdev->i2c_max_frame_size >=
> + le16_to_cpu(qcdev->dev_desc.max_input_len)) {
> + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> + le16_to_cpu(qcdev-
> >dev_desc.max_input_len));
> + } else {
> + dev_warn(qcdev->dev,
> + "Max frame size is smaller than hid
> max input length!");
> + thc_i2c_set_rx_max_size(qcdev->thc_hw,
> + le16_to_cpu(qcdev-
> >i2c_max_frame_size));
> + }
> thc_i2c_rx_max_size_enable(qcdev->thc_hw, true);
> }
>
> /* If platform supports interrupt delay feature, enable it
> with given delay */
> - if (qcdev->ddata->interrupt_delay) {
> + if (qcdev->i2c_int_delay_enable) {
> thc_i2c_set_rx_int_delay(qcdev->thc_hw,
> - qcdev->ddata-
> >interrupt_delay);
> + qcdev->i2c_int_delay * 10);
> thc_i2c_rx_int_delay_enable(qcdev->thc_hw, true);
> }
> }
> @@ -464,10 +487,10 @@ static void quicki2c_dma_adv_enable(struct
> quicki2c_device *qcdev)
> */
> static void quicki2c_dma_adv_disable(struct quicki2c_device *qcdev)
> {
> - if (qcdev->ddata->max_detect_size)
> + if (qcdev->i2c_max_frame_size_enable)
> thc_i2c_rx_max_size_enable(qcdev->thc_hw, false);
>
> - if (qcdev->ddata->interrupt_delay)
> + if (qcdev->i2c_int_delay_enable)
> thc_i2c_rx_int_delay_enable(qcdev->thc_hw, false);
> }
>
> 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 d412eafcf9ea..0d423d5dd7a7 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
> @@ -38,6 +38,8 @@
>
> /* PTL Max packet size detection capability is 255 Bytes */
> #define MAX_RX_DETECT_SIZE_PTL 255
> +/* Max interrupt delay capability is 2.56ms */
> +#define MAX_RX_INTERRUPT_DELAY 256
>
> /* Default interrupt delay is 1ms, suitable for most devices */
> #define DEFAULT_INTERRUPT_DELAY_US (1 * USEC_PER_MSEC)
> @@ -101,6 +103,10 @@ struct quicki2c_subip_acpi_parameter {
> * @HMTD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line
> Transmit HOLD Period
> * @HMRD: High Speed Mode Plus (3.4Mbits/sec) Serial Data Line
> Receive HOLD Period
> * @HMSL: Maximum length (in ic_clk_cycles) of suppressed spikes in
> High Speed Mode
> + * @FSEN: Maximum Frame Size Feature Enable Control
> + * @FSVL: Maximum Frame Size Value (unit in Bytes)
> + * @INDE: Interrupt Delay Feature Enable Control
> + * @INDV: Interrupt Delay Value (unit in 10 us)
> *
> * Those properties get from QUICKI2C_ACPI_METHOD_NAME_ISUB method,
> used for
> * I2C timing configure.
> @@ -127,17 +133,22 @@ struct quicki2c_subip_acpi_config {
> u64 HMTD;
> u64 HMRD;
> u64 HMSL;
> +
> + u64 FSEN;
> + u64 FSVL;
> + u64 INDE;
> + u64 INDV;
> u8 reserved;
> };
>
> /**
> * struct quicki2c_ddata - Driver specific data for quicki2c device
> * @max_detect_size: Identify max packet size detect for rx
> - * @interrupt_delay: Identify interrupt detect delay for rx
> + * @interrupt_delay: Identify max interrupt detect delay for rx
> */
> struct quicki2c_ddata {
> u32 max_detect_size;
> - u32 interrupt_delay;
> + u32 max_interrupt_delay;
> };
>
> struct device;
> @@ -170,6 +181,10 @@ struct acpi_device;
> * @report_len: The length of input/output report packet
> * @reset_ack_wq: Workqueue for waiting reset response from device
> * @reset_ack: Indicate reset response received or not
> + * @i2c_max_frame_size_enable: Indicate max frame size feature
> enabled or not
> + * @i2c_max_frame_size: Max RX frame size (unit in Bytes)
> + * @i2c_int_delay_enable: Indicate interrupt delay feature enabled
> or not
> + * @i2c_int_delay: Interrupt detection delay value (unit in 10 us)
> */
> struct quicki2c_device {
> struct device *dev;
> @@ -200,6 +215,11 @@ struct quicki2c_device {
>
> wait_queue_head_t reset_ack_wq;
> bool reset_ack;
> +
> + u32 i2c_max_frame_size_enable;
> + u32 i2c_max_frame_size;
> + u32 i2c_int_delay_enable;
> + u32 i2c_int_delay;
> };
>
> #endif /* _QUICKI2C_DEV_H_ */
^ permalink raw reply
* [PATCH 1/1] dt-bindings: input: convert tca8418_keypad.txt to yaml format
From: Frank Li @ 2025-09-05 19:06 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Convert tca8418_keypad.txt to yaml format.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../bindings/input/tca8418_keypad.txt | 10 ---
.../devicetree/bindings/input/ti,tca8418.yaml | 61 +++++++++++++++++++
2 files changed, 61 insertions(+), 10 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/tca8418_keypad.txt
create mode 100644 Documentation/devicetree/bindings/input/ti,tca8418.yaml
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
deleted file mode 100644
index 2551850091678..0000000000000
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-This binding is based on the matrix-keymap binding with the following
-changes:
-
-keypad,num-rows and keypad,num-columns are required.
-
-Required properties:
-- compatible: "ti,tca8418"
-- reg: the I2C address
-- interrupts: IRQ line number, should trigger on falling edge
-- linux,keymap: Keys definitions, see keypad-matrix.
diff --git a/Documentation/devicetree/bindings/input/ti,tca8418.yaml b/Documentation/devicetree/bindings/input/ti,tca8418.yaml
new file mode 100644
index 0000000000000..114de435b09d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,tca8418.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,tca8418.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C/SMBus keypad scanner
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,tca8418
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: matrix-keymap.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ keypad@34 {
+ compatible = "ti,tca8418";
+ reg = <0x34>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ keypad,num-rows = <4>;
+ keypad,num-columns = <4>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x01, BTN_0)
+ MATRIX_KEY(0x00, 0x00, BTN_1)
+ MATRIX_KEY(0x01, 0x01, BTN_2)
+ MATRIX_KEY(0x01, 0x00, BTN_3)
+ MATRIX_KEY(0x02, 0x00, BTN_4)
+ MATRIX_KEY(0x00, 0x03, BTN_5)
+ MATRIX_KEY(0x00, 0x02, BTN_6)
+ MATRIX_KEY(0x01, 0x03, BTN_7)
+ MATRIX_KEY(0x01, 0x02, BTN_8)
+ MATRIX_KEY(0x02, 0x02, BTN_9)
+ >;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/1] dt-bindings: input: convert semtech,sx8654 to yaml format
From: Rob Herring (Arm) @ 2025-09-05 19:17 UTC (permalink / raw)
To: Frank Li
Cc: devicetree, Dmitry Torokhov, linux-input, Conor Dooley,
Krzysztof Kozlowski, imx, linux-kernel
In-Reply-To: <20250904191731.528145-1-Frank.Li@nxp.com>
On Thu, 04 Sep 2025 15:17:28 -0400, Frank Li wrote:
> Convert sx8654.txt to yaml format.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../input/touchscreen/semtech,sx8654.yaml | 52 +++++++++++++++++++
> .../bindings/input/touchscreen/sx8654.txt | 23 --------
> 2 files changed, 52 insertions(+), 23 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: input: convert tca8418_keypad.txt to yaml format
From: Fabio Estevam @ 2025-09-05 19:17 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, imx
In-Reply-To: <20250905190645.609762-1-Frank.Li@nxp.com>
On Fri, Sep 5, 2025 at 4:08 PM Frank Li <Frank.Li@nxp.com> wrote:
> +title: I2C/SMBus keypad scanner
This title is too generic.
You should include the part number:
title: TCA8418 I2C/SMBus keypad scanner
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Nuno Das Neves @ 2025-09-05 20:08 UTC (permalink / raw)
To: Mukesh R, Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <4f38c613-255c-eaf6-0d50-28f8ffc02fff@linux.microsoft.com>
On 9/4/2025 11:18 AM, Mukesh R wrote:
> On 9/4/25 09:26, Michael Kelley wrote:
>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>
>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>
>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>
>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>> CONFIG_HYPERV could be changed to bool.
>>>>
>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>> is already mostly in separate source files code, though there's some
>>>> entanglement in the handling of VMBus interrupts, which could be
>>>> improved later.
>>>>
>>>> However, I have a compatibility concern. Consider this scenario:
>>>>
>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>> built with CONFIG_HYPERV=m.
>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>> 4) Build the new kernel. This succeeds.
>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>
>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>> newly built kernel has no Hyper-V support and won't run in a
>>>> Hyper-V VM.
It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
I guess any invalid value turns to =n, which makes sense most of the time.
>>>>
>>>> As a second issue, if in Step 1 the current kernel was built with
>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>> and won't run in a typical Hyper-V VM.
>>>>
>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>> I'm not sure how to fix the first issue, except by continuing to
>>>> allow CONFIG_HYPERV=m.
I'm wondering, is there a path for this change, then? Are there some
intermediate step/s we could take to minimize the problem?
>>>
>>> To certain extent, imo, users are expected to check config files
>>> for changes when moving to new versions/releases, so it would be a
>>> one time burden.
>>
>> I'm not so sanguine about the impact. For those of us who work with
>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>> the details of how the Kconfig files are put together. And the issue occurs
>> with no error messages that something has gone wrong in building
>> the kernel, except that it won't boot. Just running "make olddefconfig"
>> has worked in the past, so some users will be befuddled and end up
>> generating Azure support incidents. I also wonder about breaking
>> automated test suites for new kernels, as they are likely to be running
>> "make olddefconfig" or something similar as part of the automation.
>>
>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>
>>
>> I agree that's not ideal. But note that some Hyper-V code and symbols
>> like ms_hyperv_init_platform() and related functions show up when
>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>> is one of the recognized and somewhat hardwired hypervisors (like
>> VMware, for example).
>>
>> Finally, there are about a dozen other places in the kernel that use
>> the same Makefile construct to make some code built-in even though
>> the CONFIG option is set to "m". That may not be enough occurrences
>> to make it standard practice, but Hyper-V guests are certainly not the
>> only case.
>>
>> In my mind, this is judgment call with no absolute right answer. What
>> do others think about the tradeoffs?
>
> Wei had said in private message that he agrees this is a good idea. Nuno
> said earlier above:
>
> "FWIW I think it's a good idea, interested to hear what others think."
>
That was before Michael pointed out the potential issues which I was
unaware of. Let's see if there's a path that is smoother for all the
downstream users who may be compiling with CONFIG_HYPERV=m.
Nuno
> Thanks,> -Mukesh
>
>
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: input: convert max11801-ts to yaml format
From: Rob Herring (Arm) @ 2025-09-05 20:33 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Krzysztof Kozlowski, imx, devicetree,
linux-input, Conor Dooley, linux-kernel
In-Reply-To: <20250904200641.531897-1-Frank.Li@nxp.com>
On Thu, 04 Sep 2025 16:06:37 -0400, Frank Li wrote:
> Convert max11801-ts to yaml format.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../input/touchscreen/max11801-ts.txt | 17 -------
> .../input/touchscreen/maxim,max11801.yaml | 46 +++++++++++++++++++
> 2 files changed, 46 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-05 21:41 UTC (permalink / raw)
To: Nuno Das Neves, Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <231f05cb-4f33-48ac-bb2e-1359ed52e606@linux.microsoft.com>
On 9/5/25 13:08, Nuno Das Neves wrote:
> On 9/4/2025 11:18 AM, Mukesh R wrote:
>> On 9/4/25 09:26, Michael Kelley wrote:
>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>>
>>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>>
>>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>>
>>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>>> CONFIG_HYPERV could be changed to bool.
>>>>>
>>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>>> is already mostly in separate source files code, though there's some
>>>>> entanglement in the handling of VMBus interrupts, which could be
>>>>> improved later.
>>>>>
>>>>> However, I have a compatibility concern. Consider this scenario:
>>>>>
>>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>> built with CONFIG_HYPERV=m.
>>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>>> 4) Build the new kernel. This succeeds.
>>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>>
>>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>>> newly built kernel has no Hyper-V support and won't run in a
>>>>> Hyper-V VM.
>
> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
> I guess any invalid value turns to =n, which makes sense most of the time.
>
>>>>>
>>>>> As a second issue, if in Step 1 the current kernel was built with
>>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>>> and won't run in a typical Hyper-V VM.
>>>>>
>>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>>> I'm not sure how to fix the first issue, except by continuing to
>>>>> allow CONFIG_HYPERV=m.
>
> I'm wondering, is there a path for this change, then? Are there some
> intermediate step/s we could take to minimize the problem?
>
>>>>
>>>> To certain extent, imo, users are expected to check config files
>>>> for changes when moving to new versions/releases, so it would be a
>>>> one time burden.
>>>
>>> I'm not so sanguine about the impact. For those of us who work with
>>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>>> the details of how the Kconfig files are put together. And the issue occurs
>>> with no error messages that something has gone wrong in building
>>> the kernel, except that it won't boot. Just running "make olddefconfig"
>>> has worked in the past, so some users will be befuddled and end up
>>> generating Azure support incidents. I also wonder about breaking
>>> automated test suites for new kernels, as they are likely to be running
>>> "make olddefconfig" or something similar as part of the automation.
>>>
>>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>>
>>>
>>> I agree that's not ideal. But note that some Hyper-V code and symbols
>>> like ms_hyperv_init_platform() and related functions show up when
>>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>>> is one of the recognized and somewhat hardwired hypervisors (like
>>> VMware, for example).
>>>
>>> Finally, there are about a dozen other places in the kernel that use
>>> the same Makefile construct to make some code built-in even though
>>> the CONFIG option is set to "m". That may not be enough occurrences
>>> to make it standard practice, but Hyper-V guests are certainly not the
>>> only case.
>>>
>>> In my mind, this is judgment call with no absolute right answer. What
>>> do others think about the tradeoffs?
>>
>> Wei had said in private message that he agrees this is a good idea. Nuno
>> said earlier above:
>>
>> "FWIW I think it's a good idea, interested to hear what others think."
>>
> That was before Michael pointed out the potential issues which I was
> unaware of. Let's see if there's a path that is smoother for all the
> downstream users who may be compiling with CONFIG_HYPERV=m.
Ok, we've already thought of it for sometime and not able to come up
with any. IMO, it's a minor hickup, not major. This is stalling
upcoming iommu and other patches which will use CONFIG_HYPERV and
add more dependencies, and it would be much harder to straighten
out then. So I hope you guys can come up with some solution sooner than
later, I can't think of any.
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-06 0:34 UTC (permalink / raw)
To: Nuno Das Neves, Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <6a26cbf8-7877-4f39-0ed3-7bbc306f9fe5@linux.microsoft.com>
On 9/5/25 14:41, Mukesh R wrote:
> On 9/5/25 13:08, Nuno Das Neves wrote:
>> On 9/4/2025 11:18 AM, Mukesh R wrote:
>>> On 9/4/25 09:26, Michael Kelley wrote:
>>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>>>
>>>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>>>
>>>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>>>
>>>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>>>> CONFIG_HYPERV could be changed to bool.
>>>>>>
>>>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>>>> is already mostly in separate source files code, though there's some
>>>>>> entanglement in the handling of VMBus interrupts, which could be
>>>>>> improved later.
>>>>>>
>>>>>> However, I have a compatibility concern. Consider this scenario:
>>>>>>
>>>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>>> built with CONFIG_HYPERV=m.
>>>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>>>> 4) Build the new kernel. This succeeds.
>>>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>>>
>>>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>>>> newly built kernel has no Hyper-V support and won't run in a
>>>>>> Hyper-V VM.
>>
>> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
>> I guess any invalid value turns to =n, which makes sense most of the time.
>>
>>>>>>
>>>>>> As a second issue, if in Step 1 the current kernel was built with
>>>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>>>> and won't run in a typical Hyper-V VM.
>>>>>>
>>>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>>>> I'm not sure how to fix the first issue, except by continuing to
>>>>>> allow CONFIG_HYPERV=m.
>>
>> I'm wondering, is there a path for this change, then? Are there some
>> intermediate step/s we could take to minimize the problem?
>>
>>>>>
>>>>> To certain extent, imo, users are expected to check config files
>>>>> for changes when moving to new versions/releases, so it would be a
>>>>> one time burden.
>>>>
>>>> I'm not so sanguine about the impact. For those of us who work with
>>>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>>>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>>>> the details of how the Kconfig files are put together. And the issue occurs
>>>> with no error messages that something has gone wrong in building
>>>> the kernel, except that it won't boot. Just running "make olddefconfig"
>>>> has worked in the past, so some users will be befuddled and end up
>>>> generating Azure support incidents. I also wonder about breaking
>>>> automated test suites for new kernels, as they are likely to be running
>>>> "make olddefconfig" or something similar as part of the automation.
>>>>
>>>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>>>
>>>>
>>>> I agree that's not ideal. But note that some Hyper-V code and symbols
>>>> like ms_hyperv_init_platform() and related functions show up when
>>>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>>>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>>>> is one of the recognized and somewhat hardwired hypervisors (like
>>>> VMware, for example).
>>>>
>>>> Finally, there are about a dozen other places in the kernel that use
>>>> the same Makefile construct to make some code built-in even though
>>>> the CONFIG option is set to "m". That may not be enough occurrences
>>>> to make it standard practice, but Hyper-V guests are certainly not the
>>>> only case.
>>>>
>>>> In my mind, this is judgment call with no absolute right answer. What
>>>> do others think about the tradeoffs?
>>>
>>> Wei had said in private message that he agrees this is a good idea. Nuno
>>> said earlier above:
>>>
>>> "FWIW I think it's a good idea, interested to hear what others think."
>>>
>> That was before Michael pointed out the potential issues which I was
>> unaware of. Let's see if there's a path that is smoother for all the
>> downstream users who may be compiling with CONFIG_HYPERV=m.
>
> Ok, we've already thought of it for sometime and not able to come up
> with any. IMO, it's a minor hickup, not major. This is stalling
> upcoming iommu and other patches which will use CONFIG_HYPERV and
> add more dependencies, and it would be much harder to straighten
> out then. So I hope you guys can come up with some solution sooner than
> later, I can't think of any.
Played around a bit, setting it to "default HYPERV" like Michael suggested
gives it a default value of y. I thought it fail if one is bool and other
is tristate. So that should help with transition.
Thanks,
-Mukesh
^ permalink raw reply
* [PATCH v1 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: 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, gregkh, deller, arnd, sgarzare,
horms
At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
hv_common.c that is needed for the drivers. Moreover, vmbus driver is
built if CONFIG_HYPER is set, either loadable or builtin.
This is not a good approach. CONFIG_HYPERV is really an umbrella
config that encompasses builtin code and various other things and not
a dedicated config option for VMBus. VMBus should really have a config
option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
explicit. With that CONFIG_HYPERV could be changed to bool.
For now, hv_common.c is left as is to reduce conflicts for upcoming
patches, but once merges are mostly done, that and some others should
be moved to virt/hyperv directory.
V1:
o Change subject from hyper-v to "Drivers: hv:"
o Rewrite commit messages paying attention to VMBus and not vmbus
o Change some wordings in Kconfig
o Make new VMBUS config option default to HYPERV option for a smoother
transition
Mukesh Rathor (2):
Driver: hv: Add CONFIG_HYPERV_VMBUS option
Drivers: hv: Make CONFIG_HYPERV bool
drivers/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 15 +++++++++++----
drivers/hv/Makefile | 4 ++--
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
13 files changed, 29 insertions(+), 20 deletions(-)
--
2.36.1.vfs.0.0
^ permalink raw reply
* [PATCH v1 1/2] Driver: hv: Add CONFIG_HYPERV_VMBUS option
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: 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, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
At present VMBus driver is hinged off of CONFIG_HYPERV which entails
lot of builtin code and encompasses too much. It's not always clear
what depends on builtin hv code and what depends on VMBus. Setting
CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin
adds even more confusion. VMBus is an independent module and should have
its own config option. Also, there are scenarios like baremetal dom0/root
where support is built in with CONFIG_HYPERV but without VMBus. Lastly,
there are more features coming down that use CONFIG_HYPERV and add more
dependencies on it.
So, create a fine grained HYPERV_VMBUS option and update Kconfigs for
dependency on VMBus.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 13 ++++++++++---
drivers/hv/Makefile | 2 +-
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
12 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..58f34da061c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
- depends on DRM && PCI && HYPERV
+ depends on DRM && PCI && HYPERV_VMBUS
select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..fe3dc8c0db99 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1162,7 +1162,7 @@ config GREENASIA_FF
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Select this option to enable the Hyper-V mouse driver.
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 2e8df09db599..fe29f8dca2b5 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -44,18 +44,25 @@ config HYPERV_TIMER
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
- depends on HYPERV && CONNECTOR && NLS
+ depends on HYPERV_VMBUS && CONNECTOR && NLS
depends on PTP_1588_CLOCK_OPTIONAL
help
Select this option to enable the Hyper-V Utilities.
config HYPERV_BALLOON
tristate "Microsoft Hyper-V Balloon driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select PAGE_REPORTING
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_VMBUS
+ tristate "Microsoft Hyper-V VMBus driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable Hyper-V Vmbus driver.
+
config MSHV_ROOT
tristate "Microsoft Hyper-V root partition support"
depends on HYPERV && (X86_64 || ARM64)
@@ -75,7 +82,7 @@ config MSHV_ROOT
config MSHV_VTL
tristate "Microsoft Hyper-V VTL driver"
- depends on X86_64 && HYPERV_VTL_MODE
+ depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
# specially with large memory requirements.
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index c53a0df746b7..050517756a82 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_HYPERV) += hv_vmbus.o
+obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 17edc1597446..c7ef347a4dff 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
config HYPERV_KEYBOARD
tristate "Microsoft Synthetic Keyboard driver"
- depends on HYPERV
- default HYPERV
+ depends on HYPERV_VMBUS
+ default HYPERV_VMBUS
help
Select this option to enable the Hyper-V Keyboard driver.
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index c8cbd85adcf9..982964c1a9fb 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select UCS2_STRING
select NLS
help
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a249c65aedc..7065a8e5f9b1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -221,7 +221,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
+ depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
select PCI_HYPERV_INTERFACE
select IRQ_MSI_LIB
help
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5522310bab8d..19d0884479a2 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
config HYPERV_STORAGE
tristate "Microsoft Hyper-V virtual storage driver"
- depends on SCSI && HYPERV
+ depends on SCSI && HYPERV_VMBUS
depends on m || SCSI_FC_ATTRS != m
default HYPERV
help
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c635..6f86a61231e6 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -140,7 +140,7 @@ config UIO_MF624
config UIO_HV_GENERIC
tristate "Generic driver for Hyper-V VMBus"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Generic driver that you can bind, dynamically, to any
Hyper-V VMBus device. It is useful to provide direct access
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c21484d15f0c..72c63eaeb983 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1774,7 +1774,7 @@ config FB_BROADSHEET
config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
- depends on FB && HYPERV
+ depends on FB && HYPERV_VMBUS
select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
select FB_IOMEM_HELPERS_DEFERRED
help
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 1d2ad1304ad4..66c58c91b530 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
void __init hv_mark_resources(void);
+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
/* Free the message slot and signal end-of-message if required */
static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
{
@@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
}
}
+extern int vmbus_interrupt;
+extern int vmbus_irq;
+#endif /* CONFIG_HYPERV_VMBUS */
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
void hv_setup_vmbus_handler(void (*handler)(void));
@@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
void hv_remove_crash_handler(void);
void hv_setup_mshv_handler(void (*handler)(void));
-extern int vmbus_interrupt;
-extern int vmbus_irq;
-
#if IS_ENABLED(CONFIG_HYPERV)
/*
* Hypervisor's notion of virtual processor ID is different from
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 56356d2980c8..8e803c4828c4 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
config HYPERV_VSOCKETS
tristate "Hyper-V transport for Virtual Sockets"
- depends on VSOCKETS && HYPERV
+ depends on VSOCKETS && HYPERV_VMBUS
help
This module implements a Hyper-V transport for Virtual Sockets.
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: 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, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
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.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index b5749cf67044..7ad5744db0b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE) += soundwire/
# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) += virt/
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
+obj-$(CONFIG_HYPERV) += hv/
obj-$(CONFIG_PM_DEVFREQ) += devfreq/
obj-$(CONFIG_EXTCON) += extcon/
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index fe29f8dca2b5..7e56c51c5080 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,7 +3,7 @@
menu "Microsoft Hyper-V guest support"
config HYPERV
- tristate "Microsoft Hyper-V client drivers"
+ bool "Microsoft Hyper-V core hypervisor support"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ARM64 && !CPU_BIG_ENDIAN)
select PARAVIRT
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 050517756a82..8b04a33e4dd8 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -18,7 +18,7 @@ mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
mshv_vtl-y := mshv_vtl_main.o
# Code that must be built-in
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
+obj-$(CONFIG_HYPERV) += hv_common.o
obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o
ifneq ($(CONFIG_MSHV_ROOT) $(CONFIG_MSHV_VTL),)
obj-y += mshv_common.o
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [dtor-input:next] BUILD SUCCESS 0fec357ad073e555e7553dbc0d32278b0aaa2179
From: kernel test robot @ 2025-09-06 1:45 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: 0fec357ad073e555e7553dbc0d32278b0aaa2179 dt-bindings: input: touchscreen: imagis: add missing minItems
elapsed time: 2055m
configs tested: 100
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig gcc-15.1.0
arc randconfig-001-20250905 gcc-11.5.0
arc randconfig-002-20250905 gcc-13.4.0
arm allmodconfig gcc-15.1.0
arm allnoconfig clang-22
arm allyesconfig gcc-15.1.0
arm randconfig-001-20250905 clang-22
arm randconfig-002-20250905 clang-22
arm randconfig-003-20250905 clang-16
arm randconfig-004-20250905 gcc-14.3.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.1.0
arm64 randconfig-001-20250905 clang-22
arm64 randconfig-002-20250905 clang-17
arm64 randconfig-003-20250905 clang-17
arm64 randconfig-004-20250905 clang-22
csky allnoconfig gcc-15.1.0
csky randconfig-001-20250905 gcc-15.1.0
csky randconfig-002-20250905 gcc-13.4.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-22
hexagon allyesconfig clang-22
hexagon randconfig-001-20250905 clang-22
hexagon randconfig-002-20250905 clang-22
i386 allmodconfig gcc-13
i386 allnoconfig gcc-13
i386 allyesconfig gcc-13
i386 buildonly-randconfig-001-20250905 clang-20
i386 buildonly-randconfig-002-20250905 clang-20
i386 buildonly-randconfig-003-20250905 clang-20
i386 buildonly-randconfig-004-20250905 gcc-13
i386 buildonly-randconfig-005-20250905 clang-20
i386 buildonly-randconfig-006-20250905 clang-20
i386 defconfig clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch randconfig-001-20250905 clang-18
loongarch randconfig-002-20250905 clang-18
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
mips allnoconfig gcc-15.1.0
nios2 allnoconfig gcc-11.5.0
nios2 randconfig-001-20250905 gcc-10.5.0
nios2 randconfig-002-20250905 gcc-11.5.0
openrisc allnoconfig gcc-15.1.0
parisc allnoconfig gcc-15.1.0
parisc randconfig-001-20250905 gcc-15.1.0
parisc randconfig-002-20250905 gcc-8.5.0
powerpc allnoconfig gcc-15.1.0
powerpc randconfig-001-20250905 gcc-8.5.0
powerpc randconfig-002-20250905 clang-22
powerpc randconfig-003-20250905 gcc-8.5.0
powerpc64 randconfig-001-20250905 clang-22
powerpc64 randconfig-002-20250905 clang-22
powerpc64 randconfig-003-20250905 gcc-14.3.0
riscv allnoconfig gcc-15.1.0
riscv randconfig-001-20250905 gcc-14.3.0
riscv randconfig-002-20250905 clang-22
s390 allmodconfig clang-18
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 randconfig-001-20250905 gcc-9.5.0
s390 randconfig-002-20250905 clang-22
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh randconfig-001-20250905 gcc-15.1.0
sh randconfig-002-20250905 gcc-15.1.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc randconfig-001-20250905 gcc-8.5.0
sparc randconfig-002-20250905 gcc-15.1.0
sparc64 randconfig-001-20250905 gcc-8.5.0
sparc64 randconfig-002-20250905 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-13
um randconfig-001-20250905 clang-22
um randconfig-002-20250905 gcc-13
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20250905 clang-20
x86_64 buildonly-randconfig-002-20250905 clang-20
x86_64 buildonly-randconfig-003-20250905 gcc-13
x86_64 buildonly-randconfig-004-20250905 clang-20
x86_64 buildonly-randconfig-005-20250905 clang-20
x86_64 buildonly-randconfig-006-20250905 gcc-13
x86_64 defconfig gcc-11
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20250905 gcc-8.5.0
xtensa randconfig-002-20250905 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-06 11:36 UTC (permalink / raw)
To: Mukesh Rathor
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: <20250906010952.2145389-3-mrathor@linux.microsoft.com>
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?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: input: exc3000: move eeti,egalax_ts from egalax-ts.txt to eeti,exc3000.yaml
From: Dmitry Torokhov @ 2025-09-06 16:20 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, imx
In-Reply-To: <20250904171543.517650-1-Frank.Li@nxp.com>
On Thu, Sep 04, 2025 at 01:15:41PM -0400, Frank Li wrote:
> Remove legacy binding egalax-ts.txt file. And add compatible string
> eeti,egalax_ts and wakeup-gpios to eeti,exc3000.yaml. "eeti,egalax_ts" is
> general compatible string, which is not preferred. But it is compatible
> with old devices (older than 10 years) and existing driver in
> drivers/input/touchscreen/egalax_ts.c.
>
> Allow address 0x4 for eeti,egalax_ts.
>
> Don't require touchscreen-size-x(y) for eeti,egalax_ts.
>
> Keep the same restriction for existing compatible string.
>
> Fix below DTB_CHECKS warnings:
> arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dtb: /soc/bus@2100000/i2c@21a8000/egalax_ts@4: failed to match any schema with compatible: ['eeti,egalax_ts']
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: input: convert semtech,sx8654 to yaml format
From: Dmitry Torokhov @ 2025-09-06 16:20 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, imx
In-Reply-To: <20250904191731.528145-1-Frank.Li@nxp.com>
On Thu, Sep 04, 2025 at 03:17:28PM -0400, Frank Li wrote:
> Convert sx8654.txt to yaml format.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: goodix: Drop 'interrupts' requirement
From: Dmitry Torokhov @ 2025-09-06 16:20 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-input, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
devicetree, linux-renesas-soc
In-Reply-To: <20250904195727.168152-1-marek.vasut+renesas@mailbox.org>
On Thu, Sep 04, 2025 at 09:57:04PM +0200, Marek Vasut wrote:
> Since commit 409fe0cea366 ("Input: goodix - add support for polling mode")
> the interrupts property is optional, since at least the Linux kernel driver
> supports also polling mode.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: input: convert max11801-ts to yaml format
From: Dmitry Torokhov @ 2025-09-06 16:21 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, imx
In-Reply-To: <20250904200641.531897-1-Frank.Li@nxp.com>
On Thu, Sep 04, 2025 at 04:06:37PM -0400, Frank Li wrote:
> Convert max11801-ts to yaml format.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/3] Input: mtk-pmic-keys - MT6359 has a specific release irq
From: Dmitry Torokhov @ 2025-09-06 16:25 UTC (permalink / raw)
To: Julien Massot
Cc: kernel, Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Louis-Alexis Eyraud,
linux-input, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree
In-Reply-To: <20250905-radxa-nio-12-l-gpio-v3-1-40f11377fb55@collabora.com>
On Fri, Sep 05, 2025 at 01:51:58PM +0200, Julien Massot wrote:
> 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>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH v3 RESEND] HID: Xinmeng: Add driver for Xinmeng M71 Keyboard
From: Saalim Quadri @ 2025-09-07 11:12 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel, Saalim Quadri
In this driver, the battery is probed, and it checks the capacity
and charging status of the battery
Signed-off-by: Saalim Quadri <danascape@gmail.com>
---
v2 -> v3:
Match lore email to the driver
assign ret val while probing battery
v1 -> v2: Update Kconfig paragraph :/
drivers/hid/Kconfig | 12 +++
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 3 +
drivers/hid/hid-xinmeng.c | 170 ++++++++++++++++++++++++++++++++++++++
4 files changed, 186 insertions(+)
create mode 100644 drivers/hid/hid-xinmeng.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 43859fc75747..1cc61ca63682 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -536,6 +536,18 @@ config HID_XIAOMI
Adds support for side buttons of Xiaomi Mi Dual Mode Wireless
Mouse Silent Edition.
+config HID_XINMENG
+ tristate "Xinmeng Keyboards"
+ depends on USB_HID
+ help
+ Support for Xinmeng Keyboard.
+
+ Say Y here if you have a Xinmeng M71 Keyboard
+ and want to be able to read its battery capacity.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hid-xinmeng.
+
config HID_GYRATION
tristate "Gyration remote control"
help
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 10ae5dedbd84..e5c9d1276138 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_HID_UDRAW_PS3) += hid-udraw-ps3.o
obj-$(CONFIG_HID_UNIVERSAL_PIDFF) += hid-universal-pidff.o
obj-$(CONFIG_HID_LED) += hid-led.o
obj-$(CONFIG_HID_XIAOMI) += hid-xiaomi.o
+obj-$(CONFIG_HID_XINMENG) += hid-xinmeng.o
obj-$(CONFIG_HID_XINMO) += hid-xinmo.o
obj-$(CONFIG_HID_ZEROPLUS) += hid-zpff.o
obj-$(CONFIG_HID_ZYDACRON) += hid-zydacron.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e3fb4e2fe911..f649549bd58c 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1471,6 +1471,9 @@
#define USB_DEVICE_ID_XIN_MO_DUAL_ARCADE 0x05e1
#define USB_DEVICE_ID_THT_2P_ARCADE 0x75e1
+#define USB_VENDOR_ID_XINMENG 0x3554
+#define USB_DEVICE_ID_XINMENG_M71_RECEIVER 0xfa09
+
#define USB_VENDOR_ID_XIROKU 0x1477
#define USB_DEVICE_ID_XIROKU_SPX 0x1006
#define USB_DEVICE_ID_XIROKU_MPX 0x1007
diff --git a/drivers/hid/hid-xinmeng.c b/drivers/hid/hid-xinmeng.c
new file mode 100644
index 000000000000..a4f5b181bca4
--- /dev/null
+++ b/drivers/hid/hid-xinmeng.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HID driver for Xinmeng M71 Keyboard.
+ *
+ * Copyright (c) 2025 Saalim Quadri <danascape@gmail.com>
+ */
+
+#include <linux/device.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+#include <linux/usb.h>
+
+#include "hid-ids.h"
+
+#define BATTERY_REPORT_ID (0x13)
+
+struct xinmeng_drvdata {
+ struct hid_device *hdev;
+ bool online;
+
+ struct power_supply *battery;
+ struct power_supply_desc battery_desc;
+ u8 battery_capacity;
+ bool battery_charging;
+};
+
+static enum power_supply_property xinmeng_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_MODEL_NAME,
+ POWER_SUPPLY_PROP_ONLINE
+};
+
+static int xinmeng_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct xinmeng_drvdata *drv_data = power_supply_get_drvdata(psy);
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = 1;
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = drv_data->online;
+ break;
+ case POWER_SUPPLY_PROP_STATUS:
+ if (drv_data->online)
+ val->intval = drv_data->battery_charging ?
+ POWER_SUPPLY_STATUS_CHARGING :
+ POWER_SUPPLY_STATUS_DISCHARGING;
+ else
+ val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = drv_data->battery_capacity;
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = drv_data->hdev->name;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int xinmeng_battery_probe(struct hid_device *hdev)
+{
+ struct xinmeng_drvdata *drv_data = hid_get_drvdata(hdev);
+ struct power_supply_config pscfg = { .drv_data = drv_data };
+ int ret = 0;
+
+ drv_data->online = false;
+ drv_data->battery_capacity = 0;
+
+ drv_data->battery_desc.name = "xinmeng-m71-battery";
+ drv_data->battery_desc.type = POWER_SUPPLY_TYPE_BATTERY;
+ drv_data->battery_desc.properties = xinmeng_battery_props;
+ drv_data->battery_desc.num_properties = ARRAY_SIZE(xinmeng_battery_props);
+ drv_data->battery_desc.get_property = xinmeng_battery_get_property;
+
+ drv_data->battery = devm_power_supply_register(&hdev->dev,
+ &drv_data->battery_desc, &pscfg);
+
+ if (IS_ERR(drv_data->battery)) {
+ ret = PTR_ERR(drv_data->battery);
+ drv_data->battery = NULL;
+ hid_err(hdev, "Unable to register battery device\n");
+ return ret;
+ }
+
+ power_supply_powers(drv_data->battery, &hdev->dev);
+
+ return ret;
+}
+
+static int xinmeng_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+ struct xinmeng_drvdata *drv_data;
+ struct usb_interface *usbif;
+
+ if (!hid_is_usb(hdev))
+ return -EINVAL;
+
+ usbif = to_usb_interface(hdev->dev.parent);
+
+ drv_data = devm_kzalloc(&hdev->dev, sizeof(*drv_data), GFP_KERNEL);
+ if (!drv_data)
+ return -ENOMEM;
+
+ hid_set_drvdata(hdev, drv_data);
+ drv_data->hdev = hdev;
+
+ ret = hid_parse(hdev);
+ if (ret)
+ return ret;
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret)
+ return ret;
+
+ if (usbif->cur_altsetting->desc.bInterfaceNumber == 1) {
+ ret = xinmeng_battery_probe(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "Xinmeng hid battery_probe failed: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int xinmeng_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ struct xinmeng_drvdata *drv_data = hid_get_drvdata(hdev);
+
+ if (drv_data->battery && data[0] == BATTERY_REPORT_ID) {
+ u8 charging_status = data[7];
+ bool is_charging = (charging_status == 0x11 || charging_status == 0x10);
+
+ drv_data->battery_capacity = data[6];
+ drv_data->battery_charging = is_charging;
+ drv_data->online = true;
+ }
+
+ return 0;
+}
+
+static const struct hid_device_id xinmeng_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_XINMENG, USB_DEVICE_ID_XINMENG_M71_RECEIVER) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, xinmeng_devices);
+
+static struct hid_driver xinmeng_driver = {
+ .name = "xinmeng",
+ .id_table = xinmeng_devices,
+ .probe = xinmeng_probe,
+ .raw_event = xinmeng_raw_event
+};
+module_hid_driver(xinmeng_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("HID driver for Xinmeng keyboards");
+MODULE_AUTHOR("Saalim Quadri <danascape@gmail.com>");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 RESEND] HID: Xinmeng: Add driver for Xinmeng M71 Keyboard
From: Saalim Quadri @ 2025-09-07 11:30 UTC (permalink / raw)
To: danascape; +Cc: bentiss, jikos, linux-input, linux-kernel
In-Reply-To: <20250907111246.9733-1-danascape@gmail.com>
Hello,
Sorry but I just found a few changes to do in the driver,
I will update the driver and send a new patch. I have been using
this driver in my system for quite a while now, and am able to read
battery info.
Sincerely,
Saalim Quadri
^ permalink raw reply
* [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
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