* Re: [PATCH v3 2/9] dt-bindings: input: mtk-pmic-keys: add MT6392 binding definition
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Gary Bisson,
Julien Massot, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-3-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the binding documentation of the mtk-pmic-keys for the MT6392 PMICs.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v3 1/9] dt-bindings: mfd: mt6397: Add bindings for MT6392 PMIC
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Gary Bisson, Louis-Alexis Eyraud,
Julien Massot, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-2-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the currently supported bindings for the MT6392 PMIC.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 6a89b479d10f..22b09e148d7c 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -40,6 +40,10 @@ properties:
> - mediatek,mt6358
> - mediatek,mt6359
> - mediatek,mt6397
> + - items:
> + - enum:
> + - mediatek,mt6392
> + - const: mediatek,mt6323
> - items:
> - enum:
> - mediatek,mt6366
> @@ -68,6 +72,10 @@ properties:
> - mediatek,mt6331-rtc
> - mediatek,mt6358-rtc
> - mediatek,mt6397-rtc
> + - items:
> + - enum:
> + - mediatek,mt6392-rtc
> + - const: mediatek,mt6323-rtc
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -92,6 +100,7 @@ properties:
> - mediatek,mt6328-regulator
> - mediatek,mt6358-regulator
> - mediatek,mt6359-regulator
> + - mediatek,mt6392-regulator
> - mediatek,mt6397-regulator
> - items:
> - enum:
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Val Packett, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, Linus Walleij, Liam Girdwood, Mark Brown,
Gary Bisson, Julien Massot, Louis-Alexis Eyraud, Fabien Parent,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-10-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Val Packett <val@packett.cool>
>
> Add the dts to be included by all boards using the MT6392 PMIC.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
> 1 file changed, 141 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> new file mode 100644
> index 000000000000..fbf6f671524c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2024 Val Packett <val@packett.cool>
> + */
> +
> +#include <dt-bindings/input/input.h>
> +
> +&pwrap {
> + pmic: pmic {
> + compatible = "mediatek,mt6392", "mediatek,mt6323";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + keys {
> + compatible = "mediatek,mt6392-keys";
> +
> + key-power {
> + linux,keycodes = <KEY_POWER>;
> + wakeup-source;
> + };
> +
> + key-home {
> + linux,keycodes = <KEY_HOME>;
> + wakeup-source;
> + };
> + };
> +
> + pio6392: pinctrl {
> + compatible = "mediatek,mt6392-pinctrl";
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + rtc {
> + compatible = "mediatek,mt6392-rtc",
> + "mediatek,mt6323-rtc";
> + };
> +
> + regulators {
> + compatible = "mediatek,mt6392-regulator";
> +
> + mt6392_vproc_reg: buck_vproc {
s/buck//g
Also, no min/max voltages?!
> + regulator-name = "vproc";
> + };
> +
> + mt6392_vsys_reg: buck_vsys {
> + regulator-name = "vsys";
> + };
> +
> + mt6392_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + };
> +
> + mt6392_vxo22_reg: ldo_vxo22 {
s/ldo//g
Also, same comment here, no min/max voltages?!
Most of those are easy too, because the regulator name actually tells you
the voltage it is supposed to output ;-)
Cheers,
Angelo
> + regulator-name = "vxo22";
> + };
> +
> + mt6392_vaud22_reg: ldo_vaud22 {
> + regulator-name = "vaud22";
> + };
> +
> + mt6392_vcama_reg: ldo_vcama {
> + regulator-name = "vcama";
> + };
> +
> + mt6392_vaud28_reg: ldo_vaud28 {
> + regulator-name = "vaud28";
> + };
> +
> + mt6392_vadc18_reg: ldo_vadc18 {
> + regulator-name = "vadc18";
> + };
> +
> + mt6392_vcn35_reg: ldo_vcn35 {
> + regulator-name = "vcn35";
> + };
> +
> + mt6392_vio28_reg: ldo_vio28 {
> + regulator-name = "vio28";
> + };
> +
> + mt6392_vusb_reg: ldo_vusb {
> + regulator-name = "vusb";
> + };
> +
> + mt6392_vmc_reg: ldo_vmc {
> + regulator-name = "vmc";
> + };
> +
> + mt6392_vmch_reg: ldo_vmch {
> + regulator-name = "vmch";
> + };
> +
> + mt6392_vemc3v3_reg: ldo_vemc3v3 {
> + regulator-name = "vemc3v3";
> + };
> +
> + mt6392_vgp1_reg: ldo_vgp1 {
> + regulator-name = "vgp1";
> + };
> +
> + mt6392_vgp2_reg: ldo_vgp2 {
> + regulator-name = "vgp2";
> + };
> +
> + mt6392_vcn18_reg: ldo_vcn18 {
> + regulator-name = "vcn18";
> + };
> +
> + mt6392_vcamaf_reg: ldo_vcamaf {
> + regulator-name = "vcamaf";
> + };
> +
> + mt6392_vm_reg: ldo_vm {
> + regulator-name = "vm";
> + };
> +
> + mt6392_vio18_reg: ldo_vio18 {
> + regulator-name = "vio18";
> + };
> +
> + mt6392_vcamd_reg: ldo_vcamd {
> + regulator-name = "vcamd";
> + };
> +
> + mt6392_vcamio_reg: ldo_vcamio {
> + regulator-name = "vcamio";
> + };
> +
> + mt6392_vm25_reg: ldo_vm25 {
> + regulator-name = "vm25";
> + };
> +
> + mt6392_vefuse_reg: ldo_vefuse {
> + regulator-name = "vefuse";
> + };
> + };
> + };
> +};
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Julien Massot,
Gary Bisson, Louis-Alexis Eyraud, Val Packett, Fabien Parent,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-4-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 318 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 342 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..fa4aad2dcbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,318 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 Regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + All voltage regulators provided by the PMIC are described as sub-nodes of
> + this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
> +
> +patternProperties:
> + "^(buck_)?v(core|proc|sys)$":
> + description: Buck regulators
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(adc18|camio|cn18|io18)$":
There was a discussion a bit of time ago and we decided to drop the "ldo_" and
"buck_" prefix from the regulators.
Can you please drop those?
Cheers,
Angelo
> + description: LDOs with fixed 1.8V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(xo22)$":
> + description: LDOs with fixed 2.2V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(m25)$":
> + description: LDOs with fixed 2.5V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(aud28|io28)$":
> + description: LDOs with fixed 2.8V output w/ mode
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(cama)$":
> + description: LDOs with fixed 2.8V output w/o mode
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> + "^(ldo_)?vusb$":
> + description: LDOs with fixed 3.3V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(aud22|camaf|camd|cn35|efuse|emc3v3|gp1|gp2|m|mc|mch)$":
> + description: LDOs with variable output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes: false
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + mt6392_regulators: regulators {
> + compatible = "mediatek,mt6392-regulator";
> +
> + mt6392_vproc_reg: buck_vproc {
> + regulator-name = "vproc";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <12500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vsys_reg: buck_vsys {
> + regulator-name = "vsys";
> + regulator-min-microvolt = <1400000>;
> + regulator-max-microvolt = <2987500>;
> + regulator-ramp-delay = <25000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <12500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vxo22_reg: ldo_vxo22 {
> + regulator-name = "vxo22";
> + regulator-min-microvolt = <2200000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-enable-ramp-delay = <110>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vaud22_reg: ldo_vaud22 {
> + regulator-name = "vaud22";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcama_reg: ldo_vcama {
> + regulator-name = "vcama";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vaud28_reg: ldo_vaud28 {
> + regulator-name = "vaud28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vadc18_reg: ldo_vadc18 {
> + regulator-name = "vadc18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcn35_reg: ldo_vcn35 {
> + regulator-name = "vcn35";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3600000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vio28_reg: ldo_vio28 {
> + regulator-name = "vio28";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vusb_reg: ldo_vusb {
> + regulator-name = "vusb";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vmc_reg: ldo_vmc {
> + regulator-name = "vmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-boot-on;
> + };
> +
> + mt6392_vmch_reg: ldo_vmch {
> + regulator-name = "vmch";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-boot-on;
> + };
> +
> + mt6392_vemc3v3_reg: ldo_vemc3v3 {
> + regulator-name = "vemc3v3";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-boot-on;
> + };
> +
> + mt6392_vgp1_reg: ldo_vgp1 {
> + regulator-name = "vgp1";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vgp2_reg: ldo_vgp2 {
> + regulator-name = "vgp2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vcn18_reg: ldo_vcn18 {
> + regulator-name = "vcn18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vcamaf_reg: ldo_vcamaf {
> + regulator-name = "vcamaf";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vm_reg: ldo_vm {
> + regulator-name = "vm";
> + regulator-min-microvolt = <1240000>;
> + regulator-max-microvolt = <1390000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vio18_reg: ldo_vio18 {
> + regulator-name = "vio18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcamd_reg: ldo_vcamd {
> + regulator-name = "vcamd";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vcamio_reg: ldo_vcamio {
> + regulator-name = "vcamio";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vm25_reg: ldo_vm25 {
> + regulator-name = "vm25";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vefuse_reg: ldo_vefuse {
> + regulator-name = "vefuse";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> + };
> diff --git a/include/dt-bindings/regulator/mediatek,mt6392-regulator.h b/include/dt-bindings/regulator/mediatek,mt6392-regulator.h
> new file mode 100644
> index 000000000000..8bd1a13faad8
> --- /dev/null
> +++ b/include/dt-bindings/regulator/mediatek,mt6392-regulator.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_REGULATOR_MEDIATEK_MT6392_H_
> +#define _DT_BINDINGS_REGULATOR_MEDIATEK_MT6392_H_
> +
> +/*
> + * Buck mode constants which may be used in devicetree properties (eg.
> + * regulator-initial-mode, regulator-allowed-modes).
> + * See the manufacturer's datasheet for more information on these modes.
> + */
> +
> +#define MT6392_BUCK_MODE_AUTO 0
> +#define MT6392_BUCK_MODE_FORCE_PWM 1
> +
> +/*
> + * LDO mode constants which may be used in devicetree properties (eg.
> + * regulator-initial-mode, regulator-allowed-modes).
> + * See the manufacturer's datasheet for more information on these modes.
> + */
> +
> +#define MT6392_LDO_MODE_NORMAL 0
> +#define MT6392_LDO_MODE_LP 1
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Gary Bisson, Louis-Alexis Eyraud,
Julien Massot, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-8-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> The MT6392 is a regulator found on boards based on the MediaTek
> MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
> connects as a slave to a SoC using SPI, wrapped inside PWRAP.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Co-developed-by: Val Packett <val@packett.cool>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/mt6392-regulator.c | 487 +++++++++++++++++++++
> include/linux/regulator/mt6392-regulator.h | 40 ++
> 4 files changed, 537 insertions(+)
> create mode 100644 drivers/regulator/mt6392-regulator.c
> create mode 100644 include/linux/regulator/mt6392-regulator.h
>
..snip..
> +
> +/* The array is indexed by id(MT6392_ID_XXX) */
> +static struct mt6392_regulator_info mt6392_regulators[] = {
> + MT6392_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
s/buck_//g
s/ldo_//g
after which
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v5] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
From: Bjorn Andersson @ 2026-03-18 13:50 UTC (permalink / raw)
To: Kamil Gołda, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Yedaya Katsman
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260208-touchscreen-patches-v5-1-5821dff9c9a2@gmail.com>
On Sun, 08 Feb 2026 23:24:23 +0200, Yedaya Katsman wrote:
> Add device tree node for the Focaltech FT3518 touchscreen on
> Xiaomi Mi A3 (laurel-sprout).
>
> Enable qupv3_id_0 and i2c2 bus that the touchscreen is on.
>
> Downstream references:
> Link: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/laurel-r-oss/arch/arm64/boot/dts/qcom/trinket-pinctrl.dtsi
> Link: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/laurel-r-oss/arch/arm64/boot/dts/qcom/laurel_sprout-qrd.dtsi
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
commit: ea062e42832274cc8fb0587ea8852e1558cef0e1
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: Chen-Yu Tsai @ 2026-03-18 13:54 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Luca Leonardo Scorcia, linux-mediatek, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <c1a425ba-a4ca-49ea-9660-5de74bede124@collabora.com>
On Wed, Mar 18, 2026 at 8:39 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> > From: Val Packett <val@packett.cool>
> >
> > Add the dts to be included by all boards using the MT6392 PMIC.
> >
> > Signed-off-by: Val Packett <val@packett.cool>
> > Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
> > 1 file changed, 141 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > new file mode 100644
> > index 000000000000..fbf6f671524c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > @@ -0,0 +1,141 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 MediaTek Inc.
> > + * Copyright (c) 2024 Val Packett <val@packett.cool>
> > + */
> > +
> > +#include <dt-bindings/input/input.h>
> > +
> > +&pwrap {
> > + pmic: pmic {
> > + compatible = "mediatek,mt6392", "mediatek,mt6323";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > +
> > + keys {
> > + compatible = "mediatek,mt6392-keys";
> > +
> > + key-power {
> > + linux,keycodes = <KEY_POWER>;
> > + wakeup-source;
> > + };
> > +
> > + key-home {
> > + linux,keycodes = <KEY_HOME>;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + pio6392: pinctrl {
> > + compatible = "mediatek,mt6392-pinctrl";
> > +
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + };
> > +
> > + rtc {
> > + compatible = "mediatek,mt6392-rtc",
> > + "mediatek,mt6323-rtc";
> > + };
> > +
> > + regulators {
> > + compatible = "mediatek,mt6392-regulator";
> > +
> > + mt6392_vproc_reg: buck_vproc {
>
> s/buck//g
>
> Also, no min/max voltages?!
We really shouldn't set min/max voltages in the PMIC dtsi file.
The min/max voltages are supposed to be the intersection of the
consumers acceptable operating ranges. The min/max of the regulator
itself is already implied by the model / compatible.
ChenYu
^ permalink raw reply
* Re: [PATCH] Input: sentelic: fix comment typo
From: Joseph Salisbury @ 2026-03-18 16:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <abo7FVLq3qUzxkee@google.com>
On 3/18/26 1:43 AM, Dmitry Torokhov wrote:
> Hi Joseph,
>
> On Mon, Mar 16, 2026 at 07:48:31PM -0400, Joseph Salisbury wrote:
>>
>> On 3/16/26 2:12 PM, Joseph Salisbury wrote:
>>> The file contains a spelling error in a source comment (formating).
>>>
>>> Typos in comments reduce readability and make text searches less reliable
>>> for developers and maintainers.
>>>
>>> Replace 'formating' with 'formatting' in the affected comment. This is a
>>> comment-only cleanup and does not change behavior.
>>>
>>> Fixes: fc69f4a6af49 ("Input: add new driver for Sentelic Finger Sensing Pad")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
>>> ---
>>> drivers/input/mouse/sentelic.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/input/mouse/sentelic.h b/drivers/input/mouse/sentelic.h
>>> index 02cac0e7ad63..9ba3631e3d0f 100644
>>> --- a/drivers/input/mouse/sentelic.h
>>> +++ b/drivers/input/mouse/sentelic.h
>>> @@ -60,7 +60,7 @@
>>> #define FSP_REG_SN1 (0x41)
>>> #define FSP_REG_SN2 (0x42)
>>> -/* Finger-sensing Pad packet formating related definitions */
>>> +/* Finger-sensing Pad packet formatting related definitions */
>>> /* absolute packet type */
>>> #define FSP_PKT_TYPE_NORMAL (0x00)
>> I inadvertently added Fixes: and Cc: stable tags. If possible, please
>> remove them as they are not appropriate for fixes to misspellings in code
>> comments. If it's not possible to remove them, I can send a v2.
>>
> Sorry I did not receive the original patch but even with the typo fixed
> this comment needs more work to improve readability.
>
> Thanks.
>
Thanks for the feedback, Dmitry!
Would you like just improved readability for that line, or would you
like me to add some additional info on the definitions?
How about something like this:
-/* Finger-sensing Pad packet formating related definitions */
+/* Finger Sensing Pad packet format definitions.
+ * Define packet types and bit fields used to decode device reports.
+ */
If that looks good, I'll send a v2.
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: AngeloGioacchino Del Regno @ 2026-03-18 17:22 UTC (permalink / raw)
To: wens
Cc: Luca Leonardo Scorcia, linux-mediatek, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <CAGb2v64+oofwTiJTXDYCuzUEpk=zioi16i8a7iMimc_eZ1RPUQ@mail.gmail.com>
Il 18/03/26 14:54, Chen-Yu Tsai ha scritto:
> On Wed, Mar 18, 2026 at 8:39 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
>>> From: Val Packett <val@packett.cool>
>>>
>>> Add the dts to be included by all boards using the MT6392 PMIC.
>>>
>>> Signed-off-by: Val Packett <val@packett.cool>
>>> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
>>> 1 file changed, 141 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
>>> new file mode 100644
>>> index 000000000000..fbf6f671524c
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
>>> @@ -0,0 +1,141 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (c) 2019 MediaTek Inc.
>>> + * Copyright (c) 2024 Val Packett <val@packett.cool>
>>> + */
>>> +
>>> +#include <dt-bindings/input/input.h>
>>> +
>>> +&pwrap {
>>> + pmic: pmic {
>>> + compatible = "mediatek,mt6392", "mediatek,mt6323";
>>> + interrupt-controller;
>>> + #interrupt-cells = <2>;
>>> +
>>> + keys {
>>> + compatible = "mediatek,mt6392-keys";
>>> +
>>> + key-power {
>>> + linux,keycodes = <KEY_POWER>;
>>> + wakeup-source;
>>> + };
>>> +
>>> + key-home {
>>> + linux,keycodes = <KEY_HOME>;
>>> + wakeup-source;
>>> + };
>>> + };
>>> +
>>> + pio6392: pinctrl {
>>> + compatible = "mediatek,mt6392-pinctrl";
>>> +
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + };
>>> +
>>> + rtc {
>>> + compatible = "mediatek,mt6392-rtc",
>>> + "mediatek,mt6323-rtc";
>>> + };
>>> +
>>> + regulators {
>>> + compatible = "mediatek,mt6392-regulator";
>>> +
>>> + mt6392_vproc_reg: buck_vproc {
>>
>> s/buck//g
>>
>> Also, no min/max voltages?!
>
> We really shouldn't set min/max voltages in the PMIC dtsi file.
>
> The min/max voltages are supposed to be the intersection of the
> consumers acceptable operating ranges. The min/max of the regulator
> itself is already implied by the model / compatible.
>
Your point is fair, but it's also true that some of the regulators are not
really meant to ever output anything different than what they are supposed
to, though, with slight variations being possible... I guess the best option
here is to leave declaring voltages to board DTs instead, which is sensible
in the end.
Okay, agreed. Let's go with no voltages.
Reminder for myself: there's a bunch of PMIC devicetrees to cleanup in here...
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] Remove unused headers in x86/tools, scripts, pps, input
From: Nicolas Schier @ 2026-03-18 19:56 UTC (permalink / raw)
To: Oli
Cc: Thomas Gleixner, Ingo Molnar, Steven Rostedt, Mathieu Desnoyers,
Masami Hiramatsu, Rodolfo Giometti, Henrik Rydberg,
Dmitry Torokhov, Nathan Chancellor, linux-kernel,
linux-trace-kernel, linux-kbuild, linux-input, x86
In-Reply-To: <CAOW84UxjnSDKSjsaaS9=DBquCk3SDfb74=OmkHTLUyq5qriYsA@mail.gmail.com>
Hi Oli,
thanks for your contribution. Some comments below:
On Tue, Mar 10, 2026 at 10:01:41PM -0500, Oli wrote:
> From c78a0572f5ec2b927f9b723af687e6ef913561a4 Mon Sep 17 00:00:00 2001
> From: Eddie Hudgins <Oochiolio@gmail.com>
> Date: Tue, 10 Mar 2026 21:53:07 -0500
> Subject: [PATCH] Signed-off-by: Eddie Hudgins <Oochiolio@gmail.com>
> arch/x86/tools: Removed headers in relocs_32.c scripts/basic: Removed
> headers
> in fixdep.c drivers/pps: Removed headers in pps.c drivers/input: Removed
> headers in input-mt.c
Usually, patch mails do not contain mail headers within their body; the
only possible exception is 'From:' if the sender is not the patch
author. These additional headers prevent the usual patch application
(e.g. 'git am <mail').
>
> These changes compile for x86, x86_64, and powerpc (Those were the only
> ones fairly tested) under defconfig. This aims to clean up code and
> simplify the files for developers. This will also contribute to start of
> decluttering the environment.
A commit subject should start with a subsystem identifier. A commit
message should tell about the what and why of the patch, followed by a
'Signed-of-by'. E.g.:
kbuild: fixdep: Remove unused includes
Remove unused #include statements for clean up.
Signed-off-by: Your Name <your.e.mail@addre.ss>
(More complex changes require more details commit message).
Please check Documentation/process/submitting-patches.rst.
[...]
> diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
> index cdd5da7e009b..feb9e7d8984d 100644
> --- a/scripts/basic/fixdep.c
> +++ b/scripts/basic/fixdep.c
> @@ -89,7 +89,6 @@
> * but I don't think the added complexity is worth it)
> */
>
> -#include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
> #include <fcntl.h>
> --
> 2.43.0
The change in scripts/basic/fixdep.c looks good to me. Do you want to
prepare a new kbuild-only patch and want me to take it for kbuild?
Kind regards,
Nicolas
^ permalink raw reply
* [PATCH] HID: pulsar: add driver for Pulsar gaming mice
From: Nikolas Koesling @ 2026-03-18 20:55 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
Add a HID driver for Pulsar wireless gaming mice (X2 V2, X2H, X2A,
Xlite V3). The driver exposes battery level, voltage, and charging
status through the power supply framework. It supports wired, 1kHz,
and 4kHz wireless dongle connections.
The protocol used by this driver is based on findings from
python-pulsar-mouse-tool by Andrew Rabert (MIT License):
https://github.com/andrewrabert/python-pulsar-mouse-tool
Signed-off-by: Nikolas Koesling <nikolas@koesling.info>
---
MAINTAINERS | 6 +
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 5 +
drivers/hid/hid-pulsar.c | 669 +++++++++++++++++++++++++++++++++++++++
5 files changed, 691 insertions(+)
create mode 100644 drivers/hid/hid-pulsar.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d7241695df96..62e1549ca9fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11339,6 +11339,12 @@ L: linux-input@vger.kernel.org
S: Supported
F: drivers/hid/hid-playstation.c
+HID PULSAR DRIVER
+M: Nikolas Koesling <nikolas@koesling.info>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/hid/hid-pulsar.c
+
HID SENSOR HUB DRIVERS
M: Jiri Kosina <jikos@kernel.org>
M: Jonathan Cameron <jic23@kernel.org>
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index c1d9f7c6a5f2..503287973886 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1280,6 +1280,16 @@ config HID_UNIVERSAL_PIDFF
Supports Moza Racing, Cammus, VRS, FFBeast and more.
+config HID_PULSAR
+ tristate "Pulsar gaming mouse support"
+ depends on USB_HID
+ select POWER_SUPPLY
+ help
+ Support for Pulsar gaming mice (X2 V2, X2H, X2A, Xlite V3)
+ connected via 1kHz/4kHz USB dongle or wired.
+ Provides battery level, voltage, and charging status
+ monitoring via the power supply framework.
+
config HID_WACOM
tristate "Wacom Intuos/Graphire tablet support (USB)"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index e01838239ae6..67ad39b47df1 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -112,6 +112,7 @@ hid-picolcd-$(CONFIG_DEBUG_FS) += hid-picolcd_debugfs.o
obj-$(CONFIG_HID_PLANTRONICS) += hid-plantronics.o
obj-$(CONFIG_HID_PLAYSTATION) += hid-playstation.o
obj-$(CONFIG_HID_PRIMAX) += hid-primax.o
+obj-$(CONFIG_HID_PULSAR) += hid-pulsar.o
obj-$(CONFIG_HID_PXRC) += hid-pxrc.o
obj-$(CONFIG_HID_RAPOO) += hid-rapoo.o
obj-$(CONFIG_HID_RAZER) += hid-razer.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index afcee13bad61..18d461247aed 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1169,6 +1169,11 @@
#define USB_VENDOR_ID_PRODIGE 0x05af
#define USB_DEVICE_ID_PRODIGE_CORDLESS 0x3062
+#define USB_VENDOR_ID_PULSAR 0x3554
+#define USB_DEVICE_ID_PULSAR_WIRED 0xf507
+#define USB_DEVICE_ID_PULSAR_1KHZ 0xf508
+#define USB_DEVICE_ID_PULSAR_4KHZ 0xf509
+
#define I2C_VENDOR_ID_QTEC 0x6243
#define USB_VENDOR_ID_QUANTA 0x0408
diff --git a/drivers/hid/hid-pulsar.c b/drivers/hid/hid-pulsar.c
new file mode 100644
index 000000000000..2720b9f18b08
--- /dev/null
+++ b/drivers/hid/hid-pulsar.c
@@ -0,0 +1,669 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HID driver for pulsar mice
+ *
+ * Supported pulsar devices:
+ * - X2 V2
+ * - X2H
+ * - X2A
+ * - Xlite V3
+ *
+ * Copyright (c) 2026 Nikolas Koesling
+ */
+
+#include <linux/hid.h>
+#include <linux/usb.h>
+#include <linux/power_supply.h>
+#include "hid-ids.h"
+
+/* ----- driver settings ----- */
+#define CMD_TIMEOUT_MSEC 100
+#define MAX_BATTERY_AGE_NS 60000000000ULL /* 60s */
+#define MAX_UNAVAIL_AGE_NS 5000000000ULL /* 5s */
+#define INIT_RETRIES 1
+#define INIT_DELAY_MSEC 1000
+
+/* ----- constants ----- */
+#define USB_INTERFACE 1
+#define USB_PAYLOAD_LEN 17
+#define CMD_HID_REPORT_ID 0x08
+#define CHECKSUM_MAGIC 0x55
+#define DEV_INFO_LEN 4
+#define CON_1K 0x00
+#define CON_4K 0x01
+#define CON_WIRED 0x02
+
+/* ----- device commands ----- */
+enum pulsar_cmd {
+ CMD_NONE = 0,
+ CMD_INFO = 0x01,
+ CMD_STATUS = 0x03,
+ CMD_POWER = 0x04,
+ CMD_EVENT = 0x0a, /* recv only */
+};
+
+#define EVENT_PWR 0x40 /* power status change */
+#define EVENT_PWR_CHK 0xf9
+
+/* ----- structs ----- */
+struct pulsar_battery {
+ struct power_supply *ps;
+ struct power_supply_desc desc;
+ char name[48];
+ char model[32];
+ u8 level; /* percent */
+ u16 voltage; /* millivolts */
+ bool conn;
+ bool available;
+ u64 last_read;
+ u64 last_status;
+};
+
+struct pulsar_data {
+ struct hid_device *hdev;
+
+ spinlock_t raw_event_lock; /* protects response_buf, pending_event */
+ struct mutex lock_cmd; /* serializes device command execution */
+ struct rw_semaphore lock_bat; /* protects battery state */
+
+ struct completion response_ready;
+ u8 response_buf[USB_PAYLOAD_LEN];
+ u8 pending_event;
+ struct work_struct power_uevent_work;
+ struct delayed_work init_work;
+ unsigned int init_retries;
+ atomic_t device_verified;
+ atomic_t stopping;
+
+ struct pulsar_battery battery;
+};
+
+static u8 calc_checksum(const u8 *data, size_t len)
+{
+ u8 sum = 0;
+
+ for (size_t i = 0; i < len - 1; i++)
+ sum += data[i];
+
+ return (u8)CHECKSUM_MAGIC - sum;
+}
+
+static int send_cmd(struct hid_device *hdev, const u8 *buf, size_t len)
+{
+ int ret;
+ u8 *dmabuf;
+
+ hid_dbg(hdev, "send command: %*ph\n", (int)len, buf);
+
+ dmabuf = kmemdup(buf, len, GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ /* device listens only to control transfers */
+ ret = hid_hw_raw_request(hdev, dmabuf[0], dmabuf, len,
+ HID_OUTPUT_REPORT, HID_REQ_SET_REPORT);
+
+ kfree(dmabuf);
+
+ if (ret < 0)
+ return ret;
+ if (ret != len)
+ return -EIO;
+
+ return 0;
+}
+
+static int exec_cmd(struct pulsar_data *drvdata, const u8 *payload,
+ u8 *response, unsigned int timeout_msec)
+{
+ struct hid_device *hdev = drvdata->hdev;
+ unsigned long flags;
+ int ret;
+ unsigned long timeout;
+ u8 checksum;
+
+ if (atomic_read(&drvdata->stopping))
+ return -ENODEV;
+
+ mutex_lock(&drvdata->lock_cmd);
+
+ if (atomic_read(&drvdata->stopping)) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ reinit_completion(&drvdata->response_ready);
+ drvdata->pending_event = payload[1];
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+
+ ret = send_cmd(hdev, payload, USB_PAYLOAD_LEN);
+
+ if (ret < 0) {
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ drvdata->pending_event = CMD_NONE;
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+ hid_err(hdev, "failed to send command 0x%02x: %d\n",
+ payload[1], ret);
+ goto out;
+ }
+
+ timeout = wait_for_completion_timeout(&drvdata->response_ready,
+ msecs_to_jiffies(timeout_msec));
+
+ if (timeout == 0) {
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ drvdata->pending_event = CMD_NONE;
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ memcpy(response, drvdata->response_buf, USB_PAYLOAD_LEN);
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+
+ /* validate checksum */
+ checksum = calc_checksum(response, USB_PAYLOAD_LEN);
+
+ if (response[USB_PAYLOAD_LEN - 1] != checksum) {
+ hid_err(hdev,
+ "invalid checksum in response: 0x%02x (expected 0x%02x)\n",
+ response[USB_PAYLOAD_LEN - 1], checksum);
+ ret = -EIO;
+ goto out;
+ }
+
+ ret = 0;
+out:
+ mutex_unlock(&drvdata->lock_cmd);
+ return ret;
+}
+
+static inline void finalize_payload(u8 *payload, u8 cmd)
+{
+ payload[0] = CMD_HID_REPORT_ID;
+ payload[1] = cmd;
+ payload[USB_PAYLOAD_LEN - 1] = calc_checksum(payload, USB_PAYLOAD_LEN);
+}
+
+static int read_status(struct pulsar_data *drvdata)
+{
+ int ret;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+
+ finalize_payload(payload, CMD_STATUS);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0)
+ return ret;
+ if (response[6] > 0x01)
+ return -EIO;
+
+ return (int)response[6]; /* 1: available, 0: not available */
+}
+
+static int read_device_info(struct pulsar_data *drvdata, u8 *data)
+{
+ int ret;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+
+ payload[5] = DEV_INFO_LEN * 2;
+ get_random_bytes(payload + 6, DEV_INFO_LEN);
+ finalize_payload(payload, CMD_INFO);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0)
+ return ret;
+
+ if (data)
+ memcpy(data, response + 6 + DEV_INFO_LEN, DEV_INFO_LEN);
+
+ response[8 + DEV_INFO_LEN] = 0;
+ response[9 + DEV_INFO_LEN] = 0;
+
+ /*
+ * Verify challenge-response. Response layout from offset 6:
+ * [0..3] encoded response [4..7] device info (ID + conn type)
+ *
+ * resp[i] = challenge[i] * (i+1) + challenge[(i+1) % 4] + device_id[i]
+ *
+ * bytes 6..7 are zeroed for verification.
+ */
+ for (int i = 0; i < DEV_INFO_LEN; i++) {
+ u8 expect = response[6 + DEV_INFO_LEN + i];
+ u8 actual = response[6 + i] - (i + 1) * payload[6 + i] -
+ payload[6 + (i + 1) % DEV_INFO_LEN];
+
+ if (expect != actual) {
+ hid_warn(drvdata->hdev,
+ "device info[%d] mismatch: %02x != %02x\n",
+ i, expect, actual);
+ return -EIO;
+ }
+ }
+
+ return 0;
+}
+
+static int read_power(struct pulsar_data *drvdata)
+{
+ u64 now;
+ bool need_status, need_power;
+ int ret = 0;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+ struct pulsar_battery *battery = &drvdata->battery;
+
+ now = ktime_get_ns();
+
+ down_write(&drvdata->lock_bat);
+
+ need_status = (now - battery->last_status >= MAX_UNAVAIL_AGE_NS);
+ need_power = battery->available &&
+ (now - battery->last_read >= MAX_BATTERY_AGE_NS);
+
+ if (!need_status && !need_power)
+ goto unlock;
+
+ if (need_status) {
+ ret = read_status(drvdata);
+ if (ret < 0) {
+ hid_err(drvdata->hdev,
+ "%s: failed to read status: %d\n",
+ __func__, ret);
+ goto unlock;
+ }
+
+ battery->last_status = now;
+
+ if (!ret) {
+ battery->available = false;
+ goto unlock;
+ }
+
+ /* device just became available, force power read */
+ if (!battery->available)
+ need_power = true;
+ }
+
+ if (!need_power)
+ goto unlock;
+
+ finalize_payload(payload, CMD_POWER);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0) {
+ hid_err(drvdata->hdev, "%s: failed to read power: %d\n",
+ __func__, ret);
+ goto unlock;
+ }
+
+ if (response[6] > 100 || response[7] > 0x01) {
+ ret = -EIO;
+ goto unlock;
+ }
+
+ battery->available = true;
+ battery->level = response[6];
+ battery->conn = response[7] == 1;
+ battery->voltage = (response[8] << 8) | response[9];
+ battery->last_read = now;
+
+ hid_dbg(drvdata->hdev, "%s: level=%d, conn=%d, voltage=%d\n",
+ __func__, battery->level, battery->conn, battery->voltage);
+
+unlock:
+ up_write(&drvdata->lock_bat);
+ return ret;
+}
+
+static int battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct pulsar_data *drvdata;
+ int ret;
+
+ drvdata = power_supply_get_drvdata(psy);
+
+ ret = read_power(drvdata);
+ if (ret)
+ return ret;
+
+ down_read(&drvdata->lock_bat);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ if (!drvdata->battery.available)
+ val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+ else if (drvdata->battery.conn && drvdata->battery.level < 100)
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else if (drvdata->battery.conn && drvdata->battery.level >= 100)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = drvdata->battery.level;
+ break;
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ val->intval = drvdata->battery.voltage * 1000;
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = drvdata->battery.available;
+ break;
+ case POWER_SUPPLY_PROP_MANUFACTURER:
+ val->strval = "pulsar";
+ break;
+ case POWER_SUPPLY_PROP_SCOPE:
+ val->intval = POWER_SUPPLY_SCOPE_DEVICE;
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = drvdata->battery.model;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ up_read(&drvdata->lock_bat);
+ return ret;
+}
+
+static void power_uevent_work_handler(struct work_struct *work)
+{
+ struct pulsar_data *drvdata;
+ int ret;
+
+ drvdata = container_of(work, struct pulsar_data, power_uevent_work);
+
+ if (atomic_read(&drvdata->stopping))
+ return;
+
+ down_write(&drvdata->lock_bat);
+ drvdata->battery.last_read = 0;
+ drvdata->battery.last_status = 0;
+ up_write(&drvdata->lock_bat);
+
+ ret = read_power(drvdata);
+ if (ret < 0) {
+ hid_err(drvdata->hdev, "%s: failed to read power: %d\n",
+ __func__, ret);
+ return;
+ }
+
+ power_supply_changed(drvdata->battery.ps);
+}
+
+static int pulsar_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ struct pulsar_data *drvdata;
+
+ drvdata = hid_get_drvdata(hdev);
+ if (!drvdata)
+ return 0;
+
+ hid_dbg(hdev, "received raw event: %*ph\n", size, data);
+
+ if (size != USB_PAYLOAD_LEN || data[0] != CMD_HID_REPORT_ID)
+ return 0;
+
+ if (data[1] != CMD_EVENT) {
+ spin_lock(&drvdata->raw_event_lock);
+ if (drvdata->pending_event != data[1]) {
+ spin_unlock(&drvdata->raw_event_lock);
+ return 0;
+ }
+ memcpy(drvdata->response_buf, data, size);
+ drvdata->pending_event = CMD_NONE;
+ complete(&drvdata->response_ready);
+ spin_unlock(&drvdata->raw_event_lock);
+ return 1;
+ }
+
+ if (!atomic_read(&drvdata->device_verified))
+ return 0;
+
+ if (data[6] == EVENT_PWR && data[USB_PAYLOAD_LEN - 1] == EVENT_PWR_CHK) {
+ schedule_work(&drvdata->power_uevent_work);
+ hid_dbg(hdev, "received power event\n");
+ return 1;
+ }
+
+ return 0;
+}
+
+static const enum power_supply_property pulsar_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS, POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW, POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_MODEL_NAME, POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_MANUFACTURER, POWER_SUPPLY_PROP_PRESENT
+};
+
+static void init_power_supply_desc(struct pulsar_data *drvdata)
+{
+ drvdata->battery.desc.name = drvdata->battery.name;
+ drvdata->battery.desc.type = POWER_SUPPLY_TYPE_BATTERY;
+ drvdata->battery.desc.properties = pulsar_battery_props;
+ drvdata->battery.desc.num_properties = ARRAY_SIZE(pulsar_battery_props);
+ drvdata->battery.desc.get_property = battery_get_property;
+}
+
+static void pulsar_init_work(struct work_struct *work)
+{
+ struct pulsar_data *drvdata;
+ struct hid_device *hdev;
+ struct power_supply_config psy_cfg;
+ int ret;
+ u8 data[DEV_INFO_LEN];
+ const char *con_type = "unknown";
+ u16 model_id;
+
+ drvdata = container_of(work, struct pulsar_data, init_work.work);
+ hdev = drvdata->hdev;
+
+ ret = read_device_info(drvdata, data);
+ if (ret == -ETIMEDOUT) {
+ if (drvdata->init_retries--) {
+ hid_dbg(hdev,
+ "device info read timed out, retrying (%u left)\n",
+ drvdata->init_retries);
+ schedule_delayed_work(&drvdata->init_work,
+ msecs_to_jiffies
+ (INIT_DELAY_MSEC));
+ return;
+ }
+ hid_err(hdev, "device info read timed out, giving up\n");
+ return;
+ }
+ if (ret < 0) {
+ hid_err(hdev, "failed to read device info: %d\n", ret);
+ return;
+ }
+
+ hid_dbg(hdev, "device info: %*ph\n", DEV_INFO_LEN, data);
+ model_id = data[0] << 8 | data[1];
+
+ switch (data[2]) {
+ case CON_1K:
+ con_type = "1kHz";
+ break;
+ case CON_4K:
+ con_type = "4kHz";
+ break;
+ case CON_WIRED:
+ con_type = "wired";
+ break;
+ }
+
+ switch (model_id) {
+ case 0x060a:
+ case 0x060b:
+ case 0x0612:
+ case 0x0613:
+ case 0x0614:
+ case 0x0615:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2 V2 (%s)", con_type);
+ break;
+ case 0x060c:
+ case 0x060d:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2H (%s)", con_type);
+ break;
+ case 0x0607:
+ case 0x060e:
+ case 0x060f:
+ case 0x0610:
+ case 0x0611:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar Xlite V3 (%s)", con_type);
+ break;
+ case 0x0608:
+ case 0x0609:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2A (%s)", con_type);
+ break;
+ default:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar unknown (%s)", con_type);
+ }
+
+ init_power_supply_desc(drvdata);
+
+ psy_cfg = (struct power_supply_config) {.drv_data = drvdata };
+ drvdata->battery.ps =
+ devm_power_supply_register(&hdev->dev, &drvdata->battery.desc,
+ &psy_cfg);
+ if (IS_ERR(drvdata->battery.ps)) {
+ hid_err(hdev, "failed to register battery: %ld\n",
+ PTR_ERR(drvdata->battery.ps));
+ drvdata->battery.ps = NULL;
+ return;
+ }
+
+ atomic_set(&drvdata->device_verified, 1);
+ hid_info(hdev, "device verified, battery registered\n");
+}
+
+static int pulsar_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+ struct usb_interface *intf;
+ struct usb_device *usbdev;
+ struct pulsar_data *drvdata;
+ struct hid_report *report_in;
+ struct hid_report *report_out;
+
+ if (!hid_is_usb(hdev))
+ return -ENODEV;
+
+ ret = hid_parse(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hid_parse failed: %d\n", ret);
+ return ret;
+ }
+
+ intf = to_usb_interface(hdev->dev.parent);
+ report_in =
+ hdev->report_enum[HID_INPUT_REPORT].report_id_hash[CMD_HID_REPORT_ID];
+ report_out =
+ hdev->report_enum[HID_OUTPUT_REPORT].report_id_hash[CMD_HID_REPORT_ID];
+
+ if (!report_in || !report_out ||
+ hid_report_len(report_in) != USB_PAYLOAD_LEN ||
+ hid_report_len(report_out) != USB_PAYLOAD_LEN ||
+ intf->cur_altsetting->desc.bInterfaceNumber != USB_INTERFACE)
+ return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+
+ drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->hdev = hdev;
+
+ mutex_init(&drvdata->lock_cmd);
+ init_rwsem(&drvdata->lock_bat);
+
+ usbdev = interface_to_usbdev(intf);
+
+ spin_lock_init(&drvdata->raw_event_lock);
+ hid_set_drvdata(hdev, drvdata);
+ init_completion(&drvdata->response_ready);
+ INIT_WORK(&drvdata->power_uevent_work, power_uevent_work_handler);
+ INIT_DELAYED_WORK(&drvdata->init_work, pulsar_init_work);
+ drvdata->init_retries = INIT_RETRIES;
+
+ snprintf(drvdata->battery.name, sizeof(drvdata->battery.name),
+ "pulsar_%s_battery", usbdev->devpath);
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret < 0) {
+ hid_err(hdev, "hw start failed\n");
+ return ret;
+ }
+
+ ret = hid_hw_open(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hw open failed\n");
+ goto err_open;
+ }
+
+ schedule_delayed_work(&drvdata->init_work, 0);
+
+ return 0;
+
+err_open:
+ cancel_work_sync(&drvdata->power_uevent_work);
+ hid_hw_stop(hdev);
+ return ret;
+}
+
+static void pulsar_remove(struct hid_device *hdev)
+{
+ struct pulsar_data *drvdata;
+
+ drvdata = hid_get_drvdata(hdev);
+ if (!drvdata) {
+ hid_hw_stop(hdev);
+ return;
+ }
+
+ atomic_set(&drvdata->stopping, 1);
+ cancel_delayed_work_sync(&drvdata->init_work);
+ cancel_work_sync(&drvdata->power_uevent_work);
+
+ /* wait for active device i/o (exec_cmd) */
+ mutex_lock(&drvdata->lock_cmd);
+ hid_hw_close(hdev);
+ mutex_unlock(&drvdata->lock_cmd);
+
+ hid_hw_stop(hdev);
+ mutex_destroy(&drvdata->lock_cmd);
+}
+
+static const struct hid_device_id pulsar_table[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_WIRED) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_1KHZ) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_4KHZ) },
+ { }
+};
+
+static struct hid_driver pulsar_driver = {
+ .name = "pulsar",
+ .id_table = pulsar_table,
+ .probe = pulsar_probe,
+ .remove = pulsar_remove,
+ .raw_event = pulsar_raw_event,
+};
+
+module_hid_driver(pulsar_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("HID driver for pulsar mice");
+MODULE_AUTHOR("Nikolas Koesling");
+MODULE_DEVICE_TABLE(hid, pulsar_table);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Luca Leonardo Scorcia @ 2026-03-18 21:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260318-nickel-serval-of-tolerance-621bad@quoll>
Il giorno mer 18 mar 2026 alle ore 08:43 Krzysztof Kozlowski
<krzk@kernel.org> ha scritto:
> Please use subject prefixes matching the subsystem. You can get them for
> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> You already received this feedback from Mark.
I am sorry I missed these. I will revise all of them in the next version.
> > +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
[...]
> > +properties:
> > + compatible:
> > + items:
> > + - const: mediatek,mt6392-regulator
>
> Drop compatible. Regulator nodes do not have compatibles.
Thanks for this comment. It took me a while to understand what you
meant as most of the MediaTek PMIC regulator drivers still require the
compatible node to probe, including MT6397 that was the template for
this patch. I compared the driver to MT6359 that does not use it and I
am now working on the driver to not rely on it.
> With this, you can also drop example as it won't be used.
Just to be sure - do you mean remove the compatible attribute from the
example, or the whole example section?
> > +
> > +patternProperties:
> > + "^(buck_)?v(core|proc|sys)$":
>
> Nope, underscores are not allowed. Use only hyphens.
Got it. I will actually completely remove the (buck_|ldo_) prefix
altogether as suggested in another comment.
> > + "^(ldo_)?v(adc18|camio|cn18|io18)$":
> > + description: LDOs with fixed 1.8V output
>
> If fixed, then encode it in the schema - min/max microvolt.
If possible I'd like some clarification here. According to Chen-Yu
Tsai comment [1], dtsi shouldn't contain voltage constraints. The way
I understood this is that electrical constraints are a matter of the
actual board layout, so if adjustments are needed they have to be in
the board dts. But you also specify "If fixed", so maybe there's an
exception to this rule when the constraint is "absolute" and boards
can't actually set a different value?
[1] https://lore.kernel.org/linux-mediatek/28102417-4a2a-4e29-afbd-d0f2aa76074b@collabora.com/T/#mb1473bb5515f3e5a1bb3ff20c717b387c42373ef
Thank you for your help!
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Krzysztof Kozlowski @ 2026-03-18 22:14 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <CAORyz2Laoo4EiLcHZ-ygLiFGW_h8qV7QxqNsMbueM=nov5zH0A@mail.gmail.com>
On 18/03/2026 22:25, Luca Leonardo Scorcia wrote:
>>
>> Drop compatible. Regulator nodes do not have compatibles.
>
> Thanks for this comment. It took me a while to understand what you
> meant as most of the MediaTek PMIC regulator drivers still require the
> compatible node to probe, including MT6397 that was the template for
> this patch. I compared the driver to MT6359 that does not use it and I
> am now working on the driver to not rely on it.
>
>> With this, you can also drop example as it won't be used.
>
> Just to be sure - do you mean remove the compatible attribute from the
> example, or the whole example section?
The entire example because without the compatible it will be no-op.
>
>>> +
>>> +patternProperties:
>>> + "^(buck_)?v(core|proc|sys)$":
>>
>> Nope, underscores are not allowed. Use only hyphens.
>
> Got it. I will actually completely remove the (buck_|ldo_) prefix
> altogether as suggested in another comment.
>
>>> + "^(ldo_)?v(adc18|camio|cn18|io18)$":
>>> + description: LDOs with fixed 1.8V output
>>
>> If fixed, then encode it in the schema - min/max microvolt.
>
> If possible I'd like some clarification here. According to Chen-Yu
> Tsai comment [1], dtsi shouldn't contain voltage constraints. The way
That's odd, because long time in the past I heard that DTS must
absolutely set min/max constraints, because these are real hardware
(board) constraints for each regulator, unlike the generic and broad
ones from the driver.
IOW, driver has what datasheet tells. DTS has what actually should be used.
Also, I did not actually require to make min/max required, just they
have to be specific/constrained.
> I understood this is that electrical constraints are a matter of the
> actual board layout, so if adjustments are needed they have to be in
> the board dts. But you also specify "If fixed", so maybe there's an
> exception to this rule when the constraint is "absolute" and boards
> can't actually set a different value?
Now I am confused. You wrote - LDOs with fixed 1.8V output - so board
cannot set it to 2.0V for example. They are affixed. This regulator
CANNOT physically produce anything else.
At least this is the meaning of the text you wrote.
Best regards,
Krzysztof
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS b8303880b641fa12db4e752b19f1b5160f0fa965
From: kernel test robot @ 2026-03-19 4:21 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: b8303880b641fa12db4e752b19f1b5160f0fa965 Input: atlas - convert ACPI driver to a platform one
elapsed time: 733m
configs tested: 163
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260319 gcc-11.5.0
arc randconfig-002-20260319 gcc-11.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260319 gcc-11.5.0
arm randconfig-002-20260319 gcc-11.5.0
arm randconfig-003-20260319 gcc-11.5.0
arm randconfig-004-20260319 gcc-11.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260319 gcc-15.2.0
arm64 randconfig-002-20260319 gcc-15.2.0
arm64 randconfig-003-20260319 gcc-15.2.0
arm64 randconfig-004-20260319 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260319 gcc-15.2.0
csky randconfig-002-20260319 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260319 gcc-11.5.0
hexagon randconfig-002-20260319 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260319 gcc-14
i386 buildonly-randconfig-002-20260319 gcc-14
i386 buildonly-randconfig-003-20260319 gcc-14
i386 buildonly-randconfig-004-20260319 gcc-14
i386 buildonly-randconfig-005-20260319 gcc-14
i386 buildonly-randconfig-006-20260319 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260319 gcc-14
i386 randconfig-002-20260319 gcc-14
i386 randconfig-003-20260319 gcc-14
i386 randconfig-004-20260319 gcc-14
i386 randconfig-005-20260319 gcc-14
i386 randconfig-006-20260319 gcc-14
i386 randconfig-007-20260319 gcc-14
i386 randconfig-011-20260319 clang-20
i386 randconfig-012-20260319 clang-20
i386 randconfig-013-20260319 clang-20
i386 randconfig-014-20260319 clang-20
i386 randconfig-015-20260319 clang-20
i386 randconfig-016-20260319 clang-20
i386 randconfig-017-20260319 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260319 gcc-11.5.0
loongarch randconfig-002-20260319 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
m68k mac_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260319 gcc-11.5.0
nios2 randconfig-002-20260319 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260319 clang-19
parisc randconfig-002-20260319 clang-19
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc chrp32_defconfig clang-19
powerpc randconfig-001-20260319 clang-19
powerpc randconfig-002-20260319 clang-19
powerpc64 randconfig-001-20260319 clang-19
powerpc64 randconfig-002-20260319 clang-19
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260319 gcc-8.5.0
sparc randconfig-002-20260319 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260319 gcc-8.5.0
sparc64 randconfig-002-20260319 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260319 gcc-8.5.0
um randconfig-002-20260319 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260319 clang-20
x86_64 buildonly-randconfig-002-20260319 clang-20
x86_64 buildonly-randconfig-003-20260319 clang-20
x86_64 buildonly-randconfig-004-20260319 clang-20
x86_64 buildonly-randconfig-005-20260319 clang-20
x86_64 buildonly-randconfig-006-20260319 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260319 gcc-14
x86_64 randconfig-002-20260319 gcc-14
x86_64 randconfig-003-20260319 gcc-14
x86_64 randconfig-004-20260319 gcc-14
x86_64 randconfig-005-20260319 gcc-14
x86_64 randconfig-006-20260319 gcc-14
x86_64 randconfig-011-20260319 gcc-13
x86_64 randconfig-012-20260319 gcc-13
x86_64 randconfig-013-20260319 gcc-13
x86_64 randconfig-014-20260319 gcc-13
x86_64 randconfig-015-20260319 gcc-13
x86_64 randconfig-016-20260319 gcc-13
x86_64 randconfig-071-20260319 clang-20
x86_64 randconfig-072-20260319 clang-20
x86_64 randconfig-073-20260319 clang-20
x86_64 randconfig-074-20260319 clang-20
x86_64 randconfig-075-20260319 clang-20
x86_64 randconfig-076-20260319 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260319 gcc-8.5.0
xtensa randconfig-002-20260319 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Chen-Yu Tsai @ 2026-03-19 4:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Luca Leonardo Scorcia, linux-mediatek, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Julien Massot, Gary Bisson, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <ad0d1ea1-4c5d-4cfc-af0d-8d843e7e0e9e@kernel.org>
On Thu, Mar 19, 2026 at 6:14 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 18/03/2026 22:25, Luca Leonardo Scorcia wrote:
> >>
> >> Drop compatible. Regulator nodes do not have compatibles.
> >
> > Thanks for this comment. It took me a while to understand what you
> > meant as most of the MediaTek PMIC regulator drivers still require the
> > compatible node to probe, including MT6397 that was the template for
> > this patch. I compared the driver to MT6359 that does not use it and I
> > am now working on the driver to not rely on it.
> >
> >> With this, you can also drop example as it won't be used.
> >
> > Just to be sure - do you mean remove the compatible attribute from the
> > example, or the whole example section?
>
> The entire example because without the compatible it will be no-op.
>
> >
> >>> +
> >>> +patternProperties:
> >>> + "^(buck_)?v(core|proc|sys)$":
> >>
> >> Nope, underscores are not allowed. Use only hyphens.
> >
> > Got it. I will actually completely remove the (buck_|ldo_) prefix
> > altogether as suggested in another comment.
> >
> >>> + "^(ldo_)?v(adc18|camio|cn18|io18)$":
> >>> + description: LDOs with fixed 1.8V output
> >>
> >> If fixed, then encode it in the schema - min/max microvolt.
> >
> > If possible I'd like some clarification here. According to Chen-Yu
> > Tsai comment [1], dtsi shouldn't contain voltage constraints. The way
>
> That's odd, because long time in the past I heard that DTS must
> absolutely set min/max constraints, because these are real hardware
> (board) constraints for each regulator, unlike the generic and broad
> ones from the driver.
>
> IOW, driver has what datasheet tells. DTS has what actually should be used.
>
> Also, I did not actually require to make min/max required, just they
> have to be specific/constrained.
>
> > I understood this is that electrical constraints are a matter of the
> > actual board layout, so if adjustments are needed they have to be in
> > the board dts. But you also specify "If fixed", so maybe there's an
> > exception to this rule when the constraint is "absolute" and boards
> > can't actually set a different value?
>
> Now I am confused. You wrote - LDOs with fixed 1.8V output - so board
> cannot set it to 2.0V for example. They are affixed. This regulator
> CANNOT physically produce anything else.
As you said, it cannot physically produce anything else. IMO it doesn't
even need voltage constraints as it is already implied by the model and
regulator output, in which case I would actually recommend rejecting
min/max voltage being added to this node.
ChenYu
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Chen-Yu Tsai @ 2026-03-19 4:56 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260317184507.523060-4-l.scorcia@gmail.com>
On Wed, Mar 18, 2026 at 2:46 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 318 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 342 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..fa4aad2dcbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,318 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 Regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + All voltage regulators provided by the PMIC are described as sub-nodes of
> + this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
Please add the various supply rails. This allows you to properly describe
regulator dependencies and have a complete power supply tree.
They can be found in the datasheet.
ChenYu
^ permalink raw reply
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: Chen-Yu Tsai @ 2026-03-19 5:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Louis-Alexis Eyraud, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-8-l.scorcia@gmail.com>
On Wed, Mar 18, 2026 at 2:46 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> From: Fabien Parent <parent.f@gmail.com>
>
> The MT6392 is a regulator found on boards based on the MediaTek
> MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
> connects as a slave to a SoC using SPI, wrapped inside PWRAP.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Co-developed-by: Val Packett <val@packett.cool>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/mt6392-regulator.c | 487 +++++++++++++++++++++
> include/linux/regulator/mt6392-regulator.h | 40 ++
> 4 files changed, 537 insertions(+)
> create mode 100644 drivers/regulator/mt6392-regulator.c
> create mode 100644 include/linux/regulator/mt6392-regulator.h
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index d2335276cce5..66876d730807 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -991,6 +991,15 @@ config REGULATOR_MT6380
> This driver supports the control of different power rails of device
> through regulator interface.
>
> +config REGULATOR_MT6392
> + tristate "MediaTek MT6392 PMIC"
> + depends on MFD_MT6397
> + help
> + Say y here to select this option to enable the power regulator of
> + MediaTek MT6392 PMIC.
> + This driver supports the control of different power rails of device
> + through regulator interface.
> +
> config REGULATOR_MT6397
> tristate "MediaTek MT6397 PMIC"
> depends on MFD_MT6397
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 1beba1493241..db5145cfcf36 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -117,6 +117,7 @@ obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
> obj-$(CONFIG_REGULATOR_MT6363) += mt6363-regulator.o
> obj-$(CONFIG_REGULATOR_MT6370) += mt6370-regulator.o
> obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
> +obj-$(CONFIG_REGULATOR_MT6392) += mt6392-regulator.o
> obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
> obj-$(CONFIG_REGULATOR_MTK_DVFSRC) += mtk-dvfsrc-regulator.o
> obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
> diff --git a/drivers/regulator/mt6392-regulator.c b/drivers/regulator/mt6392-regulator.c
> new file mode 100644
> index 000000000000..50cc0019f48a
> --- /dev/null
> +++ b/drivers/regulator/mt6392-regulator.c
> @@ -0,0 +1,487 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +// Copyright (c) 2020 BayLibre, SAS.
> +// Author: Chen Zhong <chen.zhong@mediatek.com>
> +// Author: Fabien Parent <fparent@baylibre.com>
> +//
> +// Based on mt6397-regulator.c
> +
> +#include <linux/module.h>
> +#include <linux/linear_range.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/mt6397/core.h>
> +#include <linux/mfd/mt6392/registers.h>
> +#include <linux/regulator/driver.h>
> +#include <linux/regulator/machine.h>
> +#include <linux/regulator/mt6392-regulator.h>
> +#include <linux/regulator/of_regulator.h>
> +#include <dt-bindings/regulator/mediatek,mt6392-regulator.h>
> +
> +/*
> + * MT6392 regulators' information
> + *
> + * @desc: standard fields of regulator description.
> + * @qi: Mask for query enable signal status of regulators
> + * @vselon_reg: Register sections for hardware control mode of bucks
> + * @vselctrl_reg: Register for controlling the buck control mode.
> + * @vselctrl_mask: Mask for query buck's voltage control mode.
> + */
> +struct mt6392_regulator_info {
> + struct regulator_desc desc;
> + u32 qi;
> + u32 vselon_reg;
> + u32 vselctrl_reg;
> + u32 vselctrl_mask;
> + u32 modeset_reg;
> + u32 modeset_mask;
> +};
> +
> +#define MT6392_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \
> + vosel, vosel_mask, voselon, vosel_ctrl, \
> + _modeset_reg, _modeset_mask, rampdelay) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_range_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = ((max) - (min)) / (step) + 1, \
> + .linear_ranges = volt_ranges, \
> + .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
> + .vsel_reg = vosel, \
> + .vsel_mask = vosel_mask, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(0), \
> + .ramp_delay = rampdelay, \
Please add the supply names.
> + }, \
> + .qi = BIT(13), \
> + .vselon_reg = voselon, \
> + .vselctrl_reg = vosel_ctrl, \
> + .vselctrl_mask = BIT(1), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel, \
> + vosel_mask, _modeset_reg, _modeset_mask, entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_table_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = ARRAY_SIZE(ldo_volt_table), \
> + .volt_table = ldo_volt_table, \
> + .vsel_reg = vosel, \
> + .vsel_mask = vosel_mask, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + }, \
> + .qi = BIT(15), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_LDO_LINEAR(match, vreg, min, max, step, volt_ranges, \
> + enreg, enbit, vosel, vosel_mask, _modeset_reg, \
> + _modeset_mask, entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_ldo_range_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = ((max) - (min)) / (step) + 1, \
> + .linear_ranges = volt_ranges, \
> + .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
> + .vsel_reg = vosel, \
> + .vsel_mask = vosel_mask, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + }, \
> + .qi = BIT(15), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_REG_FIXED(match, vreg, enreg, enbit, volt, \
> + _modeset_reg, _modeset_mask, entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_fixed_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = 1, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + .min_uV = volt, \
> + }, \
> + .qi = BIT(15), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_REG_FIXED_NO_MODE(match, vreg, enreg, enbit, volt, \
> + entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_fixed_no_mode_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = 1, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + .min_uV = volt, \
> + }, \
> + .qi = BIT(15), \
> +}
> +
> +static const struct linear_range buck_volt_range1[] = {
> + REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
> +};
> +
> +static const struct linear_range buck_volt_range2[] = {
> + REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
> +};
> +
> +static const u32 ldo_volt_table1[] = {
> + 1800000, 1900000, 2000000, 2200000,
> +};
> +
> +static const struct linear_range ldo_volt_range2[] = {
> + REGULATOR_LINEAR_RANGE(3300000, 0, 3, 100000),
> +};
> +
> +static const u32 ldo_volt_table3[] = {
> + 1800000, 3300000,
> +};
> +
> +static const u32 ldo_volt_table4[] = {
> + 3000000, 3300000,
> +};
> +
> +static const u32 ldo_volt_table5[] = {
> + 1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
> +};
> +
> +static const u32 ldo_volt_table6[] = {
> + 1240000, 1390000,
> +};
> +
> +static const u32 ldo_volt_table7[] = {
> + 1200000, 1300000, 1500000, 1800000,
> +};
> +
> +static const u32 ldo_volt_table8[] = {
> + 1800000, 2000000,
> +};
If this PMIC is anything like the MT6358, then it has 0.01V fine
tuning for most if not all the LDOs. It is sometimes needed as
a rail may have a 0.04V boost that would otherwise be invisible
to the system. And then if you have something like 3.04V set in
the DT constraints, you end up with something the regulator driver
doesn't support, but the hardware does.
Please see how it's done in the MT6358 driver. I spent a lot of
time on that driver to make it actually support the full range
of voltages, and describing the supplies.
ChenYu
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: Convert TS-4800 to DT schema
From: Dmitry Torokhov @ 2026-03-19 5:05 UTC (permalink / raw)
To: Eduard Bostina
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Brown, linux-input,
devicetree, linux-kernel
In-Reply-To: <20260316181038.9771-1-egbostina@gmail.com>
On Mon, Mar 16, 2026 at 08:10:37PM +0200, Eduard Bostina wrote:
> Convert the TS-4800 touchscreen bindings to DT schema.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: touchscreen: trivial-touch: Move allOf: after required:
From: Dmitry Torokhov @ 2026-03-19 5:12 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Conor Dooley, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, linux-input, linux-renesas-soc
In-Reply-To: <20260312224925.186077-1-marek.vasut+renesas@mailbox.org>
On Thu, Mar 12, 2026 at 11:49:01PM +0100, Marek Vasut wrote:
> Majority of schemas place allOf: after required: . Documentation
> Documentation/devicetree/bindings/writing-schema.rst also hints at
> this ordering. Trivially update this schema. No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Krzysztof Kozlowski @ 2026-03-19 7:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Luca Leonardo Scorcia, linux-mediatek, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Julien Massot, Gary Bisson, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAGXv+5EqUhJ62fjE0R9nLcu6tsfXan8ZEYe7hvkofKnFM7W8NQ@mail.gmail.com>
On 19/03/2026 05:53, Chen-Yu Tsai wrote:
>>> I understood this is that electrical constraints are a matter of the
>>> actual board layout, so if adjustments are needed they have to be in
>>> the board dts. But you also specify "If fixed", so maybe there's an
>>> exception to this rule when the constraint is "absolute" and boards
>>> can't actually set a different value?
>>
>> Now I am confused. You wrote - LDOs with fixed 1.8V output - so board
>> cannot set it to 2.0V for example. They are affixed. This regulator
>> CANNOT physically produce anything else.
>
> As you said, it cannot physically produce anything else. IMO it doesn't
> even need voltage constraints as it is already implied by the model and
> regulator output, in which case I would actually recommend rejecting
> min/max voltage being added to this node.
But the text is not helping and not doing much good here. So either this
should be schema or nothing. I agree though that having here no
constraints in final DTS is valid.
Best regards,
Krzysztof
^ permalink raw reply
* [ardb:x86-pie-v4-wip] [x86] fa65278b9b: kunit.VCAP_API_DebugFS_Testsuite.vcap_api_show_admin_raw_test.fail
From: kernel test robot @ 2026-03-19 8:00 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: oe-lkp, lkp, linux-kernel, linux-arch, linux-input, oliver.sang
Hello,
we don't have enough knowledge how this change caused below kunit test failed,
but the results in our tests are quite persistent.
=========================================================================================
tbox_group/testcase/rootfs/kconfig/compiler/group:
lkp-hsw-d03/kunit/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-kunit/gcc-14/group-03
96f4aca8b6e7fd65 fa65278b9bdce81fddb3ec54017
---------------- ---------------------------
fail:runs %reproduction fail:runs
| | |
:30 100% 30:30 kunit.VCAP_API_DebugFS_Testsuite.vcap_api_show_admin_raw_test.fail
btw, the configs have below diff which seems reasonable to us.
--- /pkg/linux/x86_64-rhel-9.4-kunit/gcc-14/96f4aca8b6e7fd654c7fd3ce990e3326345c8f3b/.config 2026-03-18 11:03:48.295524180 +0800
+++ /pkg/linux/x86_64-rhel-9.4-kunit/gcc-14/fa65278b9bdce81fddb3ec54017ccc384fd42dca/.config 2026-03-18 11:04:47.609268479 +0800
@@ -530,6 +530,7 @@ CONFIG_ARCH_SUPPORTS_CRASH_HOTPLUG=y
CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
+CONFIG_RELOCATABLE_PIE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x200000
below is full report FYI.
kernel test robot noticed "kunit.VCAP_API_DebugFS_Testsuite.vcap_api_show_admin_raw_test.fail" on:
commit: fa65278b9bdce81fddb3ec54017ccc384fd42dca ("x86: Use PIE codegen for the relocatable 64-bit kernel")
https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git x86-pie-v4-wip
in testcase: kunit
version:
with following parameters:
group: group-03
config: x86_64-rhel-9.4-kunit
compiler: gcc-14
test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 16G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202603191529.cfc2cbbe-lkp@intel.com
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260319/202603191529.cfc2cbbe-lkp@intel.com
kern :err : [ 109.892567] [ T3126] # vcap_api_show_admin_raw_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_debugfs_kunit.c:377
Expected test_expected == test_pr_buffer[0], but
test_expected == " addr: 786, X6 rule, keysets: VCAP_KFS_MAC_ETYPE
"
test_pr_buffer[0] == ""
kern :info : [ 109.898412] [ T1] not ok 2 vcap_api_show_admin_raw_test
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/1] HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write
From: Lee Jones @ 2026-03-19 8:45 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Filipe Laíns, linux-input, linux-kernel
In-Reply-To: <o5n60785-0900-7869-sn47-7977p8so17nq@xreary.bet>
On Tue, 17 Mar 2026, Jiri Kosina wrote:
> On Tue, 17 Mar 2026, Lee Jones wrote:
>
> > > > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> > > > index 44b716697510..885b986c7a12 100644
> > > > --- a/drivers/hid/hid-logitech-dj.c
> > > > +++ b/drivers/hid/hid-logitech-dj.c
> > > > @@ -1282,6 +1282,12 @@ static int logi_dj_recv_send_report(struct dj_receiver_dev *djrcv_dev,
> > > > return -ENODEV;
> > > > }
> > > >
> > > > + if (report->maxfield < 1 || report->field[0]->report_count != DJREPORT_SHORT_LENGTH - 1) {
> > >
> > > This is all static information. So this should be checked in the
> > > .probe(), once the device has been parsed, not for every single call of
> > > logi_dj_recv_send_report().
> >
> > Doesn't report_count come from the device?
>
> The point is -- maxfield and report_count can't change once parsed unless
> the report descriptor would be re-read and re-parsed (which doesn't happen
> in runtime, only during probe).
>
> So checking during probe/parse time just once should be sufficient,
> instead of checking it upon every received report.
Okay, thanks for the explanation. I'll give it a shot.
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-03-19 9:53 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hendrik Noack, Ferass El Hafidi, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260319095303.19927-1-hendrik-noack@gmx.de>
Add bindings for Wacom W9002 and two Wacom W9007 variants which can be
found in tablets.
Co-developed-by: Ferass El Hafidi <funderscore@postmarketos.org>
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
.../input/touchscreen/wacom,w9007a-lt03.yaml | 73 +++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
new file mode 100644
index 000000000000..6d1da6a435d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/wacom,w9007a-lt03.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wacom W9000-series penabled I2C touchscreen
+
+maintainers:
+ - Hendrik Noack <hendrik-noack@gmx.de>
+
+description: |
+ The W9000-series are penabled touchscreen controllers by Wacom.
+
+ The firmware of controllers in different devices may differ. This can also
+ affect the controller's behavior.
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - wacom,w9002
+ - wacom,w9007a-lt03
+ - wacom,w9007a-v1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ flash-mode-gpios:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ digitizer@56 {
+ compatible = "wacom,w9007a-lt03";
+ reg = <0x56>;
+ interrupt-parent = <&gpd1>;
+ interrupts = <1 IRQ_TYPE_EDGE_RISING>;
+
+ vdd-supply = <&stylus_reg>;
+
+ flash-mode-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpx0 1 GPIO_ACTIVE_LOW>;
+
+ touchscreen-x-mm = <216>;
+ touchscreen-y-mm = <135>;
+ touchscreen-inverted-x;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v5 0/2] Add support for Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-03-19 9:53 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hendrik Noack, Ferass El Hafidi, linux-input, devicetree,
linux-kernel
Add devicetree bindings and a driver for the Wacom W9000-series penabled
touchscreens.
The driver currently only contains the information for the W9002 and
W9007A, which I or Ferass could test on devices. It should also work with
other chips, such as W9001 or W9010. However, I couldn't test it on these
and the message length would need to be added.
The pen-inserted-gpios is used to get if the pen is inserted in the device
or not. It's also used as an interrupt so that the power state of the chip
itself can be controlled depending on a change of the insertion state of
the pen.
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
Changes in v2:
- remove pdct-gpios, as it's unnecessary
- fix devicetree example
- adopt to kernel coding style
---
Changes in v3:
- fix missing include (thanks lkp@intel.com)
---
Changes in v4:
- adopt to feedback (thanks dmitry.torokhov@gmail.com)
- add W9002 support (thanks funderscore@postmarketos.org)
- add reset-gpios, necessary for some chips
- remove R-b from krzk due to changes in dt-bindings
---
Changes in v5:
- adopt dt-bindings format to suggestion (thanks krzk@kernel.org)
- remove pen-inserted functionality as suggested (thanks dmitry.torokhov@gmail.com)
---
Hendrik Noack (2):
dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
Input: Add support for Wacom W9000-series penabled touchscreens
.../input/touchscreen/wacom,w9007a-lt03.yaml | 73 +++
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/wacom_w9000.c | 433 ++++++++++++++++++
4 files changed, 519 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
create mode 100644 drivers/input/touchscreen/wacom_w9000.c
--
2.43.0
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
From: dev exalt @ 2026-03-19 10:05 UTC (permalink / raw)
To: Bastien Nocera
Cc: jikos, bentiss, lains, linux-input, linux-kernel, sari.kreitem,
hbarnor
In-Reply-To: <b1a7b5ab35c5dc16753e6a4ce98837d26c0eb98a.camel@hadess.net>
Hi Bastien,
Thanks for the review. Please see our responses inline below.
On Mon, Mar 9, 2026 at 11:53 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> Hey,
>
> Sorry for not looking at this earlier, it slipped through the cracks as
> it arrived on the mailing-list as I was away.
>
> On Mon, 2025-12-15 at 14:53 +0200, DevExalt wrote:
> > From: "Baraa Atta (Dev Exalt)" <exalt.dev.team@gmail.com>
> >
> > Add support in the Logitech HID++ driver for the HID++ Multi-Platform
> > feature (0x4531), which enables HID++ devices to adjust their
> > behavior
> > based on the host operating system (Linux, ChromeOS, Android).
>
> Can you please explain what the feature actually does ? (the Logitech
> docs say "Set the right keyboard layout for your computer operating
> system" and mention that some multimedia keys are inoperable unless a
> compatible OS is set).
The HID++ Multi-Platform feature (0x4531) allows a device to select a
platform profile that determines how the device firmware behaves for a
specific operating system.
In practice, this affects how certain keys and functions are exposed
to the host. Depending on the selected platform, the device may emit
different HID usages or key combinations for the same physical key.
For example, on the Logitech MX Keys S keyboard a specific key
produces different events depending on the configured platform. When
the platform is set to Linux the key generates the combination Shift +
Ctrl + Alt + Meta + Space, while when the platform is set to Chrome
the same key generates a dedicated Emoji key event (HID usage code
585).
The exact behavioral differences are device-specific and defined by
the device firmware.
>
> >
> > This patch:
> > * Adds device IDs for MX Keys S (046d:b378) and Casa Keys
> > (046d:b371).
> > * Introduces the module parameter "hidpp_platform" to allow
> > selecting a
> > target platform.
> > * Detects whether a device implements feature 0x4531.
> > * Validates that the requested platform is supported by the device.
> > * Applies the platform index when valid, otherwise leaves the device
> > unchanged.
> > * Keeps default behavior when "hidpp_platform" is unset or invalid.
>
> Can you explain the benefits of setting this module parameter, compared
> to using the keyboard shortcuts to switch to a specific OS
> configuration?
The distribution can configure the parameter and have the OS configure
the device automatically without user interaction. Devices will just
work as expected out of the box. Users can still override it using the
keyboard shortcut.
>
> What happens when 2 Logitech devices with different supported OSes are
> used?
If a device does not support the platform specified through the module
parameter, the driver does not modify that device and its default
platform configuration remains unchanged.
During initialization, the driver queries the device for the list of
supported platform descriptors exposed by the HID++ Multi-Platform
feature (0x4531). The requested platform is only applied if the device
advertises support for a compatible descriptor.
For example, if two devices are connected and the module parameter is
set to linux, a device that supports the Linux platform descriptor
will have its platform updated accordingly, causing its firmware
behavior to switch to the Linux profile. A device that does not
advertise support for the Linux platform will not be modified and will
continue operating on its default configuration.
>
> > Supported values for hidpp_platform:
> > Android, Linux, Chrome
>
> Any reason why there aren't more supported OSes?
>
> The Logitech docs[1] lists:
> WebOS iOS MacOS Android Chrome Linux WinEmb Windows Tizen
> as possible values.
>
> [1]:
> https://drive.google.com/file/d/1KyiBA5m_5V1s6jQ9eQrgRJN0SbbbI9_I/view
>
> I recently got a K980 which has this functionality, it only documents
> Windows, macOS and Chrome, but Solaar also lists Linux as an option.
>
> So my questions would be:
> - why not support the whole range of possible OSes in this option?
Our initial focus during development was primarily on Android, and we
subsequently added Linux and Chrome. However, if it is preferred for
completeness, we are happy to add the rest of supported OS platforms
listed in the documentation.
> - why is it a module option instead of, say, a sysfs attribute that
> could be changed per device?
> - why not implement this in user-space through a udev callout?
The module parameter was initially chosen to provide a simple,
system-wide default that distributions can configure at boot. This
ensures the devices work out of the box without relying on user
interaction.
Following your question, we can also add a per-device sysfs attribute
alongside the module parameter. This hybrid approach accommodates
compatibility with all systems, since udev is not supported by all
distributions.
>
> Cheers
>
> >
> > TEST=Pair MX Keys S and Casa Keys over Bluetooth and verify:
> > * Feature 0x4531 is detected.
> > * Valid platform values are accepted and applied.
> > * Invalid platform values result in no update.
> > * Devices without 0x4531 retain default behavior.
> > * Platform-specific key behavior is observed once applied.
> >
> > Signed-off-by: Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
> > ---
> > drivers/hid/hid-ids.h | 2 +
> > drivers/hid/hid-logitech-hidpp.c | 280
> > +++++++++++++++++++++++++++++++
> > drivers/hid/hid-quirks.c | 2 +
> > 3 files changed, 284 insertions(+)
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index d31711f1aaec..12de1194d7fa 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -866,6 +866,8 @@
> > #define USB_DEVICE_ID_LOGITECH_T651 0xb00c
> > #define USB_DEVICE_ID_LOGITECH_DINOVO_EDGE_KBD 0xb309
> > #define USB_DEVICE_ID_LOGITECH_CASA_TOUCHPAD 0xbb00
> > +#define USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD 0xb371
> > +#define USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD 0xb378
> > #define USB_DEVICE_ID_LOGITECH_C007 0xc007
> > #define USB_DEVICE_ID_LOGITECH_C077 0xc077
> > #define USB_DEVICE_ID_LOGITECH_RECEIVER 0xc101
> > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-
> > logitech-hidpp.c
> > index d5011a5d0890..e94daed31981 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -4373,6 +4373,280 @@ static bool hidpp_application_equals(struct
> > hid_device *hdev,
> > return report && report->application == application;
> > }
> >
> > +/* -----------------------------------------------------------------
> > --------- */
> > +/* 0x4531: Multi-Platform
> > Support */
> > +/* -----------------------------------------------------------------
> > --------- */
> > +
> > +/*
> > + * Some Logitech devices expose the HID++ feature 0x4531 (Multi-
> > Platform) allowing
> > + * the host to specify which operating system platform to use on the
> > device. Changing device's
> > + * platform may alter the behavior of the device to match the
> > specified platform.
> > + */
> > +
> > +static char *hidpp_platform;
> > +module_param(hidpp_platform, charp, 0644);
> > +MODULE_PARM_DESC(hidpp_platform, "Select host platform type for
> > Logitech HID++ Multi-Platform feature "
> > + "0x4531, valid values: (linux|chrome|android). If
> > unset, no "
> > + "change is applied.");
> > +
> > +#define HIDPP_MULTIPLATFORM_FEAT_ID 0x4531
> > +#define HIDPP_MULTIPLATFORM_GET_FEATURE_INFO 0x0F
> > +#define HIDPP_MULTIPLATFORM_GET_PLATFORM_DESCRIPTOR 0x1F
> > +#define HIDPP_MULTIPLATFORM_SET_CURRENT_PLATFORM 0x3F
> > +
> > +#define
> > HIDPP_MULTIPLATFORM_PLATFORM_MASK_LINUX BIT(10)
> > +#define HIDPP_MULTIPLATFORM_PLATFORM_MASK_CHROME BIT(11)
> > +#define HIDPP_MULTIPLATFORM_PLATFORM_MASK_ANDROID BIT(12)
> > +
> > +struct hidpp_platform_desc {
> > + u8 plat_idx;
> > + u8 desc_idx;
> > + u16 plat_mask;
> > +};
> > +
> > +/**
> > + * hidpp_multiplatform_mask_from_str() - Convert platform name to an
> > HID++ platform mask
> > + * @pname: Platform name string
> > + *
> > + * Converts a platform name string to its corresponding HID++
> > platform mask based on
> > + * the Multi-Platform feature specification.
> > + *
> > + * Return: Platform mask corresponding to @pname on success,
> > + * or 0 if @pname is NULL or unsupported.
> > + */
> > +static u16 hidpp_multiplatform_mask_from_str(const char *pname)
> > +{
> > + if (!pname)
> > + return 0;
> > +
> > + if (!strcasecmp(pname, "linux"))
> > + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_LINUX;
> > + if (!strcasecmp(pname, "chrome"))
> > + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_CHROME;
> > + if (!strcasecmp(pname, "android"))
> > + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_ANDROID;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hidpp_multiplatform_get_num_pdesc() - Retrieve number of platform
> > descriptors
> > + * @hidpp: Pointer to the hidpp_device instance
> > + * @feat_index: Feature index of the Multi-Platform feature
> > + * @num_desc: Pointer to store the number of platform descriptors
> > + *
> > + * Retrieves the number of platform descriptors supported by the
> > device through
> > + * the Multi-Platform feature and stores it in @num_desc.
> > + *
> > + * Return: 0 on success, or non-zero on failure.
> > + */
> > +static int hidpp_multiplatform_get_num_pdesc(struct hidpp_device
> > *hidpp,
> > + u8 feat_index, u8
> > *num_desc)
> > +{
> > + int ret;
> > + struct hidpp_report response;
> > + struct hid_device *hdev = hidpp->hid_dev;
> > +
> > + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> > +
> > HIDPP_MULTIPLATFORM_GET_FEATURE_INFO,
> > + NULL, 0, &response);
> > + if (ret) {
> > + hid_warn(hdev, "Multiplatform: GET_FEATURE_INFO
> > failed (err=%d)", ret);
> > + return ret;
> > + }
> > +
> > + *num_desc = response.fap.params[3];
> > + hid_dbg(hdev, "Multiplatform: Device supports %d platform
> > descriptors", *num_desc);
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hidpp_multiplatform_get_platform_desc() - Retrieve a platform
> > descriptor entry
> > + * @hidpp: Pointer to the hidpp_device instance
> > + * @feat_index: Feature index of the Multi-Platform feature
> > + * @platform_idx: Index of the platform descriptor to retrieve
> > + * @pdesc: Pointer to store the retrieved platform descriptor
> > + *
> > + * Retrieves a single platform descriptor identified by
> > @platform_idx from the
> > + * device and stores the parsed descriptor fields in @pdesc.
> > + *
> > + * Return: 0 on success, or non-zero on failure.
> > + */
> > +static int hidpp_multiplatform_get_platform_desc(struct hidpp_device
> > *hidpp, u8 feat_index,
> > + u8 platform_idx,
> > struct hidpp_platform_desc *pdesc)
> > +{
> > + int ret;
> > + struct hidpp_report response;
> > + u8 params[1] = { platform_idx };
> > + struct hid_device *hdev = hidpp->hid_dev;
> > +
> > + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> > +
> > HIDPP_MULTIPLATFORM_GET_PLATFORM_DESCRIPTOR,
> > + params, sizeof(params),
> > &response);
> > +
> > + if (ret) {
> > + hid_warn(hdev,
> > + "Multiplatform: GET_PLATFORM_DESCRIPTOR
> > failed for index %d (err=%d)",
> > + platform_idx, ret);
> > + return ret;
> > + }
> > +
> > + pdesc->plat_idx = response.fap.params[0];
> > + pdesc->desc_idx = response.fap.params[1];
> > + pdesc->plat_mask =
> > get_unaligned_be16(&response.fap.params[2]);
> > +
> > + hid_dbg(hdev,
> > + "Multiplatform: descriptor %d: plat_idx=%d,
> > desc_idx=%d, plat_mask=0x%04x",
> > + platform_idx, pdesc->plat_idx, pdesc->desc_idx,
> > pdesc->plat_mask);
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hidpp_multiplatform_get_platform_index() - Find platform index
> > for a mask
> > + * @hidpp: Pointer to the hidpp_device instance
> > + * @feat_index: Feature index of the Multi-Platform feature
> > + * @plat_mask: Platform mask to search for
> > + * @plat_index: Pointer to store the matched platform index
> > + *
> > + * Iterates through all platform descriptors exposed by the device
> > via the
> > + * Multi-Platform feature, retrieving each descriptor and comparing
> > its
> > + * platform mask to @plat_mask. A descriptor matches if its mask
> > overlaps with
> > + * the requested @plat_mask (i.e. (pdesc.plat_mask & plat_mask) is
> > non-zero).
> > + *
> > + * When a matching descriptor is found, its platform index
> > (plat_idx) is
> > + * written to @plat_index and the function returns success.
> > + *
> > + * If no descriptor matches, -ENOENT is returned.
> > + *
> > + * Return: 0 on success; -ENOENT if no matching descriptor exists;
> > + * or non-zero on failure.
> > + */
> > +static int hidpp_multiplatform_get_platform_index(struct
> > hidpp_device *hidpp,
> > + u8 feat_index, u16
> > plat_mask,
> > + u8 *plat_index)
> > +{
> > + int i;
> > + int ret;
> > + u8 num_desc;
> > + struct hidpp_platform_desc pdesc;
> > + struct hid_device *hdev = hidpp->hid_dev;
> > +
> > + ret = hidpp_multiplatform_get_num_pdesc(hidpp, feat_index,
> > &num_desc);
> > + if (ret)
> > + return ret;
> > +
> > + for (i = 0; i < num_desc; i++) {
> > + ret = hidpp_multiplatform_get_platform_desc(hidpp,
> > feat_index, i, &pdesc);
> > + if (ret)
> > + return ret;
> > +
> > + if (pdesc.plat_mask & plat_mask) {
> > + *plat_index = pdesc.plat_idx;
> > + hid_dbg(hdev,
> > + "Multiplatform: Selected platform
> > index %d for platform '%s'",
> > + *plat_index, hidpp_platform);
> > + return 0;
> > + }
> > + }
> > +
> > + hid_dbg(hdev,
> > + "Multiplatform: No matching platform descriptor
> > found for platform '%s'",
> > + hidpp_platform);
> > + return -ENOENT;
> > +}
> > +
> > +/**
> > + * hidpp_multiplatform_update_device_platform() - Update the device
> > platform
> > + * @hidpp: Pointer to the hidpp_device instance
> > + * @feat_index: Feature index of the Multi-Platform feature
> > + * @plat_index: Platform index to set on the device
> > + *
> > + * Sends the HID++ Multi-Platform 'SET_CURRENT_PLATFORM' command to
> > the device to
> > + * update its platform index to @plat_index.
> > + *
> > + * Return: 0 on success, or non-zero on failure.
> > + */
> > +static int hidpp_multiplatform_update_device_platform(struct
> > hidpp_device *hidpp,
> > + u8 feat_index,
> > u8 plat_index)
> > +{
> > + int ret;
> > + struct hidpp_report response;
> > + /* Byte 0 (hostIndex): 0xFF selects the current host. */
> > + u8 params[2] = { 0xFF, plat_index };
> > +
> > + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> > +
> > HIDPP_MULTIPLATFORM_SET_CURRENT_PLATFORM,
> > + params, sizeof(params),
> > &response);
> > +
> > + if (ret)
> > + hid_warn(hidpp->hid_dev,
> > + "Multiplatform: SET_CURRENT_PLATFORM failed
> > for index %d (err=%d)",
> > + plat_index, ret);
> > +
> > + return ret;
> > +}
> > +
> > +/**
> > + * hidpp_multiplatform_init() - Apply the HID++ Multi-Platform
> > (0x4531) feature
> > + * @hidpp: Pointer to the hidpp_device instance
> > + *
> > + * Initializes the Multi-Platform feature by selecting the device
> > platform
> > + * corresponding to the module parameter @hidpp_platform, if
> > provided.
> > + *
> > + * The function performs the following steps:
> > + * 1. Convert the @hidpp_platform string into a platform mask.
> > + * 2. Check whether the device supports the Multi-Platform feature
> > (0x4531).
> > + * 3. Look up the device's platform index whose mask matches the
> > host
> > + * platform mask.
> > + * 4. Apply that platform index to the device via
> > 'SET_CURRENT_PLATFORM'.
> > + *
> > + * If the module parameter is unset or invalid, or the device does
> > not support
> > + * the feature, or no matching platform descriptor is found, the
> > function exits
> > + * silently without modifying the device state.
> > + *
> > + * On success, the device's platform configuration is updated.
> > + */
> > +static void hidpp_multiplatform_init(struct hidpp_device *hidpp)
> > +{
> > + int ret;
> > + u8 feat_index;
> > + u8 plat_index;
> > + u16 host_plat_mask;
> > + struct hid_device *hdev = hidpp->hid_dev;
> > +
> > + if (!hidpp_platform)
> > + return;
> > +
> > + host_plat_mask =
> > hidpp_multiplatform_mask_from_str(hidpp_platform);
> > + if (!host_plat_mask) {
> > + hid_warn(hdev,
> > + "Multiplatform: Invalid or unsupported
> > platform name '%s'",
> > + hidpp_platform);
> > + return;
> > + }
> > +
> > + ret = hidpp_root_get_feature(hidpp,
> > HIDPP_MULTIPLATFORM_FEAT_ID, &feat_index);
> > + if (ret) {
> > + hid_warn(hdev,
> > + "Multiplatform: Failed to get the HID++
> > multiplatform feature 0x4531");
> > + return;
> > + }
> > +
> > + ret = hidpp_multiplatform_get_platform_index(hidpp,
> > feat_index, host_plat_mask,
> > + &plat_index);
> > + if (ret)
> > + return;
> > +
> > + ret = hidpp_multiplatform_update_device_platform(hidpp,
> > feat_index, plat_index);
> > + if (ret)
> > + return;
> > +
> > + hid_info(hdev,
> > + "Multiplatform: Device platform successfully set to
> > '%s'", hidpp_platform);
> > +}
> > +
> > static int hidpp_probe(struct hid_device *hdev, const struct
> > hid_device_id *id)
> > {
> > struct hidpp_device *hidpp;
> > @@ -4467,6 +4741,8 @@ static int hidpp_probe(struct hid_device *hdev,
> > const struct hid_device_id *id)
> > if (hidpp->quirks & HIDPP_QUIRK_DELAYED_INIT)
> > connect_mask &= ~HID_CONNECT_HIDINPUT;
> >
> > + hidpp_multiplatform_init(hidpp);
> > +
> > /* Now export the actual inputs and hidraw nodes to the
> > world */
> > hid_device_io_stop(hdev);
> > ret = hid_connect(hdev, connect_mask);
> > @@ -4664,6 +4940,10 @@ static const struct hid_device_id
> > hidpp_devices[] = {
> > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
> > { /* MX Anywhere 3SB mouse over Bluetooth */
> > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
> > + { /* Casa Keys keyboard over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD) },
> > + { /* MX Keys S keyboard over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD) },
> > {}
> > };
> >
> > diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> > index c89a015686c0..99ca04b61bda 100644
> > --- a/drivers/hid/hid-quirks.c
> > +++ b/drivers/hid/hid-quirks.c
> > @@ -520,6 +520,8 @@ static const struct hid_device_id
> > hid_have_special_driver[] = {
> > #endif
> > #if IS_ENABLED(CONFIG_HID_LOGITECH_HIDPP)
> > { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> > USB_DEVICE_ID_LOGITECH_G920_WHEEL) },
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD) },
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD) },
> > #endif
> > #if IS_ENABLED(CONFIG_HID_MAGICMOUSE)
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
> > USB_DEVICE_ID_APPLE_MAGICMOUSE) },
Thanks,
Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
^ 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