* [PATCH v6 0/6 RESEND] mfd: cpcap: convert documentation to schema and add Mot board support
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
The initial goal was only to add support for the CPCAP used in the Mot
Tegra20 board; however, since the documentation was already partially
converted, I decided to complete the conversion to schema too.
The CPCAP regulator, leds, rtc, pwrbutton and core files were converted
from TXT to YAML while preserving the original structure. Mot board
compatibility was added to the regulator and core schema. Since these
were one-line patches, they were not separated into dedicated commits;
however, the commit message notes this for both cases.
Finally, the CPCAP MFD was slightly refactored to improve support for
multiple subcell compositions.
---
Changes in v2:
- fixed code style
- rtc conversion was picked, so patch dropped
- added audio ports description into mfd schema
- splitted schema conversion and compatible addition
- minor style improvements and typo fixes
Changes in v3:
- added regulator node names list into pattern
- filled spi_device_id with driver data
- ADC patches were picked, so changes dropped
Changes in v4:
- dropped regulator patches (applied)
Changes in v5:
- switched to MFD_CELL_* macros
- switched to use determinator of model
- switched to spi_get_device_match_data
Changes in v6:
- removed address-cells and size-cells from main node
- changed macros formatting and OF matches
- factored out common devices and made device addition staged
- dropped cpcap->variant check for 0
- EINVAL > ENODEV in variant checking switch
---
Svyatoslav Ryhel (6):
dt-bindings: leds: leds-cpcap: convert to DT schema
dt-bindings: input: cpcap-pwrbutton: convert to DT schema
dt-bindings: mfd: motorola-cpcap: convert to DT schema
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
mfd: motorola-cpcap: diverge configuration per-board
mfd: motorola-cpcap: add support for Mot CPCAP composition
.../bindings/input/cpcap-pwrbutton.txt | 20 -
.../input/motorola,cpcap-pwrbutton.yaml | 32 ++
.../devicetree/bindings/leds/leds-cpcap.txt | 29 --
.../bindings/leds/motorola,cpcap-leds.yaml | 42 ++
.../bindings/mfd/motorola,cpcap.yaml | 408 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
drivers/mfd/motorola-cpcap.c | 143 +++---
include/linux/mfd/motorola-cpcap.h | 7 +
8 files changed, 571 insertions(+), 188 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
--
2.51.0
^ permalink raw reply
* [PATCH v6 1/6 RESEND] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260625081812.33474-1-clamor95@gmail.com>
Convert LEDs devicetree bindings for the Motorola CPCAP MFD from TXT to
YAML format. This patch does not change any functionality; the bindings
remain the same.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/leds/leds-cpcap.txt | 29 -------------
.../bindings/leds/motorola,cpcap-leds.yaml | 42 +++++++++++++++++++
2 files changed, 42 insertions(+), 29 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
deleted file mode 100644
index ebf7cdc7f70c..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Motorola CPCAP PMIC LEDs
-------------------------
-
-This module is part of the CPCAP. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
-
-Requires node properties:
-- compatible: should be one of
- * "motorola,cpcap-led-mdl" (Main Display Lighting)
- * "motorola,cpcap-led-kl" (Keyboard Lighting)
- * "motorola,cpcap-led-adl" (Aux Display Lighting)
- * "motorola,cpcap-led-red" (Red Triode)
- * "motorola,cpcap-led-green" (Green Triode)
- * "motorola,cpcap-led-blue" (Blue Triode)
- * "motorola,cpcap-led-cf" (Camera Flash)
- * "motorola,cpcap-led-bt" (Bluetooth)
- * "motorola,cpcap-led-cp" (Camera Privacy LED)
-- label: see Documentation/devicetree/bindings/leds/common.txt
-- vdd-supply: A phandle to the regulator powering the LED
-
-Example:
-
-&cpcap {
- cpcap_led_red: red-led {
- compatible = "motorola,cpcap-led-red";
- label = "cpcap:red";
- vdd-supply = <&sw5>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
new file mode 100644
index 000000000000..c8e7b88a05cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC LEDs
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ This module is part of the Motorola CPCAP MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. LEDs are
+ represented as sub-nodes of the PMIC node on the device tree.
+
+allOf:
+ - $ref: /schemas/leds/common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - motorola,cpcap-led-adl # Display Lighting
+ - motorola,cpcap-led-blue # Blue Triode
+ - motorola,cpcap-led-bt # Bluetooth
+ - motorola,cpcap-led-cf # Camera Flash
+ - motorola,cpcap-led-cp # Camera Privacy LED
+ - motorola,cpcap-led-green # Green Triode
+ - motorola,cpcap-led-kl # Keyboard Lighting
+ - motorola,cpcap-led-mdl # Main Display Lighting
+ - motorola,cpcap-led-red # Red Triode
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - label
+ - vdd-supply
+
+unevaluatedProperties: false
+
+...
--
2.51.0
^ permalink raw reply related
* [PATCH v6 2/6 RESEND] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260625081812.33474-1-clamor95@gmail.com>
Convert power button devicetree bindings for the Motorola CPCAP MFD from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/input/cpcap-pwrbutton.txt | 20 ------------
.../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
deleted file mode 100644
index 0dd0076daf71..000000000000
--- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Motorola CPCAP on key
-
-This module is part of the CPCAP. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
-
-This module provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be one of the following
- - "motorola,cpcap-pwrbutton"
-- interrupts: irq specifier for CPCAP's ON IRQ
-
-Example:
-
-&cpcap {
- cpcap_pwrbutton: pwrbutton {
- compatible = "motorola,cpcap-pwrbutton";
- interrupts = <23 IRQ_TYPE_NONE>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
new file mode 100644
index 000000000000..77a3e5a47d1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC power key
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ This module is part of the Motorola CPCAP MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
+ power key is represented as a sub-node of the PMIC node on the device
+ tree.
+
+properties:
+ compatible:
+ const: motorola,cpcap-pwrbutton
+
+ interrupts:
+ items:
+ - description: CPCAP's ON interrupt
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+...
--
2.51.0
^ permalink raw reply related
* [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260625081812.33474-1-clamor95@gmail.com>
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/mfd/motorola,cpcap.yaml | 403 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
2 files changed, 403 insertions(+), 78 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
new file mode 100644
index 000000000000..76705ea56805
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
@@ -0,0 +1,403 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC MFD
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: motorola,cpcap
+ - const: st,6556002
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ spi-max-frequency:
+ maximum: 9600000
+
+ spi-cs-high: true
+ spi-cpol: true
+ spi-cpha: true
+
+ adc:
+ $ref: /schemas/iio/adc/motorola,cpcap-adc.yaml#
+
+ audio-codec:
+ type: object
+ additionalProperties: false
+
+ properties:
+ interrupts:
+ items:
+ - description: headset detect interrupt
+ - description: microphone bias 2 detect interrupt
+
+ interrupt-names:
+ items:
+ - const: hs
+ - const: mb2
+
+ "#sound-dai-cells":
+ const: 1
+
+ VAUDIO-supply:
+ description:
+ Codec power supply, usually VAUDIO regulator of CPCAP.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: port connected to the Stereo HiFi DAC
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: port connected to the Voice DAC
+
+ required:
+ - port@0
+ - port@1
+
+ required:
+ - interrupts
+ - interrupt-names
+ - "#sound-dai-cells"
+
+ battery:
+ $ref: /schemas/power/supply/cpcap-battery.yaml#
+
+ charger:
+ $ref: /schemas/power/supply/cpcap-charger.yaml#
+
+ key-power:
+ $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
+
+ phy:
+ $ref: /schemas/phy/motorola,cpcap-usb-phy.yaml#
+
+ regulator:
+ $ref: /schemas/regulator/motorola,cpcap-regulator.yaml#
+
+ rtc:
+ $ref: /schemas/rtc/motorola,cpcap-rtc.yaml#
+
+patternProperties:
+ "^led(-[a-z]+)?$":
+ $ref: /schemas/leds/motorola,cpcap-leds.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpcap: pmic@0 {
+ compatible = "motorola,cpcap", "st,6556002";
+ reg = <0>; /* cs0 */
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ spi-max-frequency = <3000000>;
+ spi-cs-high;
+
+ spi-cpol;
+ spi-cpha;
+
+ cpcap_adc: adc {
+ compatible = "motorola,cpcap-adc";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <8 IRQ_TYPE_NONE>;
+ interrupt-names = "adcdone";
+
+ #io-channel-cells = <1>;
+ };
+
+ cpcap_audio: audio-codec {
+ interrupt-parent = <&cpcap>;
+ interrupts = <9 IRQ_TYPE_NONE>, <10 IRQ_TYPE_NONE>;
+ interrupt-names = "hs", "mb2";
+
+ VAUDIO-supply = <&vdd_audio>;
+
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* HiFi */
+ port@0 {
+ reg = <0>;
+
+ cpcap_audio_codec0: endpoint {
+ };
+ };
+
+ /* Voice */
+ port@1 {
+ reg = <1>;
+
+ cpcap_audio_codec1: endpoint {
+ };
+ };
+ };
+ };
+
+ cpcap_battery: battery {
+ compatible = "motorola,cpcap-battery";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <6 IRQ_TYPE_NONE>, <5 IRQ_TYPE_NONE>,
+ <3 IRQ_TYPE_NONE>, <20 IRQ_TYPE_NONE>,
+ <54 IRQ_TYPE_NONE>, <57 IRQ_TYPE_NONE>;
+ interrupt-names = "eol", "lowbph", "lowbpl",
+ "chrgcurr1", "battdetb", "cccal";
+
+ io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
+ <&cpcap_adc 5>, <&cpcap_adc 6>;
+ io-channel-names = "battdetb", "battp",
+ "chg_isense", "batti";
+ power-supplies = <&cpcap_charger>;
+ };
+
+ cpcap_charger: charger {
+ compatible = "motorola,mapphone-cpcap-charger";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <13 IRQ_TYPE_NONE>, <12 IRQ_TYPE_NONE>,
+ <29 IRQ_TYPE_NONE>, <28 IRQ_TYPE_NONE>,
+ <22 IRQ_TYPE_NONE>, <21 IRQ_TYPE_NONE>,
+ <20 IRQ_TYPE_NONE>, <19 IRQ_TYPE_NONE>,
+ <54 IRQ_TYPE_NONE>;
+ interrupt-names = "chrg_det", "rvrs_chrg", "chrg_se1b",
+ "se0conn", "rvrs_mode", "chrgcurr2",
+ "chrgcurr1", "vbusvld", "battdetb";
+
+ mode-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>,
+ <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+ io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
+ <&cpcap_adc 2>, <&cpcap_adc 5>,
+ <&cpcap_adc 6>;
+ io-channel-names = "battdetb", "battp",
+ "vbus", "chg_isense",
+ "batti";
+ };
+
+ key-power {
+ compatible = "motorola,cpcap-pwrbutton";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <23 IRQ_TYPE_NONE>;
+ };
+
+ led-red {
+ compatible = "motorola,cpcap-led-red";
+ vdd-supply = <&vdd_led>;
+ label = "status-led::red";
+ };
+
+ led-green {
+ compatible = "motorola,cpcap-led-green";
+ vdd-supply = <&vdd_led>;
+ label = "status-led::green";
+ };
+
+ led-blue {
+ compatible = "motorola,cpcap-led-blue";
+ vdd-supply = <&vdd_led>;
+ label = "status-led::blue";
+ };
+
+ cpcap_usb2_phy: phy {
+ compatible = "motorola,cpcap-usb-phy";
+
+ pinctrl-0 = <&usb_gpio_mux_sel1>, <&usb_gpio_mux_sel2>;
+ pinctrl-1 = <&usb_ulpi_pins>;
+ pinctrl-2 = <&usb_utmi_pins>;
+ pinctrl-3 = <&uart3_pins>;
+ pinctrl-names = "default", "ulpi", "utmi", "uart";
+ #phy-cells = <0>;
+
+ interrupts-extended =
+ <&cpcap 15 IRQ_TYPE_NONE>, <&cpcap 14 IRQ_TYPE_NONE>,
+ <&cpcap 28 IRQ_TYPE_NONE>, <&cpcap 19 IRQ_TYPE_NONE>,
+ <&cpcap 18 IRQ_TYPE_NONE>, <&cpcap 17 IRQ_TYPE_NONE>,
+ <&cpcap 16 IRQ_TYPE_NONE>, <&cpcap 49 IRQ_TYPE_NONE>,
+ <&cpcap 48 IRQ_TYPE_NONE>;
+ interrupt-names = "id_ground", "id_float", "se0conn",
+ "vbusvld", "sessvld", "sessend",
+ "se1", "dm", "dp";
+
+ mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,
+ <&gpio1 0 GPIO_ACTIVE_HIGH>;
+
+ io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
+ io-channel-names = "vbus", "id";
+
+ vusb-supply = <&avdd_usb>;
+ };
+
+ regulator {
+ compatible = "motorola,cpcap-regulator";
+
+ regulators {
+ vdd_cpu: SW1 {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1125000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_core: SW2 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_1v8_vio: SW3 {
+ regulator-name = "vdd_1v8_vio";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_aon: SW4 {
+ regulator-name = "vdd_aon";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_led: SW5 {
+ regulator-name = "vdd_led";
+ regulator-min-microvolt = <5050000>;
+ regulator-max-microvolt = <5050000>;
+ regulator-enable-ramp-delay = <1500>;
+ regulator-boot-on;
+ };
+
+ vdd_hvio: VHVIO {
+ regulator-name = "vdd_hvio";
+ regulator-min-microvolt = <2775000>;
+ regulator-max-microvolt = <2775000>;
+ regulator-enable-ramp-delay = <1000>;
+ };
+
+ vcore_emmc: VSDIO {
+ regulator-name = "vcore_emmc";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ avdd_dsi_csi: VCSI {
+ regulator-name = "avdd_dsi_csi";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-boot-on;
+ };
+
+ avdd_3v3_periph: VWLAN2 {
+ regulator-name = "avdd_3v3_periph";
+ regulator-min-microvolt = <2775000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-boot-on;
+ };
+
+ vddio_usd: VSIMCARD {
+ regulator-name = "vddio_usd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2900000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-boot-on;
+ };
+
+ vdd_haptic: VVIB {
+ regulator-name = "vdd_haptic";
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <1000>;
+ };
+
+ avdd_usb: VUSB {
+ regulator-name = "avdd_usb";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_audio: VAUDIO {
+ regulator-name = "vdd_audio";
+ regulator-min-microvolt = <2775000>;
+ regulator-max-microvolt = <2775000>;
+ regulator-enable-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+
+ cpcap_rtc: rtc {
+ compatible = "motorola,cpcap-rtc";
+
+ interrupt-parent = <&cpcap>;
+ interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
deleted file mode 100644
index 18c3fc26ca93..000000000000
--- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Motorola CPCAP PMIC device tree binding
-
-Required properties:
-- compatible : One or both of "motorola,cpcap" or "ste,6556002"
-- reg : SPI chip select
-- interrupts : The interrupt line the device is connected to
-- interrupt-controller : Marks the device node as an interrupt controller
-- #interrupt-cells : The number of cells to describe an IRQ, should be 2
-- #address-cells : Child device offset number of cells, should be 1
-- #size-cells : Child device size number of cells, should be 0
-- spi-max-frequency : Typically set to 3000000
-- spi-cs-high : SPI chip select direction
-
-Optional subnodes:
-
-The sub-functions of CPCAP get their own node with their own compatible values,
-which are described in the following files:
-
-- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml
-- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml
-- Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
-- Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
-- Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
-- Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
-- Documentation/devicetree/bindings/leds/leds-cpcap.txt
-- Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
-
-The only exception is the audio codec. Instead of a compatible value its
-node must be named "audio-codec".
-
-Required properties for the audio-codec subnode:
-
-- #sound-dai-cells = <1>;
-- interrupts : should contain jack detection interrupts, with headset
- detect interrupt matching "hs" and microphone bias 2
- detect interrupt matching "mb2" in interrupt-names.
-- interrupt-names : Contains "hs", "mb2"
-
-The audio-codec provides two DAIs. The first one is connected to the
-Stereo HiFi DAC and the second one is connected to the Voice DAC.
-
-Example:
-
-&mcspi1 {
- cpcap: pmic@0 {
- compatible = "motorola,cpcap", "ste,6556002";
- reg = <0>; /* cs0 */
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
- spi-max-frequency = <3000000>;
- spi-cs-high;
-
- audio-codec {
- #sound-dai-cells = <1>;
- interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>;
- interrupt-names = "hs", "mb2";
-
- /* HiFi */
- port@0 {
- endpoint {
- remote-endpoint = <&cpu_dai1>;
- };
- };
-
- /* Voice */
- port@1 {
- endpoint {
- remote-endpoint = <&cpu_dai2>;
- };
- };
- };
- };
-};
-
--
2.51.0
^ permalink raw reply related
* [PATCH v6 4/6 RESEND] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260625081812.33474-1-clamor95@gmail.com>
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/mfd/motorola,cpcap.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
index 76705ea56805..da7abe2ec912 100644
--- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
+++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
@@ -14,9 +14,14 @@ allOf:
properties:
compatible:
- items:
- - const: motorola,cpcap
- - const: st,6556002
+ oneOf:
+ - enum:
+ - motorola,mapphone-cpcap
+ - motorola,mot-cpcap
+
+ - items:
+ - const: motorola,cpcap
+ - const: st,6556002
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* [PATCH v6 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260625081812.33474-1-clamor95@gmail.com>
MFD have rigid subdevice structure which does not allow flexible dynamic
subdevice linking. Address this by diverging CPCAP subdevice composition
to take into account board specific configuration.
Create a common and default subdevice composition, rename edit existing
subdevice composition into cpcap_mapphone_devices since it targets mainly
Mapphone board.
Removed st,6556002 as it is no longer applicable to all cases and
duplicates motorola,cpcap, which is used as the default composition.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/motorola-cpcap.c | 125 +++++++++++++++--------------
include/linux/mfd/motorola-cpcap.h | 6 ++
2 files changed, 70 insertions(+), 61 deletions(-)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index d8243b956f87..5b6ca6b81c23 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
+#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/sysfs.h>
@@ -30,6 +31,7 @@ struct cpcap_ddata {
struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
const struct regmap_config *regmap_conf;
struct regmap *regmap;
+ enum cpcap_variant variant;
};
static int cpcap_sense_irq(struct regmap *regmap, int irq)
@@ -195,20 +197,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
return 0;
}
-static const struct of_device_id cpcap_of_match[] = {
- { .compatible = "motorola,cpcap", },
- { .compatible = "st,6556002", },
- {},
-};
-MODULE_DEVICE_TABLE(of, cpcap_of_match);
-
-static const struct spi_device_id cpcap_spi_ids[] = {
- { .name = "cpcap", },
- { .name = "6556002", },
- {},
-};
-MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
-
static const struct regmap_config cpcap_regmap_config = {
.reg_bits = 16,
.reg_stride = 4,
@@ -241,62 +229,58 @@ static int cpcap_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
-static const struct mfd_cell cpcap_mfd_devices[] = {
- {
- .name = "cpcap_adc",
- .of_compatible = "motorola,mapphone-cpcap-adc",
- }, {
- .name = "cpcap_battery",
- .of_compatible = "motorola,cpcap-battery",
- }, {
- .name = "cpcap-charger",
- .of_compatible = "motorola,mapphone-cpcap-charger",
- }, {
- .name = "cpcap-regulator",
- .of_compatible = "motorola,mapphone-cpcap-regulator",
- }, {
- .name = "cpcap-rtc",
- .of_compatible = "motorola,cpcap-rtc",
- }, {
- .name = "cpcap-pwrbutton",
- .of_compatible = "motorola,cpcap-pwrbutton",
- }, {
- .name = "cpcap-usb-phy",
- .of_compatible = "motorola,mapphone-cpcap-usb-phy",
- }, {
- .name = "cpcap-led",
- .id = 0,
- .of_compatible = "motorola,cpcap-led-red",
- }, {
- .name = "cpcap-led",
- .id = 1,
- .of_compatible = "motorola,cpcap-led-green",
- }, {
- .name = "cpcap-led",
- .id = 2,
- .of_compatible = "motorola,cpcap-led-blue",
- }, {
- .name = "cpcap-led",
- .id = 3,
- .of_compatible = "motorola,cpcap-led-adl",
- }, {
- .name = "cpcap-led",
- .id = 4,
- .of_compatible = "motorola,cpcap-led-cp",
- }, {
- .name = "cpcap-codec",
- }
+static const struct mfd_cell cpcap_common_devices[] = {
+ MFD_CELL_OF("cpcap_battery", NULL, NULL, 0, 0, "motorola,cpcap-battery"),
+ MFD_CELL_OF("cpcap-rtc", NULL, NULL, 0, 0, "motorola,cpcap-rtc"),
+ MFD_CELL_OF("cpcap-pwrbutton", NULL, NULL, 0, 0, "motorola,cpcap-pwrbutton"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 0, "motorola,cpcap-led-red"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 1, "motorola,cpcap-led-green"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 2, "motorola,cpcap-led-blue"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 3, "motorola,cpcap-led-adl"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 4, "motorola,cpcap-led-cp"),
+ MFD_CELL_NAME("cpcap-codec"),
+};
+
+static const struct mfd_cell cpcap_default_devices[] = {
+ MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,cpcap-adc"),
+ MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,cpcap-regulator"),
+ MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,cpcap-usb-phy"),
+};
+
+static const struct mfd_cell cpcap_mapphone_devices[] = {
+ MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-adc"),
+ MFD_CELL_OF("cpcap-charger", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-charger"),
+ MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-regulator"),
+ MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-usb-phy"),
};
static int cpcap_probe(struct spi_device *spi)
{
struct cpcap_ddata *cpcap;
+ const struct mfd_cell *cells;
+ unsigned int num_cells;
int ret;
cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
if (!cpcap)
return -ENOMEM;
+ cpcap->variant = (enum cpcap_variant)spi_get_device_match_data(spi);
+
+ switch (cpcap->variant) {
+ case CPCAP_DEFAULT:
+ cells = cpcap_default_devices;
+ num_cells = ARRAY_SIZE(cpcap_default_devices);
+ break;
+ case CPCAP_MAPPHONE:
+ cells = cpcap_mapphone_devices;
+ num_cells = ARRAY_SIZE(cpcap_mapphone_devices);
+ break;
+ default:
+ return dev_err_probe(&spi->dev, -ENODEV,
+ "Unknown device %d\n", cpcap->variant);
+ }
+
cpcap->spi = spi;
spi_set_drvdata(spi, cpcap);
@@ -331,10 +315,29 @@ static int cpcap_probe(struct spi_device *spi)
spi->dev.coherent_dma_mask = 0;
spi->dev.dma_mask = &spi->dev.coherent_dma_mask;
- return devm_mfd_add_devices(&spi->dev, 0, cpcap_mfd_devices,
- ARRAY_SIZE(cpcap_mfd_devices), NULL, 0, NULL);
+ ret = devm_mfd_add_devices(&spi->dev, 0, cpcap_common_devices,
+ ARRAY_SIZE(cpcap_common_devices), NULL, 0, NULL);
+ if (ret)
+ return dev_err_probe(&spi->dev, ret,
+ "Failed to add common child devices\n");
+
+ return devm_mfd_add_devices(&spi->dev, 0, cells, num_cells, NULL, 0, NULL);
}
+static const struct of_device_id cpcap_of_match[] = {
+ { .compatible = "motorola,cpcap", .data = (void *)CPCAP_DEFAULT },
+ { .compatible = "motorola,mapphone-cpcap", .data = (void *)CPCAP_MAPPHONE },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, cpcap_of_match);
+
+static const struct spi_device_id cpcap_spi_ids[] = {
+ { "cpcap", CPCAP_DEFAULT },
+ { "mapphone-cpcap", CPCAP_MAPPHONE },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
+
static struct spi_driver cpcap_driver = {
.driver = {
.name = "cpcap-core",
diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
index 981e5777deb7..1a85b06272c8 100644
--- a/include/linux/mfd/motorola-cpcap.h
+++ b/include/linux/mfd/motorola-cpcap.h
@@ -25,6 +25,12 @@
#define CPCAP_REVISION_2_0 0x10
#define CPCAP_REVISION_2_1 0x11
+enum cpcap_variant {
+ CPCAP_DEFAULT = 1,
+ CPCAP_MAPPHONE,
+ CPCAP_MAX
+};
+
/* CPCAP registers */
#define CPCAP_REG_INT1 0x0000 /* Interrupt 1 */
#define CPCAP_REG_INT2 0x0004 /* Interrupt 2 */
--
2.51.0
^ permalink raw reply related
* [PATCH v6 6/6 RESEND] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Svyatoslav Ryhel @ 2026-06-25 8:18 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260625081812.33474-1-clamor95@gmail.com>
Add a MFD subdevice composition used in Tegra20 based Mot board
(Motorola Atrix 4G and Droid X2).
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/motorola-cpcap.c | 20 +++++++++++++++++++-
include/linux/mfd/motorola-cpcap.h | 1 +
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index 5b6ca6b81c23..f6198276d266 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -237,7 +237,6 @@ static const struct mfd_cell cpcap_common_devices[] = {
MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 1, "motorola,cpcap-led-green"),
MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 2, "motorola,cpcap-led-blue"),
MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 3, "motorola,cpcap-led-adl"),
- MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 4, "motorola,cpcap-led-cp"),
MFD_CELL_NAME("cpcap-codec"),
};
@@ -245,6 +244,7 @@ static const struct mfd_cell cpcap_default_devices[] = {
MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,cpcap-adc"),
MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,cpcap-regulator"),
MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,cpcap-usb-phy"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 4, "motorola,cpcap-led-cp"),
};
static const struct mfd_cell cpcap_mapphone_devices[] = {
@@ -252,6 +252,18 @@ static const struct mfd_cell cpcap_mapphone_devices[] = {
MFD_CELL_OF("cpcap-charger", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-charger"),
MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-regulator"),
MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,mapphone-cpcap-usb-phy"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 4, "motorola,cpcap-led-cp"),
+};
+
+/*
+ * The Mot board features a USB-PHY and charger similar to the ones in
+ * Mapphone; however, because Mot is based on Tegra20, it is incompatible
+ * with the existing implementation, which is tightly interconnected with
+ * the OMAP USB PHY.
+ */
+static const struct mfd_cell cpcap_mot_devices[] = {
+ MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,mot-cpcap-adc"),
+ MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,mot-cpcap-regulator"),
};
static int cpcap_probe(struct spi_device *spi)
@@ -276,6 +288,10 @@ static int cpcap_probe(struct spi_device *spi)
cells = cpcap_mapphone_devices;
num_cells = ARRAY_SIZE(cpcap_mapphone_devices);
break;
+ case CPCAP_MOT:
+ cells = cpcap_mot_devices;
+ num_cells = ARRAY_SIZE(cpcap_mot_devices);
+ break;
default:
return dev_err_probe(&spi->dev, -ENODEV,
"Unknown device %d\n", cpcap->variant);
@@ -327,6 +343,7 @@ static int cpcap_probe(struct spi_device *spi)
static const struct of_device_id cpcap_of_match[] = {
{ .compatible = "motorola,cpcap", .data = (void *)CPCAP_DEFAULT },
{ .compatible = "motorola,mapphone-cpcap", .data = (void *)CPCAP_MAPPHONE },
+ { .compatible = "motorola,mot-cpcap", .data = (void *)CPCAP_MOT },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, cpcap_of_match);
@@ -334,6 +351,7 @@ MODULE_DEVICE_TABLE(of, cpcap_of_match);
static const struct spi_device_id cpcap_spi_ids[] = {
{ "cpcap", CPCAP_DEFAULT },
{ "mapphone-cpcap", CPCAP_MAPPHONE },
+ { "mot-cpcap", CPCAP_MOT },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
index 1a85b06272c8..bb23363eeccd 100644
--- a/include/linux/mfd/motorola-cpcap.h
+++ b/include/linux/mfd/motorola-cpcap.h
@@ -28,6 +28,7 @@
enum cpcap_variant {
CPCAP_DEFAULT = 1,
CPCAP_MAPPHONE,
+ CPCAP_MOT,
CPCAP_MAX
};
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
From: sashiko-bot @ 2026-06-25 8:18 UTC (permalink / raw)
To: DevExalt; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260625080807.74157-1-exalt.dev.team@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Use-After-Destroy of `multiplatform_lock` and race with hardware teardown due to deferred sysfs cleanup.
- [Medium] The `platform` sysfs attribute is exposed before IO is re-enabled, causing writes to time out and drop packets.
- [Low] The `platform` sysfs attribute documentation incorrectly claims it supports read operations.
--
commit b016243fdd25010c24333aa504f62dd4e1905e09
Author: Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
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.
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 90b0184df777f..a41fac1b4d82d 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
[ ... ]
> @@ -4423,6 +4427,379 @@ 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.
> + *
> + * Devices that implement this feature expose a per-device sysfs attribute
> + * "platform". Writing one of (windows|winemb|linux|chrome|android|
> + * macos|ios|webos|tizen) selects the matching platform descriptor on the device;
> + * reading reports the platform last applied through this attribute, or an empty
> + * line if none has been set.
> + */
[Severity: Low]
This isn't a bug, but the comment mentions that reading reports the platform
last applied. However, the sysfs attribute is declared as Write-Only using
DEVICE_ATTR_WO(platform) further below.
Should this block comment be updated, or was a read function intended to be
included?
[ ... ]
> +static ssize_t platform_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct hid_device *hdev = to_hid_device(dev);
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> + char platform[16];
> + int idx;
> + int ret;
> +
> + strscpy(platform, buf, sizeof(platform));
> + string_lower(platform, platform);
> +
> + idx = sysfs_match_string(multiplatform_names, platform);
> + if (idx < 0)
> + return idx;
> +
> + mutex_lock(&hidpp->multiplatform_lock);
[Severity: High]
Does this create a use-after-destroy regression?
Because devm_device_add_group() is used in hidpp_multiplatform_init(), the
sysfs attribute group is removed only after hidpp_remove() returns.
If hidpp_remove() destroys the multiplatform_lock via mutex_destroy(), could a
concurrent userspace write to the platform sysfs attribute attempt to lock
the destroyed mutex here?
> + ret = hidpp_multiplatform_set_platform(hidpp, multiplatform_masks[idx]);
> + mutex_unlock(&hidpp->multiplatform_lock);
> + if (ret)
> + return ret;
> +
> + hid_dbg(hdev, "Multiplatform: Device platform set to '%s'\n",
> + multiplatform_names[idx]);
> +
> + return count;
> +}
[ ... ]
> @@ -4517,6 +4895,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);
[Severity: Medium]
Will writes to the sysfs attribute time out here?
By initializing the sysfs attribute group in hidpp_multiplatform_init() and
immediately stopping IO with hid_device_io_stop(), the driver creates a
window where writes from userspace are possible but IO responses are blocked.
If a write happens before hid_device_io_start() is called later in probe,
could hidpp_send_fap_command_sync() wait for a response that never arrives,
causing a -ETIMEDOUT error and dropping packets?
> ret = hid_connect(hdev, connect_mask);
[ ... ]
> @@ -4576,6 +4957,7 @@ static void hidpp_remove(struct hid_device *hdev)
> cancel_work_sync(&hidpp->work);
> cancel_work_sync(&hidpp->reset_hi_res_work);
> mutex_destroy(&hidpp->send_mutex);
> + mutex_destroy(&hidpp->multiplatform_lock);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625080807.74157-1-exalt.dev.team@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: sashiko-bot @ 2026-06-25 8:21 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-leds, linux-input, lee, conor+dt, robh, devicetree,
dmitry.torokhov
In-Reply-To: <20260625081529.22447-2-clamor95@gmail.com>
> Document embedded controller used in ASUS Transformer device series.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v9 5/7] leds: Add driver for ASUS Transformer LEDs
From: sashiko-bot @ 2026-06-25 8:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, linux-input, dmitry.torokhov, robh, devicetree,
linux-leds, lee
In-Reply-To: <20260625081529.22447-6-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> ASUS Transformer tablets have a green and an amber LED on both the Pad
> and the Dock. If both LEDs are enabled simultaneously, the emitted light
> will be yellow.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v9 7/7] power: supply: Add charger driver for Asus Transformers
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, dmitry.torokhov, robh, lee, linux-leds, conor+dt,
devicetree
In-Reply-To: <20260625081529.22447-8-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add support for charger detection capabilities found in the embedded
> controller of ASUS Transformer devices.
>
> Suggested-by: Maxim Schwalm <maxim.schwalm@gmail.com>
> Suggested-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH v6 2/6 RESEND] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, devicetree, linux-leds, linux-input, robh, lee,
dmitry.torokhov
In-Reply-To: <20260625081812.33474-3-clamor95@gmail.com>
> Convert power button devicetree bindings for the Motorola CPCAP MFD from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v6 6/6 RESEND] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, linux-leds, dmitry.torokhov, conor+dt, linux-input,
devicetree, lee
In-Reply-To: <20260625081812.33474-7-clamor95@gmail.com>
> Add a MFD subdevice composition used in Tegra20 based Mot board
> (Motorola Atrix 4G and Droid X2).
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Krzysztof Kozlowski @ 2026-06-25 8:23 UTC (permalink / raw)
To: Dmitry Torokhov, David Heidelberg
Cc: Krzysztof Kozlowski, Konrad Dybcio, Rob Herring, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <ajxakXFuKAkhdZLN@google.com>
On 25/06/2026 06:53, Dmitry Torokhov wrote:
> On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
>> On 24/06/2026 06:28, Dmitry Torokhov wrote:
>>> Hi David,
>>>
>>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>>>> On 28/05/2026 00:13, David Heidelberg wrote:
>>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>
>>>>>>> We know the driver is reporting s3706b, introduce the compatible so we
>>>>>>> can more easily introduce quirks for weird touchscreen replacements in
>>>>>>> followup series.
>>>>>>>
>>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>>>>> ---
>>>>>>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>> b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>> index 6b7378cf4d493..148164d456a5a 100644
>>>>>>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>> @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
>>>>>>> };
>>>>>>> };
>>>>>>> &i2c12 {
>>>>>>> status = "okay";
>>>>>>> clock-frequency = <400000>;
>>>>>>> synaptics-rmi4-i2c@20 {
>>>>>>> - compatible = "syna,rmi4-i2c";
>>>>>>> + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
>>>>>>
>>>>>> So I believe we established that this device (s3706b) does not in fact
>>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>>>
>>>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>>>
>>>>> The 3rd party replacement impersonating original parts may not implement
>>>>> it properly, but I don't address this issue in this initial submission.
>>>>>
>>>>> With this compatible we know which original part is used by the vendor
>>>>> and installed in the phones, so later we can deduct specific sequences
>>>>> for the replacement aftermarket parts to keep phone touchscreen working
>>>>> same as they do on Android without affecting other devices.
>>>>
>>>> Hello Dmitry.
>>>>
>>>> May I ask what is currently preventing this series from moving forward?
>>>>
>>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>>>> and am now on the 9th iteration (this patchset). At this point, the series
>>>> has been under discussion for well over a year, with relatively little
>>>> feedback and increasingly long gaps between review rounds.
>>>>
>>>> The current approach is based on the guidance I have received so far,
>>>> including suggestions from the device-tree maintainers. When concerns were
>>>> raised, I tried to address them and rework the series accordingly.
>>>>
>>>> What I am struggling with is understanding what specific issue still needs
>>>> to be resolved before these patches can be accepted. If there are remaining
>>>> requirements, objections to the approach, or technical concerns that I have
>>>> not addressed, I would appreciate having them stated explicitly so I can
>>>> work on them.
>>>>
>>>> I also split out the straightforward, self-contained changes in the hope
>>>> that at least those could progress independently while I continued working
>>>> on any follow-up requirements. However, even those patches do not appear to
>>>> be moving forward.
>>>>
>>>> Could you please clarify what outcome you would like to see from this
>>>> series, and what concrete changes would be required to get it accepted?
>>>
>>> I am still confused about how you want to differentiate between the full
>>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
>>> mentioned, implements RMI4 protocol properly, so we do not need to
>>> actually have it documented neither in binding nor in DTS.
>>
>> --- part 1 ---
>>
>> This series addresses identification within device-tree. It's normal
>> recommended practice.
>>
>> If we know, the device ships specific, but **compliant** variant, we just
>> put it as compatible = "more-specific", "less-specific"; in this case
>> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>>
>> This approach is used everywhere. This has nothing to do with after-market parts.
>
> We do this in many cases, sometimes when a part has different timings or
> maybe additional functionality compared to the base model.
Generic expectation is to have always dedicated front compatible for
every device. rmi4-i2c is not really specific enough, more like a
family, thus a specific device compatible is essential by the DT rules.
It does not matter if that specific compatible is ever used.
>
> How does this new compatible for controller that fully implements RMI4
> protocol help here?
It does not matter. This is a different device, thus it needs
front-specific compatible.
Also, the commit msg actually did mention how this helps: allowing
further quirks (I did not verify that in practice, but explanation is
plausible).
>
>>
>> --- part 2 (irrelevant for this series) ---
>>
>>>
>>> The issue you have with after-market parts that are not compliant and we
>>> need to figure out how to deal with them. Inside the driver I
>>
>> As was suggested by device-tree folks, this is the first step, there isn't
>> better one available. If there is, please suggest one, and I'll apply it.
>
> Was it clearly communicated to DT folks that the compatible you are
> adding is fully compatible with the base "syna,rmi4-i2c" but other ones
> will not be compatible?
That was not communicated but also did not have to. You can install in
your board whatever you wish, e.g. replacing foo device with bar being
something completely different and incompatible. Does not matter really
if this is after-market or a person just swapped things.
DT does not solve that problem simply, because we describe static
hardware configuration.
>
>>
>>> essentially need a"incomplete protocol" flag that we can use to
>>> implement additional checks or skip known to be not implemented
>>> functions/queries. In DT we could introduce something like
>>> "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
>>> and neither one should be a fallback for the other.
>>>
>>> This of course needs buy-in from DT maintainers.
>>
>> As you can see, this still holds Acked-by and Reviewed-by from the relevant
>> people - Krzysztof and Konrad.
>
> I see that but the commit does not explain how exactly you are planning
> to deal with knockoffs.
I think it does not have to. David does not need to solve all possible
problems. He is solving his problems and not preventing the other
problems to be solved in the future. Unless you expect that the second
part - future problems - will be blocked by this code.
But then I think no one ever solved in DT a problem of replacement of
valid parts with after-market incompatible parts. Therefore I do not
even know what solution I could suggest to David.
>
>>
>>>
>>> Does this make sense?
>>
>> For the scope we're discussing it doesn't seems so.
>>
>> This discussion should be associated with the last revision of the full
>> series I sent 3 months ago. We're in very unflattering state, where:
>>
>> 2018 - these aftermarket touchscreen worked on Android well enough for
>> people to have working touch (let's say with slightly worse experience then
>> the original).
>>
>> 2026 in the mainline, we cannot even more forward and report to user-space
>> there is aftermarket non-compliant piece of hardware installed.
>>
>> Actionable steps I suggest after this series lands:
>>
>> 1. don't do any changes, but since we know what 3rd party touchscreen do
>> incorrectly deviating from the standard, REPORT it to the userspace, so USER
>> know, their device (phone/tablet) doesn't have original part.
>>
>> 2. then figure out, IF we can reasonably well workaround it and HOW to do it
>>
>> These two steps present some progress which could be discussed and could
>> lead us somewhere, what do you think?
>
> So since we know that these devices can come with controllers that do
> not implement RMI4 fully, can we:
>
> 1. Establish a new compatible that is separate from syna,rmi4-i2c? As I
> mentioned, it could be oneplus,rmi4-i2c or event a concrete controller
> vendor,id combo. The point that it should be completely separate from
> the current compatible and not use the current compatible as a fallback.
Board/machine level compatible already gives you that.
after-market-incompatible-parts is not a problem of this s3706b, if I
understood correctly. It feels to me more of a problem of the board:
people install into this board some incompatible replacement parts.
I would understand that this is not a board/machine level problem, if
multiple different boards with s3706b were affected. Is this the case?
>
> 2. Make modifications to RMI4 implementation to handle these controllers
> in a reasonable manner, but not mess up the full RMI4 support
>
> 3. Update DTS for the affected headsets to switch them to this new
> implementation.2. Make modifications to RMI4 implementation to handle
> these controllers in a reasonable manner, but not mess up the full RMI4
> support
>
> 3. Update DTS for the affected headsets to switch them to this new
> implementation.
>
> Thanks.
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/6 RESEND] dt-bindings: leds: leds-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 8:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, robh, linux-input, dmitry.torokhov, lee, conor+dt,
linux-leds
In-Reply-To: <20260625081812.33474-2-clamor95@gmail.com>
> Convert LEDs devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Krzysztof Kozlowski @ 2026-06-25 8:25 UTC (permalink / raw)
To: Dmitry Torokhov, David Heidelberg
Cc: Krzysztof Kozlowski, Konrad Dybcio, Rob Herring, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <f81e4d83-90d9-47c8-aee9-319df3f8b0fb@kernel.org>
On 25/06/2026 10:23, Krzysztof Kozlowski wrote:
> On 25/06/2026 06:53, Dmitry Torokhov wrote:
>> On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
>>> On 24/06/2026 06:28, Dmitry Torokhov wrote:
>>>> Hi David,
>>>>
>>>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>>>>> On 28/05/2026 00:13, David Heidelberg wrote:
>>>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>
>>>>>>>> We know the driver is reporting s3706b, introduce the compatible so we
>>>>>>>> can more easily introduce quirks for weird touchscreen replacements in
>>>>>>>> followup series.
>>>>>>>>
>>>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>>>>>> ---
>>>>>>>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>> b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>> index 6b7378cf4d493..148164d456a5a 100644
>>>>>>>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>> @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
>>>>>>>> };
>>>>>>>> };
>>>>>>>> &i2c12 {
>>>>>>>> status = "okay";
>>>>>>>> clock-frequency = <400000>;
>>>>>>>> synaptics-rmi4-i2c@20 {
>>>>>>>> - compatible = "syna,rmi4-i2c";
>>>>>>>> + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
>>>>>>>
>>>>>>> So I believe we established that this device (s3706b) does not in fact
>>>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>>>>
>>>>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>>>>
>>>>>> The 3rd party replacement impersonating original parts may not implement
>>>>>> it properly, but I don't address this issue in this initial submission.
>>>>>>
>>>>>> With this compatible we know which original part is used by the vendor
>>>>>> and installed in the phones, so later we can deduct specific sequences
>>>>>> for the replacement aftermarket parts to keep phone touchscreen working
>>>>>> same as they do on Android without affecting other devices.
>>>>>
>>>>> Hello Dmitry.
>>>>>
>>>>> May I ask what is currently preventing this series from moving forward?
>>>>>
>>>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>>>>> and am now on the 9th iteration (this patchset). At this point, the series
>>>>> has been under discussion for well over a year, with relatively little
>>>>> feedback and increasingly long gaps between review rounds.
>>>>>
>>>>> The current approach is based on the guidance I have received so far,
>>>>> including suggestions from the device-tree maintainers. When concerns were
>>>>> raised, I tried to address them and rework the series accordingly.
>>>>>
>>>>> What I am struggling with is understanding what specific issue still needs
>>>>> to be resolved before these patches can be accepted. If there are remaining
>>>>> requirements, objections to the approach, or technical concerns that I have
>>>>> not addressed, I would appreciate having them stated explicitly so I can
>>>>> work on them.
>>>>>
>>>>> I also split out the straightforward, self-contained changes in the hope
>>>>> that at least those could progress independently while I continued working
>>>>> on any follow-up requirements. However, even those patches do not appear to
>>>>> be moving forward.
>>>>>
>>>>> Could you please clarify what outcome you would like to see from this
>>>>> series, and what concrete changes would be required to get it accepted?
>>>>
>>>> I am still confused about how you want to differentiate between the full
>>>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
>>>> mentioned, implements RMI4 protocol properly, so we do not need to
>>>> actually have it documented neither in binding nor in DTS.
>>>
>>> --- part 1 ---
>>>
>>> This series addresses identification within device-tree. It's normal
>>> recommended practice.
>>>
>>> If we know, the device ships specific, but **compliant** variant, we just
>>> put it as compatible = "more-specific", "less-specific"; in this case
>>> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>>>
>>> This approach is used everywhere. This has nothing to do with after-market parts.
>>
>> We do this in many cases, sometimes when a part has different timings or
>> maybe additional functionality compared to the base model.
>
> Generic expectation is to have always dedicated front compatible for
> every device. rmi4-i2c is not really specific enough, more like a
> family, thus a specific device compatible is essential by the DT rules.
>
> It does not matter if that specific compatible is ever used.
>
>>
>> How does this new compatible for controller that fully implements RMI4
>> protocol help here?
>
> It does not matter. This is a different device, thus it needs
> front-specific compatible.
>
> Also, the commit msg actually did mention how this helps: allowing
> further quirks (I did not verify that in practice, but explanation is
> plausible).
>
>>
>>>
>>> --- part 2 (irrelevant for this series) ---
>>>
>>>>
>>>> The issue you have with after-market parts that are not compliant and we
>>>> need to figure out how to deal with them. Inside the driver I
>>>
>>> As was suggested by device-tree folks, this is the first step, there isn't
>>> better one available. If there is, please suggest one, and I'll apply it.
>>
>> Was it clearly communicated to DT folks that the compatible you are
>> adding is fully compatible with the base "syna,rmi4-i2c" but other ones
>> will not be compatible?
>
> That was not communicated but also did not have to. You can install in
> your board whatever you wish, e.g. replacing foo device with bar being
> something completely different and incompatible. Does not matter really
> if this is after-market or a person just swapped things.
>
> DT does not solve that problem simply, because we describe static
> hardware configuration.
>
>>
>>>
>>>> essentially need a"incomplete protocol" flag that we can use to
>>>> implement additional checks or skip known to be not implemented
>>>> functions/queries. In DT we could introduce something like
>>>> "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
>>>> and neither one should be a fallback for the other.
>>>>
>>>> This of course needs buy-in from DT maintainers.
>>>
>>> As you can see, this still holds Acked-by and Reviewed-by from the relevant
>>> people - Krzysztof and Konrad.
>>
>> I see that but the commit does not explain how exactly you are planning
>> to deal with knockoffs.
>
> I think it does not have to. David does not need to solve all possible
> problems. He is solving his problems and not preventing the other
> problems to be solved in the future. Unless you expect that the second
> part - future problems - will be blocked by this code.
>
> But then I think no one ever solved in DT a problem of replacement of
> valid parts with after-market incompatible parts. Therefore I do not
> even know what solution I could suggest to David.
... maybe except DT overlays. This DTS would be correct and if anyone
installs replacement part which is not compatible, then just use overlay
changing the compatible. The idea of manually (per-user) altering
hardware is matching the concept behind DT overlays.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Konrad Dybcio @ 2026-06-25 8:25 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <82253653-bd85-45b8-8520-e2bb213ca48f@oss.qualcomm.com>
On 6/17/26 12:12 PM, Fenglin Wu wrote:
>
> On 6/17/2026 5:30 PM, Konrad Dybcio wrote:
>> On 6/17/26 4:31 AM, Fenglin Wu wrote:
>>>>> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + }
>>>>> +
>>>>> + for (; i < len; i++) {
>>>>> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + }
>>>> So if i'm reading this right, the first loop will always write
>>>> 4*(len//4) bytes and the second one will be entered at most once,
>>>> to write len rem 4 bytes.. should this be an if instead?
>>> I should put a comment for clarification. Here’s some background: FIFO data writing supports both 4-byte bulk writes using registers [HAP_PTN_FIFO_DIN_0_REG ... HAP_PTN_FIFO_DIN_3_REG], and 1-byte writes using the HAP_PTN_FIFO_DIN_1B_REG register. The 4-byte bulk write is more efficient, especially for waveform which has several Kb data, and it helps to reduce software latency when loading effects and reduce the delay in triggering vibration. It also helps prevent the FIFO from running dry during data refill in FIFO-empty interrupts. Typically, we use 4-byte writes for the initial 4-byte aligned data, and 1-byte writes for any trailing remainder.
>>>
>>> So it still needs a 'for' loop here since the remainder could be more than 1 byte.
>> Right, I mentioned len rem 4 but failed to notice it's a
>> single-byte write.. anyway, a comment here would be good
>>
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * Configure the hardware FIFO memory boundary.
>>>>> + * FIFO occupies addresses [0, fifo_len).
>>>>> + */
>>>>> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
>>>>> +{
>>>>> + u32 fifo_len, fifo_units;
>>>>> +
>>>>> + /* Config all memory space for FIFO usage for now */
>>>> What's the not-"for now" endgame for this?
>>> The hardware supports more modes than the two currently supported in the driver. One of these, called 'PAT_MEM' mode, also shares memory space with FIFO mode. However, 'PAT_MEM' requires memory to be pre-reserved and waveform data to be pre-loaded. The entire 8K bytes of memory can be divided into partitions, and it is configurable, with FIFO mode always using the first partition [0, fifo_len], where 'fifo_len' is set via the 'MMAP_FIFO_REG' register. 'PAT_MEM' mode plays waveform using data preloaded in a memory bank defined by the registers 'PATX_MEM_START_ADDR_REG' and 'PATTERN_SPMI_PATX_LEN_REG' (they are not defined in the driver). Since PAT_MEM is mainly intended for hardware-triggered vibrations, such as a signal from a dedicated GPIO triggering a short vibration with a preloaded waveform, and although it also supports software triggers, I haven't found a suitable way to support it well into the driver under input FF framework yet. So, I am currently allocating the
>>> entire 8K FIFO memory for FIFO mode only. We can adjust this later if we find a better way to incorporate 'PAT_MEM' mode into the driver.
>> Sounds like a plan.
>>
>> For the other mode, would that GPIO trigger need any OS intervention?
>> Could you speak a bit more about how that works?
>>
>> Konrad
>
> I'll try to clarify the 'PAT_MEM' mode further. 'PAT_MEM' is useful for latency-sensitive vibrations because it preloads the waveform into a fixed memory bank, then it doesn't need to load the data of the effect in the HW before triggering the play. When playback is triggered, it plays the waveform from the specified memory address and length. This memory should be preserved, and the data is preloaded during boot. Unlike FIFO mode, it doesn't allow data refilling. The trigger can come from hardware via dedicated GPIOs—currently, three are supported, each mapping to a memory bank set through specific registers. Software configuration can be done in the bootloader or in the driver probe, but the 'fifo_len' should be adjusted accordingly. After setup, software doesn't need to manage it further, relying on the GPIO signal to activate the playback (for example, a pressure sensor triggering vibration to simulate a physical key press). The trigger can also come from software using
> SPMI commands by setting the play mode, start address, and data length. I previously tried using the 'FF_HAPTIC' effect by mapping 'hid_usage' to a predefined effect in the devicetree, but later I found it unsuitable since 'FF_HAPTIC' is mainly for USB HID touch devices and not general vibration usage. If you have any suggestions for supporting 'PAT_MEM' mode through the input FF framework, please let me know.
I don't really know much about this part of the kernel, but at a glance
FF_HAPTIC seems to be roughly what we're after - quoting the cover letter
of the series that introduced it:
<quote>
Haptic control
..............
The HID protocol described in HUTRR63[3] must be used.
The following waveforms should be supported:
| WAVEFORMNONE | Implicit waveforms required by protocol |
| WAVEFORMSTOP | |
| ------------------------ | ------------------------------------------------- |
| WAVEFORMPRESS | To be used to simulate button press. In device- |
| | controlled mode, it will also be used to simulate |
| | button release. |
| ------------------------ | ------------------------------------------------- |
| WAVEFORMRELEASE | To be used to simulate button release. |
All waveforms will have an associated duration; continuous waveforms will be
ignored by the kernel.
</quote>
(i.e. reword 'press' to 'trigger' and we're mostly there?)
I'd start prototyping in that area (maybe taking it out of drivers/hid/)
and see where it goes. However as I mentioned, this may as well be my
wishful thinking.
Konrad
^ permalink raw reply
* Re: [PATCH v9 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: sashiko-bot @ 2026-06-25 8:25 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, linux-input, dmitry.torokhov, lee, devicetree, conor+dt,
linux-leds
In-Reply-To: <20260625081529.22447-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Explicitly calling `input_unregister_device()` on a device allocated with `devm_input_allocate_device()`.
--
commit b1b4cf8c044b790c2019bf0bb44a52ad2de52358
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: keyboard: Add driver for ASUS Transformer dock multimedia keys
This patch adds support for the multimedia top button row of the ASUS
Transformer's Mobile Dock keyboard. It tracks keyboard input events for
AltGr presses to switch to multimedia keys.
> diff --git a/drivers/input/keyboard/asus-transformer-ec-keys.c b/drivers/input/keyboard/asus-transformer-ec-keys.c
> new file mode 100644
> index 0000000000000..53aff3ce7146d
> --- /dev/null
> +++ b/drivers/input/keyboard/asus-transformer-ec-keys.c
[ ... ]
> +static int asus_ec_keys_probe(struct platform_device *pdev)
> +{
> + struct i2c_client *parent = to_i2c_client(pdev->dev.parent);
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct device *dev = &pdev->dev;
> + struct asus_ec_keys_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> + priv->ec = ec;
> +
> + priv->xidev = devm_input_allocate_device(dev);
[ ... ]
> + error = input_register_device(priv->xidev);
> + if (error)
> + return dev_err_probe(dev, error,
> + "failed to register extension keys\n");
> +
> + error = asus_ec_keys_register_handler(dev, priv);
> + if (error) {
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Since priv->xidev is allocated with devm_input_allocate_device() earlier in
asus_ec_keys_probe(), does explicitly calling input_unregister_device()
here in the error path lead to a double-unregistration when the managed API
automatic cleanup triggers?
> + return error;
> + }
> +
> + priv->nb.notifier_call = asus_ec_keys_notify;
> +
> + error = blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
> + if (error) {
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Could manually unregistering the devm-managed input device here in the
notifier registration error path similarly cause a double-unregistration?
> + input_unregister_handler(&priv->input_handler);
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static void asus_ec_keys_remove(struct platform_device *pdev)
> +{
> + struct asus_ec_keys_data *priv = platform_get_drvdata(pdev);
> + struct asusec_core *ec = priv->ec;
> +
> + blocking_notifier_chain_unregister(&ec->notify_list, &priv->nb);
> + input_unregister_handler(&priv->input_handler);
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Does bypassing the automatic devm lifecycle by explicitly calling
input_unregister_device() in asus_ec_keys_remove() on a managed device lead
to double-unregistration when the device is unbound?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v9 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: sashiko-bot @ 2026-06-25 8:26 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, lee, linux-input, devicetree, robh, linux-leds,
dmitry.torokhov
In-Reply-To: <20260625081529.22447-3-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Support Nuvoton NPCE795-based ECs as used in Asus Transformer TF201,
> TF300T, TF300TG, TF300TL and TF700T pad and dock, as well as TF101 dock
> and TF600T, P1801-T and TF701T pad. This is a glue driver handling
> detection and common operations for EC's functions.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v9 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: sashiko-bot @ 2026-06-25 8:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, conor+dt, linux-input, devicetree, robh,
linux-leds, lee
In-Reply-To: <20260625081529.22447-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Premature registration of the event notifier before callback initialization causes a race condition leading to a NULL pointer dereference.
- [High] Incorrect devres ordering leaves the notifier active after serio ports are destroyed, causing a Use-After-Free during teardown.
- [High] Incorrect bounds check on the EC packet length allows an out-of-bounds heap read and exposes uninitialized memory.
--
commit 27a9e7909b45cc654374940aa7f4c4574172729b
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
Add input driver for ASUS Transformer dock keyboard and touchpad. Modify
incoming keyboard data to send proper scancodes for keys that don't match
their position.
> diff --git a/drivers/input/serio/asus-transformer-ec-kbc.c b/drivers/input/serio/asus-transformer-ec-kbc.c
> new file mode 100644
> index 0000000000000..3ddfa9925b2b0
> --- /dev/null
> +++ b/drivers/input/serio/asus-transformer-ec-kbc.c
[ ... ]
> +static int asus_ec_kbc_notify(struct notifier_block *nb,
> + unsigned long action, void *data_)
> +{
[ ... ]
> + /*
> + * The data[0] is the length of the packet including itself. The data[]
> + * buffer has to be at least 3 bytes (length + ctrl + 1 data byte) and
> + * must not exceed the EC buffer size.
> + */
> + if (data[0] < 2 || data[0] > ASUSEC_ENTRY_BUFSIZE)
> + return NOTIFY_BAD;
> +
> + n = data[0] - 1;
> + data += 2;
[ ... ]
> + while (n--)
> + serio_interrupt(priv->sdev[port_idx], *data++, 0);
[Severity: High]
If data[0] is ASUSEC_ENTRY_BUFSIZE (33), n becomes 32, and data is advanced
by 2. Will the loop read 32 bytes from data[2] up to data[33]?
Since the buffer is exactly 33 bytes long, could this read past the end of
the array or access uninitialized data?
> +
> + return NOTIFY_OK;
> +}
[ ... ]
> +static int asus_ec_kbc_probe(struct platform_device *pdev)
> +{
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct asus_ec_kbc_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->ec = ec;
> + priv->parent = to_i2c_client(pdev->dev.parent);
> +
> + error = blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
[Severity: High]
Is it safe to register the notifier here before priv->nb.notifier_call is
initialized?
If an interrupt fires immediately after registration, could the notifier core
attempt to call a NULL pointer?
> + if (error)
> + return dev_err_probe(&pdev->dev, error,
> + "failed to register blocking notifier chain");
> +
> + error = devm_add_action_or_reset(&pdev->dev,
> + asus_ec_notifier_chain_unregister,
> + priv);
[Severity: High]
Since managed resources (devm) are released in LIFO order, will the serio
ports registered below be unregistered and freed before this notifier is
unregistered?
If an interrupt arrives during the unbind window or if the probe function
fails after port registration, could the notifier loop in asus_ec_kbc_notify()
dereference the freed serio port pointers?
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 0, "Keyboard", 0);
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 1, "Touchpad", I8042_CMD_AUX_SEND);
> + if (error)
> + return error;
> +
> + priv->nb.notifier_call = asus_ec_kbc_notify;
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v6 4/6 RESEND] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: sashiko-bot @ 2026-06-25 8:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, devicetree, lee, conor+dt, dmitry.torokhov, linux-input,
linux-leds
In-Reply-To: <20260625081812.33474-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added device tree compatible strings `motorola,mapphone-cpcap` and `motorola,mot-cpcap` are defined as a standalone enum without a fallback, forcing device trees to either break schema validation or break OMAP platform initialization.
--
commit 6926040210bec2501eaa0528dd29bde0ac318c6c
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> --- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> @@ -14,9 +14,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: motorola,cpcap
> - - const: st,6556002
> + oneOf:
> + - enum:
> + - motorola,mapphone-cpcap
> + - motorola,mot-cpcap
[Severity: High]
Will this schema change break OMAP platform initialization for devices
using these new variants?
The schema defines the new compatibles as a standalone enum. However, the
OMAP platform initialization code explicitly relies on finding a node with the
generic motorola,cpcap compatible to configure the PMIC:
arch/arm/mach-omap2/pmic-cpcap.c:omap4_cpcap_init() {
...
if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
return -ENODEV;
...
}
If a device tree conforms to this new schema (using only the specific variant
compatible), the platform code will fail to find the node, breaking PMIC setup
and CPU voltage scaling.
Conversely, if a device tree defines an items array using motorola,cpcap as a
fallback to successfully initialize the platform code, it will fail schema
validation because this oneOf block expects either a standalone enum or the
specific ["motorola,cpcap", "st,6556002"] items list.
Should the new variants include motorola,cpcap as a fallback in an items
array, or does the OMAP platform code need an update to recognize these
new standalone compatibles?
> +
> + - items:
> + - const: motorola,cpcap
> + - const: st,6556002
>
> reg:
> maxItems: 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v6 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: sashiko-bot @ 2026-06-25 8:29 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, linux-input, conor+dt, linux-leds, robh, lee,
dmitry.torokhov
In-Reply-To: <20260625081812.33474-6-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Repurposing the `motorola,cpcap` compatible string and removing `st,6556002` breaks backwards compatibility with existing Device Trees.
- [Low] Direct cast from `const void *` to `enum cpcap_variant` will cause a `-Wpointer-to-int-cast` compiler warning on 64-bit architectures.
--
commit bcc834e6accda9ec696d0ed365c9e5ada87bff4f
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: motorola-cpcap: diverge configuration per-board
MFD have rigid subdevice structure which does not allow flexible dynamic
subdevice linking. Address this by diverging CPCAP subdevice composition
to take into account board specific configuration.
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index d8243b956f875..5b6ca6b81c232 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
[ ... ]
> @@ -241,62 +229,58 @@ static int cpcap_resume(struct device *dev)
[ ... ]
> +static const struct mfd_cell cpcap_default_devices[] = {
> + MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,cpcap-adc"),
> + MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,cpcap-regulator"),
> + MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,cpcap-usb-phy"),
> +};
[Severity: Critical]
Does repurposing the default configuration break backwards compatibility with
existing Device Trees?
Existing hardware using the "motorola,cpcap" compatible string will now
use this generic array. It completely omits the charger and uses non-Mapphone
of_compatible strings, which will prevent existing child nodes (like
"motorola,mapphone-cpcap-adc") from successfully binding.
[ ... ]
> static int cpcap_probe(struct spi_device *spi)
> {
> struct cpcap_ddata *cpcap;
> + const struct mfd_cell *cells;
> + unsigned int num_cells;
> int ret;
>
> cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
> if (!cpcap)
> return -ENOMEM;
>
> + cpcap->variant = (enum cpcap_variant)spi_get_device_match_data(spi);
[Severity: Low]
Will this direct cast from const void * to enum cpcap_variant cause a
-Wpointer-to-int-cast compiler warning when building on 64-bit architectures?
[ ... ]
> @@ -331,10 +315,29 @@ static int cpcap_probe(struct spi_device *spi)
[ ... ]
> +static const struct of_device_id cpcap_of_match[] = {
> + { .compatible = "motorola,cpcap", .data = (void *)CPCAP_DEFAULT },
> + { .compatible = "motorola,mapphone-cpcap", .data = (void *)CPCAP_MAPPHONE },
> + { /* sentinel */ }
> +};
[Severity: Critical]
Does removing the "st,6556002" compatible string and re-mapping
"motorola,cpcap" to CPCAP_DEFAULT break existing devices?
Devices in the wild using "motorola,cpcap" or "st,6556002" in their
device tree may fail to probe critical PMIC functionality because they
are no longer correctly matched with their required Mapphone components.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v9 6/7] power: supply: Add driver for ASUS Transformer battery
From: sashiko-bot @ 2026-06-25 8:31 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, robh, devicetree, linux-leds, dmitry.torokhov,
linux-input, lee
In-Reply-To: <20260625081529.22447-7-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Driver implements one battery cell per EC controller and supports reading
> of battery status for ASUS Transformer's pad and mobile dock.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=6
^ permalink raw reply
* [PATCH] HID: usbhid: Use seq_buf_putc() in three functions
From: Markus Elfring @ 2026-06-25 9:22 UTC (permalink / raw)
To: linux-input, linux-usb, Benjamin Tissoires, Jiri Kosina,
Mahad Ibrahim
Cc: LKML, kernel-janitors, Woradorn Laodhanadhaworn
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 25 Jun 2026 11:11:26 +0200
A single space character should occasionally be put into a sequence buffer.
Thus use the function “seq_buf_putc” in these implementations.
The source code was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/hid/usbhid/hid-core.c | 2 +-
drivers/hid/usbhid/usbkbd.c | 2 +-
drivers/hid/usbhid/usbmouse.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 96b0181cf819..a755102b8cfe 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1412,7 +1412,7 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
if (dev->product) {
if (dev->manufacturer)
- seq_buf_puts(&hid_name, " ");
+ seq_buf_putc(&hid_name, ' ');
seq_buf_puts(&hid_name, dev->product);
}
diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index 83d4df0d7a45..02abd54eca49 100644
--- a/drivers/hid/usbhid/usbkbd.c
+++ b/drivers/hid/usbhid/usbkbd.c
@@ -302,7 +302,7 @@ static int usb_kbd_probe(struct usb_interface *iface,
if (dev->product) {
if (dev->manufacturer)
- seq_buf_puts(&kbd_name, " ");
+ seq_buf_putc(&kbd_name, ' ');
seq_buf_puts(&kbd_name, dev->product);
}
diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
index b3b2abeee614..9fce51d65cd6 100644
--- a/drivers/hid/usbhid/usbmouse.c
+++ b/drivers/hid/usbhid/usbmouse.c
@@ -150,7 +150,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
if (dev->product) {
if (dev->manufacturer)
- seq_buf_puts(&mouse_name, " ");
+ seq_buf_putc(&mouse_name, ' ');
seq_buf_puts(&mouse_name, dev->product);
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] HID: usbhid: Use seq_buf_putc() in three functions
From: sashiko-bot @ 2026-06-25 9:32 UTC (permalink / raw)
To: Markus Elfring; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <89e9c672-efee-4ed2-9ef5-637ec9707f0b@web.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Replacing `seq_buf_puts()` with `seq_buf_putc()` introduces a NUL-termination bug when the manufacturer string is exactly 127 bytes long, leading to an out-of-bounds read.
--
commit c41669030bdd8635988fc175a1caf4183a28344a
Author: Markus Elfring <elfring@users.sourceforge.net>
HID: usbhid: Use seq_buf_putc() in three functions
This patch updates three probe functions to use seq_buf_putc() instead
of seq_buf_puts() when inserting a single space character into sequence
buffers.
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -1412,7 +1412,7 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
>
> if (dev->product) {
> if (dev->manufacturer)
> - seq_buf_puts(&hid_name, " ");
> + seq_buf_putc(&hid_name, ' ');
[Severity: Medium]
Does this change introduce a missing null termination bug in usbhid_probe()
if the manufacturer string is exactly 127 bytes long?
The previous code using seq_buf_puts() requires two bytes of available
capacity (one for the space, one for the trailing null byte) and safely fails
if there isn't enough room.
Looking at seq_buf_putc(), it only checks if there is room for one byte.
If the sequence buffer is exactly 128 bytes long and already contains 127
characters from dev->manufacturer plus the null terminator, seq_buf_putc()
will overwrite the null terminator at index 127 with a space character.
This leaves hid->name completely unterminated. When exposed to userspace via
sysfs or input ioctls, this could lead to an out-of-bounds read into the
adjacent hid->phys memory field.
> seq_buf_puts(&hid_name, dev->product);
> }
>
> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> --- a/drivers/hid/usbhid/usbkbd.c
> +++ b/drivers/hid/usbhid/usbkbd.c
[ ... ]
> @@ -302,7 +302,7 @@ static int usb_kbd_probe(struct usb_interface *iface,
>
> if (dev->product) {
> if (dev->manufacturer)
> - seq_buf_puts(&kbd_name, " ");
> + seq_buf_putc(&kbd_name, ' ');
[Severity: Medium]
Does this have the same unterminated string issue for kbd->name in
usb_kbd_probe()?
If an untrusted USB device presents a manufacturer string of exactly 127
bytes, this overwrite could allow an out-of-bounds read into the adjacent
kbd->phys array.
> seq_buf_puts(&kbd_name, dev->product);
> }
>
> diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
> --- a/drivers/hid/usbhid/usbmouse.c
> +++ b/drivers/hid/usbhid/usbmouse.c
[ ... ]
> @@ -150,7 +150,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
>
> if (dev->product) {
> if (dev->manufacturer)
> - seq_buf_puts(&mouse_name, " ");
> + seq_buf_putc(&mouse_name, ' ');
[Severity: Medium]
Is mouse->name vulnerable to the same null terminator overwrite here in
usb_mouse_probe()?
Similarly, this could leak the contents of mouse->phys to userspace.
> seq_buf_puts(&mouse_name, dev->product);
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/89e9c672-efee-4ed2-9ef5-637ec9707f0b@web.de?part=1
^ 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