* [PATCH v4 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-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 eea5b2efa80c..487e5456864b 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 v4 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-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 | 411 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
2 files changed, 411 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..eea5b2efa80c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
@@ -0,0 +1,411 @@
+# 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
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ 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
+ - "#address-cells"
+ - "#size-cells"
+
+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>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ 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 v4 2/6] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-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 v4 1/6] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260417071106.21984-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 v4 0/6] mfd: cpcap: convert documentation to schema and add Mot board support
From: Svyatoslav Ryhel @ 2026-04-17 7:11 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
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)
---
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 | 416 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
drivers/mfd/motorola-cpcap.c | 151 ++++++-
7 files changed, 623 insertions(+), 145 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 v3 3/3] arm64: dts: qcom: milos: Add GX clock controller
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Konrad Dybcio,
Jagadeesh Kona
In-Reply-To: <20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com>
Add a node for the GX clock controller, which provides a power domain to
consumers.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..4bd9181ca03e 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1542,6 +1542,16 @@ lpass_ag_noc: interconnect@3c40000 {
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ gxclkctl: clock-controller@3d64000 {
+ compatible = "qcom,milos-gxclkctl";
+ reg = <0x0 0x03d64000 0x0 0x6000>;
+
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&gpucc GPU_CC_CX_GDSC>;
+
+ #power-domain-cells = <1>;
+ };
+
gpucc: clock-controller@3d90000 {
compatible = "qcom,milos-gpucc";
reg = <0x0 0x03d90000 0x0 0x9800>;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] clk: qcom: Add support for GXCLK for Milos
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Jagadeesh Kona, Taniya Das,
Dmitry Baryshkov
In-Reply-To: <20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com>
GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing
clocks for the GPU subsystem on GX power domain. The GX clock controller
driver manages only the GX GDSC and the rest of the resources of the
controller are managed by the firmware.
We can use the existing kaanapali driver for Milos as well since the
GX_CLKCTL_GX_GDSC supported by the Linux driver requires the same
configuration.
Reviewed-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/clk/qcom/Makefile | 2 +-
drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 89d07c35e4d9..462c7615a6d7 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -189,7 +189,7 @@ obj-$(CONFIG_SM_GPUCC_8450) += gpucc-sm8450.o
obj-$(CONFIG_SM_GPUCC_8550) += gpucc-sm8550.o
obj-$(CONFIG_SM_GPUCC_8650) += gpucc-sm8650.o
obj-$(CONFIG_SM_GPUCC_8750) += gpucc-sm8750.o gxclkctl-kaanapali.o
-obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o
+obj-$(CONFIG_SM_GPUCC_MILOS) += gpucc-milos.o gxclkctl-kaanapali.o
obj-$(CONFIG_SM_LPASSCC_6115) += lpasscc-sm6115.o
obj-$(CONFIG_SM_TCSRCC_8550) += tcsrcc-sm8550.o
obj-$(CONFIG_SM_TCSRCC_8650) += tcsrcc-sm8650.o
diff --git a/drivers/clk/qcom/gxclkctl-kaanapali.c b/drivers/clk/qcom/gxclkctl-kaanapali.c
index 40d856378a74..7b0af0ba1e68 100644
--- a/drivers/clk/qcom/gxclkctl-kaanapali.c
+++ b/drivers/clk/qcom/gxclkctl-kaanapali.c
@@ -53,6 +53,7 @@ static const struct qcom_cc_desc gx_clkctl_kaanapali_desc = {
static const struct of_device_id gx_clkctl_kaanapali_match_table[] = {
{ .compatible = "qcom,glymur-gxclkctl" },
{ .compatible = "qcom,kaanapali-gxclkctl" },
+ { .compatible = "qcom,milos-gxclkctl" },
{ .compatible = "qcom,sm8750-gxclkctl" },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: clock: qcom: document the Milos GX clock controller
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Krzysztof Kozlowski
In-Reply-To: <20260417-milos-gxclkctl-v3-0-08f5988c43a2@fairphone.com>
Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and
Power domains (GDSC), but the requirement from the SW driver is to use
the GDSC power domain from the clock controller to recover the GPU
firmware in case of any failure/hangs. The rest of the resources of the
clock controller are being used by the firmware of GPU. This module
exposes the GDSC power domains which helps the recovery of Graphics
subsystem.
Milos can reuse the qcom,kaanapali-gxclkctl.h header due to similarity
of the hardware block, and also reuse of the Linux driver.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
.../bindings/clock/qcom,milos-gxclkctl.yaml | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml
new file mode 100644
index 000000000000..fbcb5d3f3e3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,milos-gxclkctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Power Domain Controller on Milos
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and
+ Power domains (GDSC). This module provides the power domains control
+ of gxclkctl on Qualcomm SoCs which helps the recovery of Graphics subsystem.
+
+ See also:
+ include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,milos-gxclkctl
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ description:
+ Power domains required for the clock controller to operate
+ items:
+ - description: GFX power domain
+ - description: GPUCC(CX) power domain
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@3d64000 {
+ compatible = "qcom,milos-gxclkctl";
+ reg = <0x0 0x03d64000 0x0 0x6000>;
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&gpucc 0>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/3] Add support for GXCLK for Milos
From: Luca Weiss @ 2026-04-17 7:07 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Luca Weiss, Krzysztof Kozlowski,
Jagadeesh Kona, Taniya Das, Dmitry Baryshkov, Konrad Dybcio
Similar to other new SoCs, Milos also contains the GXCLKCTL block that
we need to control for GPU. Add support for it.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v3:
- Replace unevaluatedProperties with additionalProperties
- Pick up tags
- Link to v2: https://patch.msgid.link/20260403-milos-gxclkctl-v2-0-95eb94a7d0a4@fairphone.com
Changes in v2:
- Update casing of binding title, reg goes as second property (Krzysztof)
- Rebase on linux-next
- Pick up tags
- Link to v1: https://lore.kernel.org/r/20260306-milos-gxclkctl-v1-0-00b09ee159a7@fairphone.com
---
Luca Weiss (3):
dt-bindings: clock: qcom: document the Milos GX clock controller
clk: qcom: Add support for GXCLK for Milos
arm64: dts: qcom: milos: Add GX clock controller
.../bindings/clock/qcom,milos-gxclkctl.yaml | 61 ++++++++++++++++++++++
arch/arm64/boot/dts/qcom/milos.dtsi | 10 ++++
drivers/clk/qcom/Makefile | 2 +-
drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
4 files changed, 73 insertions(+), 1 deletion(-)
---
base-commit: f4d9dc7f102a8d7e7fa018ae048aa324349122a4
change-id: 20260306-milos-gxclkctl-8a8372d6a1e0
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH v4 3/3 RESEND] drm/bridge: simple-bridge: Add support for MStar TSUMU88ADT3-LF-1
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064953.20511-1-clamor95@gmail.com>
From: Maxim Schwalm <maxim.schwalm@gmail.com>
A simple HDMI bridge used in ASUS Transformer AiO P1801-T.
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..cc13c98f9be6 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "mstar,tsumu88adt3-lf-1",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/3 RESEND] dt-bindigs: display: extend the simple bridge with MStar TSUMU88ADT3-LF-1 bridge
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064953.20511-1-clamor95@gmail.com>
A simple bridge used in ASUS Transformer AiO P1801-T.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..7636c24906ba 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - mstar,tsumu88adt3-lf-1
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/3 RESEND] dt-bindigs: display: extend the LVDS codec with Triple 10-BIT LVDS Transmitter
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064953.20511-1-clamor95@gmail.com>
From: David Heidelberg <david@ixit.cz>
LVDS transmitter used in the Microsoft Surface RT.
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 7586d681bcc6..0363201f0e61 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -34,6 +34,7 @@ properties:
- items:
- enum:
- doestek,dtc34lm85am # For the Doestek DTC34LM85AM Flat Panel Display (FPD) Transmitter
+ - idt,v103 # For the Triple 10-BIT LVDS Transmitter
- onnn,fin3385 # OnSemi FIN3385
- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/3 RESEND] drm: bridge: add support for Triple 10-BIT
From: Svyatoslav Ryhel @ 2026-04-17 6:49 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
Triple 10-BIT LVDS Transmitter is used in Microsoft Surface RT and
MStar TSUMU88ADT3-LF-1 HDMI bridge is used in ASUS Transformer AiO
P1801-T.
Link to v3: https://lore.kernel.org/lkml/20250824092728.105643-1-clamor95@gmail.com/
---
Changes on switching from v3 to v4:
- rebased on top of v7.0
Changes on switching from v2 to v3:
- place mstar,tsumu88adt3-lf-1 alphabetically
- fix typos
Changes on switching from v1 to v2:
- sort compatible alphabetically in schema
---
David Heidelberg (1):
dt-bindigs: display: extend the LVDS codec with Triple 10-BIT LVDS
Transmitter
Maxim Schwalm (1):
drm/bridge: simple-bridge: Add support for MStar TSUMU88ADT3-LF-1
Svyatoslav Ryhel (1):
dt-bindigs: display: extend the simple bridge with MStar
TSUMU88ADT3-LF-1 bridge
.../devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
3 files changed, 7 insertions(+)
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/1 RESEND] dt-bindings: display: bridge: ssd2825: inherit dsi-controller properties
From: Svyatoslav Ryhel @ 2026-04-17 6:46 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260417064657.20293-1-clamor95@gmail.com>
SSD2825 being RGB-DSI bridge should inherit dsi-controller properties same
way other DSI controllers and DSI bridges do.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/display/bridge/solomon,ssd2825.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml b/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
index e2d293d623b8..760645493031 100644
--- a/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
@@ -10,6 +10,7 @@ maintainers:
- Svyatoslav Ryhel <clamor95@gmail.com>
allOf:
+ - $ref: /schemas/display/dsi-controller.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
@@ -86,7 +87,7 @@ required:
- compatible
- ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/1 RESEND] dt-bindings: display: bridge: ssd2825: inherit dsi-controller properties
From: Svyatoslav Ryhel @ 2026-04-17 6:46 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
SSD2825 being RGB-DSI bridge should inherit dsi-controller properties same
way other DSI controllers and DSI bridges do.
Svyatoslav Ryhel (1):
dt-bindings: display: bridge: ssd2825: inherit dsi-controller
properties
.../devicetree/bindings/display/bridge/solomon,ssd2825.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: socfpga: Add the Agilex7 series SoC's
From: Krzysztof Kozlowski @ 2026-04-17 6:43 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <a75e4553-3db3-491c-a5af-a539e9c8da82@kernel.org>
On 16/04/2026 17:20, Dinh Nguyen wrote:
>
>
> On 4/14/26 07:55, Krzysztof Kozlowski wrote:
>> On 14/04/2026 14:53, Dinh Nguyen wrote:
>>>
>>>
>>> On 4/14/26 02:17, Krzysztof Kozlowski wrote:
>>>> On Mon, Apr 13, 2026 at 09:45:52AM -0500, Dinh Nguyen wrote:
>>>>> The Agilex7 is a series of devices from Altera that are derived from
>>>>> the Agilex family.
>>>>>
>>>>> The Agilex7F device supports PCIE 4.0 and DDR4. The Agilex7I device supports
>>>>> PCIE 5.0 and DDR4, while the Agilex7M device supports DDR4, DDR5, LPDDR5
>>>>> and PCIE 5.0.
>>>>>
>>>>> All other peripherals from these devices are the same as the Agilex
>>>>> device.
>>>>>
>>>>> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
>>>>> ---
>>>>> Documentation/devicetree/bindings/arm/altera.yaml | 10 ++++++++++
>>>>> 1 file changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
>>>>> index 206686f3eebc..5ee09f8d4698 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/altera.yaml
>>>>> +++ b/Documentation/devicetree/bindings/arm/altera.yaml
>>>>> @@ -115,6 +115,16 @@ properties:
>>>>> - intel,socfpga-agilex5-socdk-nand
>>>>> - const: intel,socfpga-agilex5
>>>>>
>>>>> + - description: Agilex7 series F, I and M boards
>>>>> + items:
>>>>> + - enum:
>>>>> + - intel,socfpga-agilex7m-socdk
>>>>> + - enum:
>>>>> + - intel,socfpga-agilex7f
>>>>> + - intel,socfpga-agilex7i
>>>>> + - intel,socfpga-agilex7m
>>>>> + - const: intel,socfpga-agilex
>>>>
>>>> And separate question - why previous soc "agilex" is used as fallback?
>>>> Even more confusing.
>>>>
>>>
>>> You're right. Sorry for the confusion. The Agilex7M, I, F devices are
>>> basically "agilex" devices with some few additions (PCIE, DDR5). Maybe I
>>> should place the Agilex7M/I/F devices into the "agilex" boards area?
>>
>> Compatibles should be specific and not based on families, thus what is
>> "intel,socfpga-agilex"? SoC, right?
>>
>> Then "intel,socfpgaa-agilex7f" is a new SoC, no?
>>
>
> The Agilex7 is re-branded name for the original Agilex soc,
> "intel, socfga-agilex". From a software perspective, they are the same
> device. I looked over the commits to see how I could handle a
> rebranding, but couldn't come up with a conclusion.
The family does not matter. What is "socfga-agilex"? One given soc. Not
a family.
>
> I could create a new SoC like you've suggested:
>
> + - description: Agilex7m boards
> + items:
> + - enum:
> + - altr,socfpga-agilex7m-socdk
> + - const: altr,socfpga-agilex7m
> + - const: altr,socfpga-agilex7
So what is "altr,socfpga-agilex7"? Why SoC has two compatibles?
>
> Or I can use the original "intel,socfpga-agilex"?
>
> + - description: Agilex7m boards
> + items:
> + - enum:
> + - altr,socfpga-agilex7m-socdk
> + - const: altr,socfpga-agilex7m
> + - const: altr,socfpga-agilex
But why? Why are you using one SoC compatible in other context? It's
really no different than all other SoCs.
>
> If I create a new "altr,socfpga-agilex7" binding, then I would have to
> add the new binding to a few drivers. But if I use the original
> "intel,socfpga-agilex", then no drivers will need to be updated.
You anyway MUST have new binding for each device. Please carefully
follow writing bindings and DTS 101.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: anacapa: add interrupt properties for PDB PCA9555
From: Rex Fu via B4 Relay @ 2026-04-17 6:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, Rex Fu
From: Rex Fu <Rex.Fu@amd.com>
Add interrupt-parent and interrupts properties to the PDB PCA9555
nodes in the anacapa DTS.
Signed-off-by: Rex Fu <Rex.Fu@amd.com>
---
Single DTS update for the PDB PCA9555 interrupt wiring on anacapa.
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 2cb7bd128d24..7319f2319bb7 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -481,6 +481,9 @@ gpio@22 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"RPDB_FAN_FULL_SPEED_R_N", "RPDB_I2C_TEMP75_U8_ALERT_R_N",
"RPDB_I2C_TMP432_U29_ALERT_R_N", "RPDB_GLOBAL_WP",
@@ -500,6 +503,9 @@ gpio@24 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"RPDB_EAM2_PRSNT_MOS_N_R", "RPDB_EAM3_PRSNT_MOS_N_R",
"RPDB_PWRGD_P50V_HSC4_SYS_R",
@@ -529,6 +535,9 @@ gpio@22 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"LPDB_FAN_FULL_SPEED_R_N","LPDB_I2C_TEMP75_U8_ALERT_R_N",
"LPDB_I2C_TMP432_U29_ALERT_R_N","LPDB_GLOBAL_WP",
@@ -546,6 +555,9 @@ gpio@24 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"LPDB_P50V_FAN1_R2_PG","LPDB_P50V_FAN2_R2_PG",
"LPDB_P50V_FAN3_R2_PG","LPDB_P50V_FAN4_R2_PG",
---
base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
change-id: 20260417-anacapa-pca9555-irq-3090d4120270
Best regards,
--
Rex Fu <Rex.Fu@amd.com>
^ permalink raw reply related
* Re: [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Anand Moon @ 2026-04-17 6:08 UTC (permalink / raw)
To: Shuwei Wu
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, linux-pm, linux-kernel, linux-riscv,
spacemit, devicetree
In-Reply-To: <CANAwSgRt5-t_ah=phGc+CQYHG-CdWJuOX-2VTW6xE7n7EnVsFw@mail.gmail.com>
Hi Shuwei,
On Thu, 16 Apr 2026 at 17:07, Anand Moon <linux.amoon@gmail.com> wrote:
>
> Hi Shuwei,
>
> Thanks for sharing the details.
>
> On Thu, 16 Apr 2026 at 11:29, Shuwei Wu <shuwei.wu@mailbox.org> wrote:
> >
> > On Tue Apr 14, 2026 at 9:25 PM CST, Anand Moon wrote:
> > > Hi Shuwei,
> > >
> > > On Fri, 10 Apr 2026 at 13:30, Shuwei Wu <shuwei.wu@mailbox.org> wrote:
> > >>
> > >> Add Operating Performance Points (OPP) tables and CPU clock properties
> > >> for the two clusters in the SpacemiT K1 SoC.
> > >>
> > >> Also assign the CPU power supply (cpu-supply) for the Banana Pi BPI-F3
> > >> board to fully enable CPU DVFS.
> > >>
> > >> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> > >>
> > >> ---
> > >> Changes in v2:
> > >> - Add k1-opp.dtsi with OPP tables for both CPU clusters
> > >> - Assign CPU supplies and include OPP table for Banana Pi BPI-F3
> > >> ---
> > >> arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
> > >> arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
> > >> arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
> > >> 3 files changed, 147 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > >> index 444c3b1e6f44..3780593f610d 100644
> > >> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > >> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > >> @@ -5,6 +5,7 @@
> > >>
> > >> #include "k1.dtsi"
> > >> #include "k1-pinctrl.dtsi"
> > >> +#include "k1-opp.dtsi"
> > >>
> > >> / {
> > >> model = "Banana Pi BPI-F3";
> > >> @@ -86,6 +87,38 @@ &combo_phy {
> > >> status = "okay";
> > >> };
> > >>
> > >> +&cpu_0 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_1 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_2 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_3 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_4 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_5 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_6 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> +&cpu_7 {
> > >> + cpu-supply = <&buck1_3v45>;
> > >> +};
> > >> +
> > >> &emmc {
> > >> bus-width = <8>;
> > >> mmc-hs400-1_8v;
> > >> @@ -201,7 +234,7 @@ pmic@41 {
> > >> dldoin2-supply = <&buck5>;
> > >>
> > >> regulators {
> > >> - buck1 {
> > >> + buck1_3v45: buck1 {
> > >> regulator-min-microvolt = <500000>;
> > >> regulator-max-microvolt = <3450000>;
> > >> regulator-ramp-delay = <5000>;
> > >> diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> > >> new file mode 100644
> > >> index 000000000000..768ae390686d
> > >> --- /dev/null
> > >> +++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> > >> @@ -0,0 +1,105 @@
> > >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > >> +
> > >> +/ {
> > >> + cluster0_opp_table: opp-table-cluster0 {
> > >> + compatible = "operating-points-v2";
> > >> + opp-shared;
> > >> +
> > >> + opp-614400000 {
> > >> + opp-hz = /bits/ 64 <614400000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-819000000 {
> > >> + opp-hz = /bits/ 64 <819000000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-1000000000 {
> > >> + opp-hz = /bits/ 64 <1000000000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-1228800000 {
> > >> + opp-hz = /bits/ 64 <1228800000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-1600000000 {
> > >> + opp-hz = /bits/ 64 <1600000000>;
> > >> + opp-microvolt = <1050000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> + };
> > >> +
> > >> + cluster1_opp_table: opp-table-cluster1 {
> > >> + compatible = "operating-points-v2";
> > >> + opp-shared;
> > >> +
> > >> + opp-614400000 {
> > >> + opp-hz = /bits/ 64 <614400000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-819000000 {
> > >> + opp-hz = /bits/ 64 <819000000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-1000000000 {
> > >> + opp-hz = /bits/ 64 <1000000000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-1228800000 {
> > >> + opp-hz = /bits/ 64 <1228800000>;
> > >> + opp-microvolt = <950000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> +
> > >> + opp-1600000000 {
> > >> + opp-hz = /bits/ 64 <1600000000>;
> > >> + opp-microvolt = <1050000>;
> > >> + clock-latency-ns = <200000>;
> > >> + };
> > >> + };
> > >> +};
> > >> +
> > >> +&cpu_0 {
> > >> + operating-points-v2 = <&cluster0_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_1 {
> > >> + operating-points-v2 = <&cluster0_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_2 {
> > >> + operating-points-v2 = <&cluster0_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_3 {
> > >> + operating-points-v2 = <&cluster0_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_4 {
> > >> + operating-points-v2 = <&cluster1_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_5 {
> > >> + operating-points-v2 = <&cluster1_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_6 {
> > >> + operating-points-v2 = <&cluster1_opp_table>;
> > >> +};
> > >> +
> > >> +&cpu_7 {
> > >> + operating-points-v2 = <&cluster1_opp_table>;
> > >> +};
> > >> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> > >> index 529ec68e9c23..bdd109b81730 100644
> > >> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> > >> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> > >> @@ -54,6 +54,7 @@ cpu_0: cpu@0 {
> > >> compatible = "spacemit,x60", "riscv";
> > >> device_type = "cpu";
> > >> reg = <0>;
> > >> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> > >> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> > >> riscv,isa-base = "rv64i";
> > >> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> > >> @@ -84,6 +85,7 @@ cpu_1: cpu@1 {
> > >> compatible = "spacemit,x60", "riscv";
> > >> device_type = "cpu";
> > >> reg = <1>;
> > >> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> > >
> > > Based on the Spacemit kernel source, the k1-x_opp_table.dtsi file
> > > defines several additional clocks for the Operating Performance Points
> > > (OPP) table:
> > >
> > > clocks = <&ccu CLK_CPU_C0_ACE>, <&ccu CLK_CPU_C1_ACE>, <&ccu CLK_CPU_C0_TCM>,
> > > <&ccu CLK_CCI550>, <&ccu CLK_PLL3>, <&ccu
> > > CLK_CPU_C0_HI>, <&ccu CLK_CPU_C1_HI>;
> > > clock-names = "ace0","ace1","tcm","cci","pll3", "c0hi", "c1hi";
> > >
> > > These hardware clocks are also explicitly registered in the APMU clock driver
> > > via the k1_ccu_apmu_hws array, confirming their availability for frequency
> > > and voltage scaling on the K1-X SoC.
> > >
> > > static struct clk_hw *k1_ccu_apmu_hws[] = {
> > > [CLK_CCI550] = &cci550_clk.common.hw,
> > > [CLK_CPU_C0_HI] = &cpu_c0_hi_clk.common.hw,
> > > [CLK_CPU_C0_CORE] = &cpu_c0_core_clk.common.hw,
> > > [CLK_CPU_C0_ACE] = &cpu_c0_ace_clk.common.hw,
> > > [CLK_CPU_C0_TCM] = &cpu_c0_tcm_clk.common.hw,
> > > [CLK_CPU_C1_HI] = &cpu_c1_hi_clk.common.hw,
> > > [CLK_CPU_C1_CORE] = &cpu_c1_core_clk.common.hw,
> > > [CLK_CPU_C1_ACE] = &cpu_c1_ace_clk.common.hw,
> > >
> > > Yes, it is possible to add these clocks for DVFS to work correctly,
> > > provided they are managed by the appropriate driver and declared in
> > > the Device Tree (DT).
> > >
> > > Thanks
> > > -Anand
> >
> > Thanks for your review and for pointing this out.
> >
> > Regarding the clocks you mentioned, I'd like to clarify their roles based on
> > the K1 datasheet. Taking Cluster 0 as an example, c0_core_clk is the primary
> > clock for the cluster. c0_ace_clk and c0_tcm_clk are children derived from it,
> > defaulting to half the frequency of their parent core clock, while c0_hi_clk
> > represents the high-speed path selection.
> > Cluster 1 follows the same structure.
> >
> > Based on the official SpacemiT Bianbu OS source, the spacemit-cpufreq.c driver
> > mainly performs the following tasks:
> > 1. Sets the CCI550 clock frequency to 614MHz.
> > 2. Sets the clock frequencies of c0_ace_clk, c1_ace1_clk, and c0_tcm_clk to half
> > the frequency of their parent clock.
> > 3. For the 1.6GHz OPP, it sets the PLL3 frequency to 3.2GHz and the
> > c0_hi_clk/c1_hi_clk frequencies to 1.6GHz.
> >
> > I booted with the manufacturer's OpenWRT image and used debugfs to confirm that
> > the clock states are exactly as described above.
> >
> > At 1.6GHz:
> > Clock Source & Tree Rate (Hz) HW Enable Consumer
> > ---------------------------------------------------------------------------
> > pll3 3,200,000,000 Y deviceless
> > └─ pll3_d2 1,600,000,000 Y deviceless
> > ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> > │ └─ cpu_c1_pclk 1,600,000,000 Y cpu0
> > │ └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> > └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> > └─ cpu_c0_core_clk 1,600,000,000 Y cpu0
> > ├─ cpu_c0_tcm_clk 800,000,000 Y deviceless
> > └─ cpu_c0_ace_clk 800,000,000 Y deviceless
> >
> > pll1_2457p6_vco 2,457,600,000 Y deviceless
> > └─ pll1_d4 614,400,000 Y deviceless
> > └─ pll1_d4_614p4 614,400,000 Y deviceless
> > └─ cci550_clk 614,400,000 Y deviceless
> >
> > At 1.228GHz:
> > Clock Source & Tree Rate (Hz) HW Enable Consumer
> > ---------------------------------------------------------------------------
> > pll1_2457p6_vco 2,457,600,000 Y deviceless
> > └─ pll1_d2 1,228,800,000 Y deviceless
> > └─ pll1_d2_1228p8 1,228,800,000 Y deviceless
> > ├─ cpu_c0_core_clk 1,228,800,000 Y cpu0
> > │ ├─ cpu_c0_tcm_clk 614,400,000 Y deviceless
> > │ └─ cpu_c0_ace_clk 614,400,000 Y deviceless
> > └─ cpu_c1_pclk 1,228,800,000 Y cpu0
> > └─ cpu_c1_ace_clk 614,400,000 Y deviceless
> > └─ pll1_d4 614,400,000 Y deviceless
> > └─ pll1_d4_614p4 614,400,000 Y deviceless
> > └─ cci550_clk 614,400,000 Y deviceless
> >
> > pll3 3,200,000,000 Y deviceless
> > └─ pll3_d2 1,600,000,000 Y deviceless
> > ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> > └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> > └─ pll3_d3 1,066,666,666 Y deviceless
> >
> > Regarding the necessity of listing these clocks in the DT, my analysis is as follows:
> > 1. For CCI550, I did not find a clear definition of this clock's specific role
> > in the SoC datasheet. Although the vendor kernel increases its frequency,
> > my benchmarks show that maintaining the mainline default (245.76MHz) has a
> > negligible impact on CPU performance.
> > 2. For ACE and TCM clocks, they function as synchronous children of the core
> > clock with a default divide-by-2 ratio. Since they scale automatically relative
> > to c0_core_clk/c1_core_clk and no other peripherals depend on them, they do not
> > require manual management in the OPP table.
> > 3. For the high-speed path, the underlying clock controller logic already handles
> > the parent MUX switching and PLL3 scaling automatically when clk_set_rate()
> > is called on the core clock.
> >
> > I have verified this by checking the hardware state in the mainline kernel.
> > The clock tree matches the vendor kernel's configuration:
> >
> > At 1.6GHz:
> > Clock Source & Tree Rate (Hz) HW Enable Consumer
> > ---------------------------------------------------------------------------
> > pll3 3,200,000,000 Y deviceless
> > └─ pll3_d2 1,600,000,000 Y deviceless
> > ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> > │ └─ cpu_c1_core_clk 1,600,000,000 Y cpu4
> > │ └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> > └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> > └─ cpu_c0_core_clk 1,600,000,000 Y cpu0
> > ├─ cpu_c0_tcm_clk 800,000,000 Y deviceless
> > └─ cpu_c0_ace_clk 800,000,000 Y deviceless
> >
> > pll1 2,457,600,000 Y deviceless
> > └─ pll1_d5 491,520,000 Y deviceless
> > └─ pll1_d5_491p52 491,520,000 Y deviceless
> > └─ cci550_clk 245,760,000 Y deviceless
> >
> > At 1.228GHz:
> > Clock Source & Tree Rate (Hz) HW Enable Consumer
> > ---------------------------------------------------------------------------
> > pll1 2,457,600,000 Y deviceless
> > ├─ pll1_d5 491,520,000 Y deviceless
> > │ └─ pll1_d5_491p52 491,520,000 Y deviceless
> > │ └─ cci550_clk 245,760,000 Y deviceless
> > └─ pll1_d2 1,228,800,000 Y deviceless
> > └─ pll1_d2_1228p8 1,228,800,000 Y deviceless
> > └─ cpu_c0_core_clk 1,228,800,000 Y cpu0
> > ├─ cpu_c0_tcm_clk 614,400,000 Y deviceless
> > └─ cpu_c0_ace_clk 614,400,000 Y deviceless
> >
> > pll3 3,200,000,000 Y deviceless
> > └─ pll3_d2 1,600,000,000 Y deviceless
> > └─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> > └─ cpu_c1_core_clk 1,600,000,000 Y cpu4
> > └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> >
>
> Thanks, I have verified the clocks are set to Y in
> /sys/kernel/debug/clk/clk_summary
>
> > Performance benchmarks also confirm that the current configuration is sufficient:
> > Benchmark (AWK computation): time awk 'BEGIN{for(i=0;i<10000000;i++) sum+=i}'
> > ----------------------------------------------------------------------------
> > Frequency | Mainline Linux (s) | OpenWrt (s)
> > (kHz) | Real (Total) | User (CPU) | Real (Total) | User (CPU) )
> > -------------+---------------+---------------+---------------+--------------
> > 1,600,000 | 1.82s | 1.81s | 1.73s | 1.73s
> > 1,228,800 | 2.34s | 2.33s | 2.26s | 2.26s
> > 1,000,000 | 2.94s | 2.86s | 2.78s | 2.78s
> > 819,000 | 3.54s | 3.53s | 3.39s | 3.39s
> > 614,400 | 4.73s | 4.71s | 4.51s | 4.51s
> > ----------------------------------------------------------------------------
> >
> > In summary, because the clock controller correctly handles the internal dividers
> > and parent switching, declaring only the primary core clock for each CPU node is
> > sufficient for functional DVFS.
> >
> I have just tested this patch against next-20260415
> But, I have observed this log on the Banana Pi F3 dev board with the
> Banana PI - R4 heat sink and fan.
>
> [ 5.803445][ T1] In-situ OAM (IOAM) with IPv6
> [ 5.809605][ T1] NET: Registered PF_PACKET protocol family
> [ 5.819098][ T1] Key type dns_resolver registered
> [ 5.853430][ C2] cpu2: scalar unaligned word access speed is
> 1.60x byte access speed (fast)
> [ 5.853431][ C3] cpu3: scalar unaligned word access speed is
> 1.67x byte access speed (fast)
> [ 5.853440][ C7] cpu7: scalar unaligned word access speed is
> 8.10x byte access speed (fast)
> [ 5.853432][ C1] cpu1: scalar unaligned word access speed is
> 3.98x byte access speed (fast)
> [ 5.853431][ T1] cpu0: scalar unaligned word access speed is
> 2.33x byte access speed (fast)
> [ 5.853436][ C5] cpu5: scalar unaligned word access speed is
> 2.29x byte access speed (fast)
> [ 5.853436][ C6] cpu6: scalar unaligned word access speed is
> 2.58x byte access speed (fast)
> [ 5.853431][ C4] cpu4: scalar unaligned word access speed is
> 2.07x byte access speed (fast)
> [ 5.936544][ T92] mmcblk0boot0: mmc0:0001 AJTD4R 4.00 MiB
> [ 6.003120][ T92] mmcblk0boot1: mmc0:0001 AJTD4R 4.00 MiB
> [ 6.070909][ T92] mmcblk0rpmb: mmc0:0001 AJTD4R 4.00 MiB, chardev (244:0)
> [ 6.380324][ T1] registered taskstats version 1
> [ 6.407337][ T1] Loading compiled-in X.509 certificates
> [ 6.594206][ T1] Loaded X.509 cert 'Build time autogenerated
> kernel key: 19b81ec48e45e6ee983623417bad5096df8bbcf1'
> [ 7.600343][ T1] Demotion targets for Node 0: null
> [ 7.608583][ T1] kmemleak: Kernel memory leak detector
> initialized (mem pool available: 1309)
> [ 7.608646][ T120] kmemleak: Automatic memory scanning thread started
> [ 7.624663][ T1] debug_vm_pgtable: [debug_vm_pgtable ]:
> Validating architecture page table helpers
> [ 7.636721][ T1] page_owner is disabled
> [ 8.213648][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
> in 'domains'
> [ 8.233502][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
> in 'domains'
> [ 8.254012][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
> in 'domains'
> [ 8.319431][ T74] printk: legacy console [ttyS0] disabled
> [ 8.345811][ T74] d4017000.serial: ttyS0 at MMIO 0xd4017000 (irq
> = 16, base_baud = 921600) is a XScale
> [ 8.357331][ T74] printk: legacy console [ttyS0] enabled
> [ 8.357331][ T74] printk: legacy console [ttyS0] enabled
> [ 8.369971][ T74] printk: legacy bootconsole [uart0] disabled
> [ 8.369971][ T74] printk: legacy bootconsole [uart0] disabled
> [ 8.427040][ T74] /soc/i2c@d401d800/pmic@41: Fixed dependency
> cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5
> [ 8.634595][ T74] spacemit-p1-rtc spacemit-p1-rtc.1.auto:
> registered as rtc0
> [ 8.642732][ T74] spacemit-p1-rtc spacemit-p1-rtc.1.auto: setting
> system clock to 2026-04-10T00:03:42 UTC (1775779422)
> [ 8.766081][ T74] sdhci-spacemit d4280000.mmc: Got CD GPIO
> [ 8.801855][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 8.806411][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 8.813413][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 8.818261][ T130] cpu cpu4: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 8.818307][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 8.827239][ T129] cpu cpu0: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 8.833161][ T130] cpu cpu4: Failed to set regulator voltages: -22
> [ 8.842546][ T129] cpu cpu0: Failed to set regulator voltages: -22
> [ 8.848941][ T130] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 8.855273][ T129] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 8.893720][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 8.904437][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 8.908515][ T129] cpu cpu0: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 8.918057][ T129] cpu cpu0: Failed to set regulator voltages: -22
> [ 8.924402][ T129] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 8.945668][ T74] mmc1: SDHCI controller on d4280000.mmc
> [d4280000.mmc] using ADMA
> [ 8.976207][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 8.980156][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 8.986169][ T130] cpu cpu4: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 8.995473][ T130] cpu cpu4: Failed to set regulator voltages: -22
> [ 9.001603][ T130] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 9.020028][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 9.024051][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 9.030122][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 9.036004][ T130] cpu cpu4: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 9.036059][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 9.045003][ T130] cpu cpu4: Failed to set regulator voltages: -22
> [ 9.045077][ T130] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 9.058079][ T57] spacemit-k1-pcie ca800000.pcie: host bridge
> /soc/pcie-bus/pcie@ca800000 ranges:
> [ 9.064716][ T129] cpu cpu0: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 9.064745][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 9.064825][ T129] cpu cpu0: Failed to set regulator voltages: -22
> [ 9.064889][ T129] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 9.065762][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 9.069924][ T60] spacemit-k1-pcie ca400000.pcie: host bridge
> /soc/pcie-bus/pcie@ca400000 ranges:
> [ 9.071122][ T60] spacemit-k1-pcie ca400000.pcie: IO
> 0x009f002000..0x009f101fff -> 0x0000000000
> [ 9.073304][ T60] spacemit-k1-pcie ca400000.pcie: MEM
> 0x0090000000..0x009effffff -> 0x0090000000
> [ 9.081407][ T74] at24 2-0050: 256 byte 24c02 EEPROM, read-only
> [ 9.083047][ T130] cpu cpu4: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 9.083509][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 9.083614][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 9.083686][ T129] cpu cpu0: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 9.083845][ T129] cpu cpu0: Failed to set regulator voltages: -22
> [ 9.083885][ T129] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 9.089945][ T57] spacemit-k1-pcie ca800000.pcie: IO
> 0x00b7002000..0x00b7101fff -> 0x0000000000
> [ 9.092728][ T1] clk: Disabling unused clocks
> [ 9.095269][ T130] cpu cpu4: Failed to set regulator voltages: -22
> [ 9.096981][ T1] PM: genpd: Disabling unused power domains
> [ 9.104949][ T57] spacemit-k1-pcie ca800000.pcie: MEM
> 0x00a0000000..0x00afffffff -> 0x00a0000000
> [ 9.107986][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 9.108166][ T129] buck1: Restricting voltage, 1050000-950000uV
> [ 9.108246][ T129] cpu cpu0: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 9.108311][ T129] cpu cpu0: Failed to set regulator voltages: -22
> [ 9.108356][ T129] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 9.108582][ T130] cpufreq: __target_index: Failed to change cpu
> frequency: -22
> [ 9.113366][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 9.118144][ T57] spacemit-k1-pcie ca800000.pcie: MEM
> 0x00b0000000..0x00b6ffffff -> 0x00b0000000
> [ 9.130386][ T130] buck1: Restricting voltage, 1050000-950000uV
> [ 9.196246][ T130] cpu cpu4: _set_opp_voltage: failed to set
> voltage (1050000 1050000 1050000 mV): -22
> [ 9.202562][ T60] spacemit-k1-pcie ca400000.pcie: iATU: unroll T,
> 8 ob, 8 ib, align 4K, limit 4G
> [ 9.206998][ T130] cpu cpu4: Failed to set regulator voltages: -22
> [ 9.257180][ T130] cpufreq: __target_index: Failed to change cpu
> frequency: -22
>
> After reviewing the Banana Pi F3 schematics, I confirmed that Buck1 and Buck2
> Both supply the CORE_0V9 with 0.9V±1% rail. To resolve the restriction errors,
> I expanded the voltage range in the DTS to 500,000–950,000 µV.
>
> Additionally, I updated the DTS to map the second CPU cluster (cores 4–7)
> to Buck2 to better align with the hardware's power distribution.
>
> [1] https://drive.google.com/file/d/19iLJ5xnCB_oK8VeQjkPGjzAn39WYyylv/view
> (page 4)
>
> Can you share your thoughts on the changes below?
> $ git diff
> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> index 7e300cca50d8..be53645ba0c6 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> @@ -102,19 +102,19 @@ &cpu_3 {
> };
>
> &cpu_4 {
> - cpu-supply = <&buck1_3v45>;
> + cpu-supply = <&buck2_3v45>;
> };
>
> &cpu_5 {
> - cpu-supply = <&buck1_3v45>;
> + cpu-supply = <&buck2_3v45>;
> };
>
> &cpu_6 {
> - cpu-supply = <&buck1_3v45>;
> + cpu-supply = <&buck2_3v45>;
> };
>
> &cpu_7 {
> - cpu-supply = <&buck1_3v45>;
> + cpu-supply = <&buck2_3v45>;
> };
>
> &emmc {
> @@ -234,14 +234,14 @@ pmic@41 {
> regulators {
> buck1_3v45: buck1 {
> regulator-min-microvolt = <500000>;
> - regulator-max-microvolt = <3450000>;
> + regulator-max-microvolt = <950000>;
> regulator-ramp-delay = <5000>;
> regulator-always-on;
> };
>
> - buck2 {
> + buck2_3v45: buck2 {
> regulator-min-microvolt = <500000>;
> - regulator-max-microvolt = <3450000>;
> + regulator-max-microvolt = <950000>;
> regulator-ramp-delay = <5000>;
> regulator-always-on;
> };
> > --
> > Best regards,
> > Shuwei Wu
>
I also made some modifications to the k1-opp.dtsi to fix the warning,
add over clock to 18000
[ 8.712035][ T80] core: _opp_supported_by_regulators: OPP minuV:
1050000 maxuV: 1050000, not supported by regulator
[ 8.720556][ T80] cpu cpu0: _opp_add: OPP not supported by
regulators (1600000000)
[ 8.752494][ T80] core: _opp_supported_by_regulators: OPP minuV:
1050000 maxuV: 1050000, not supported by regulator
[ 8.760906][ T80] cpu cpu4: _opp_add: OPP not supported by
regulators (1600000000)
[ 8.780195][ T80] cpufreq: cpufreq_policy_online: CPU0: Running
at unlisted initial frequency: 1600000 kHz, changing to: 1228800 kHz
[ 8.809572][ T80] cpufreq: cpufreq_policy_online: CPU4: Running
at unlisted initial frequency: 1600000 kHz, changing to: 1228800 kHz
$ git diff .
diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
index 768ae390686d..bec565947ba3 100644
--- a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
@@ -31,7 +31,13 @@ opp-1228800000 {
opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
- opp-microvolt = <1050000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1800000000 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
};
@@ -66,7 +72,13 @@ opp-1228800000 {
opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
- opp-microvolt = <1050000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1800000000 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
};
> Thanks
> -Anand
Thanks
-Anand
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: purwa: Add EL2 overlay for purwa-iot-evk
From: Xin Liu @ 2026-04-17 5:42 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, tingwei.zhang, jie.gan
Add support for building an EL2 combined DTB for the purwa-iot-evk
in the Qualcomm DTS Makefile.
The new purwa-iot-evk-el2.dtb is generated by combining the base
purwa-iot-evk.dtb with the x1-el2.dtbo overlay, enabling EL2-specific
configurations required by the platform.
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e7306419..0e326f62357b 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -157,6 +157,10 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-maple.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-poplar.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-xiaomi-sagit.dtb
dtb-$(CONFIG_ARCH_QCOM) += purwa-iot-evk.dtb
+
+purwa-iot-evk-el2-dtbs := purwa-iot-evk.dtb x1-el2.dtbo
+
+dtb-$(CONFIG_ARCH_QCOM) += purwa-iot-evk-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-particle-tachyon.dtb
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] input: misc: Add PixArt PAJ7620 gesture sensor driver
From: Harpreet Saini @ 2026-04-17 5:25 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: David Lechner, Harpreet Saini, devicetree, linux-input,
linux-kernel
In-Reply-To: <20260417052527.62535-1-sainiharpreet29@yahoo.com>
This driver adds support for the PixArt PAJ7620 gesture sensor.
It implements hand gesture recognition (up, down, left, right,
etc.) and reports them as standard input key events. The driver
includes power management support via Runtime PM.
Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
---
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/paj7620.c | 350 +++++++++++++++++++++++++++++++++++
3 files changed, 363 insertions(+)
create mode 100644 drivers/input/misc/paj7620.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 94a753fcb64f..de4206c297f2 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -453,6 +453,18 @@ config INPUT_KXTJ9
To compile this driver as a module, choose M here: the module will
be called kxtj9.
+config INPUT_PAJ7620
+ tristate "PixArt PAJ7620 Gesture Sensor"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y here if you want to support the PixArt PAJ7620 gesture
+ sensor. This sensor supports 9 hand gestures and communicates
+ over the I2C bus.
+
+ To compile this driver as a module, choose M here: the
+ module will be called paj7620.
+
config INPUT_POWERMATE
tristate "Griffin PowerMate and Contour Jog support"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415fc4e2918b..dec8b8d0cdf4 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_INPUT_PF1550_ONKEY) += pf1550-onkey.o
obj-$(CONFIG_INPUT_PM8941_PWRKEY) += pm8941-pwrkey.o
obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR) += pm8xxx-vibrator.o
obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
+obj-$(CONFIG_INPUT_PAJ7620) += paj7620.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_PWM_VIBRA) += pwm-vibra.o
diff --git a/drivers/input/misc/paj7620.c b/drivers/input/misc/paj7620.c
new file mode 100644
index 000000000000..632a77ce4085
--- /dev/null
+++ b/drivers/input/misc/paj7620.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PixArt PAJ7620 Gesture Sensor - Input driver
+ *
+ * Copyright (C) 2026 Harpreet Saini <sainiharpreet29@yahoo.com>
+ */
+
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+/* Registers */
+#define PAJ7620_REG_BANK_SEL 0xEF
+#define PAJ7620_REG_GES_RESULT1 0x43
+#define PAJ7620_REG_GES_RESULT2 0x44
+#define PAJ7620_REG_SLEEP_BANK0 0x65
+#define PAJ7620_REG_SLEEP_BANK1 0x05
+#define PAJ7620_REG_AUTO_STANDBY 0x073
+
+/* Gesture bits */
+#define PAJ_UP BIT(0)
+#define PAJ_DOWN BIT(1)
+#define PAJ_LEFT BIT(2)
+#define PAJ_RIGHT BIT(3)
+#define PAJ_FORWARD BIT(4)
+#define PAJ_BACKWARD BIT(5)
+#define PAJ_CLOCKWISE BIT(6)
+#define PAJ_ANTICLOCK BIT(7)
+#define PAJ_WAVE BIT(8)
+
+struct paj7620_data {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct input_dev *idev;
+ struct regulator_bulk_data supplies[3];
+};
+
+/*
+ * The following arrays contain undocumented register sequences required to
+ * initialize the sensor's internal DSP and gesture engine.
+ * These were derived from vendor reference code and verified via testing.
+ */
+static const struct reg_sequence Init_Register[] = {
+ { 0xEF, 0x00 }, { 0x37, 0x07 }, { 0x38, 0x17 }, { 0x39, 0x06 },
+ { 0x41, 0x00 }, { 0x42, 0x00 }, { 0x46, 0x2D }, { 0x47, 0x0F },
+ { 0x48, 0x3C }, { 0x49, 0x00 }, { 0x4A, 0x1E }, { 0x4C, 0x20 },
+ { 0x51, 0x10 }, { 0x5E, 0x10 }, { 0x60, 0x27 }, { 0x80, 0x42 },
+ { 0x81, 0x44 }, { 0x82, 0x04 }, { 0x8B, 0x01 }, { 0x90, 0x06 },
+ { 0x95, 0x0A }, { 0x96, 0x0C }, { 0x97, 0x05 }, { 0x9A, 0x14 },
+ { 0x9C, 0x3F }, { 0xA5, 0x19 }, { 0xCC, 0x19 }, { 0xCD, 0x0B },
+ { 0xCE, 0x13 }, { 0xCF, 0x64 }, { 0xD0, 0x21 }, { 0xEF, 0x01 },
+ { 0x02, 0x0F }, { 0x03, 0x10 }, { 0x04, 0x02 }, { 0x25, 0x01 },
+ { 0x27, 0x39 }, { 0x28, 0x7F }, { 0x29, 0x08 }, { 0x3E, 0xFF },
+ { 0x5E, 0x3D }, { 0x65, 0x96 }, { 0x67, 0x97 }, { 0x69, 0xCD },
+ { 0x6A, 0x01 }, { 0x6D, 0x2C }, { 0x6E, 0x01 }, { 0x72, 0x01 },
+ { 0x73, 0x35 }, { 0x74, 0x00 }, { 0x77, 0x01 },
+};
+
+/*
+ * Specific configuration overrides required to enable the internal
+ * 8-gesture state machine.
+ */
+static const struct reg_sequence Init_Gesture_Array[] = {
+ { 0xEF, 0x00 }, { 0x41, 0x00 }, { 0x42, 0x00 }, { 0xEF, 0x00 },
+ { 0x48, 0x3C }, { 0x49, 0x00 }, { 0x51, 0x10 }, { 0x83, 0x20 },
+ { 0x9F, 0xF9 }, { 0xEF, 0x01 }, { 0x01, 0x1E }, { 0x02, 0x0F },
+ { 0x03, 0x10 }, { 0x04, 0x02 }, { 0x41, 0x40 }, { 0x43, 0x30 },
+ { 0x65, 0x96 }, { 0x66, 0x00 }, { 0x67, 0x97 }, { 0x68, 0x01 },
+ { 0x69, 0xCD }, { 0x6A, 0x01 }, { 0x6B, 0xB0 }, { 0x6C, 0x04 },
+ { 0x6D, 0x2C }, { 0x6E, 0x01 }, { 0x74, 0x00 }, { 0xEF, 0x00 },
+ { 0x41, 0xFF }, { 0x42, 0x01 },
+};
+
+static void paj7620_report_keys(struct input_dev *idev, int gesture)
+{
+ static const struct { int bit; int key; } map[] = {
+ { PAJ_UP, KEY_UP },
+ { PAJ_DOWN, KEY_DOWN },
+ { PAJ_LEFT, KEY_LEFT },
+ { PAJ_RIGHT, KEY_RIGHT },
+ { PAJ_FORWARD, KEY_ENTER },
+ { PAJ_BACKWARD, KEY_BACK },
+ { PAJ_CLOCKWISE, KEY_NEXT },
+ { PAJ_ANTICLOCK, KEY_PREVIOUS },
+ { PAJ_WAVE, KEY_MENU },
+ };
+ // gesture mode does not support key hold, so pulse event
+ for (int i = 0; i < ARRAY_SIZE(map); i++) {
+ if (gesture & map[i].bit) {
+ input_report_key(idev, map[i].key, 1);
+ input_sync(idev);
+ input_report_key(idev, map[i].key, 0);
+ input_sync(idev);
+ }
+ }
+}
+
+static irqreturn_t paj7620_irq_thread(int irq, void *ptr)
+{
+ struct paj7620_data *data = ptr;
+ unsigned int g1, g2;
+ int ret;
+
+ /* 2. RUNTIME PM: Force awake to read registers */
+ pm_runtime_get_sync(&data->client->dev);
+
+ regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0);
+ ret = regmap_read(data->regmap, PAJ7620_REG_GES_RESULT1, &g1);
+ ret |= regmap_read(data->regmap, PAJ7620_REG_GES_RESULT2, &g2);
+
+ if (!ret && (g1 || g2))
+ paj7620_report_keys(data->idev, (g2 << 8) | g1);
+
+ pm_runtime_mark_last_busy(&data->client->dev);
+ pm_runtime_put_autosuspend(&data->client->dev);
+
+ return IRQ_HANDLED;
+}
+
+static int paj7620_init(struct paj7620_data *data)
+{
+ int state = 0, ret, i;
+
+ /* 1. Wake-up sequence: Read register 0x00 until it returns 0x20 */
+ for (i = 0; i < 10; i++) {
+ ret = regmap_read(data->regmap, 0x00, &state);
+ if (ret >= 0 && state == 0x20)
+ break;
+ usleep_range(1000, 2000);
+ }
+
+ if (state != 0x20) {
+ dev_err(&data->client->dev, "Sensor wake-up failed (0x%02x)\n", state);
+ return -ENODEV;
+ }
+
+ /* 2. Blast full register array into PAJ7620 instantly */
+ ret = regmap_multi_reg_write(data->regmap, Init_Register,
+ ARRAY_SIZE(Init_Register));
+ if (ret < 0) {
+ dev_err(&data->client->dev, "Multi-reg write failed (%d)\n", ret);
+ return ret;
+ }
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x00);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_multi_reg_write(data->regmap, Init_Gesture_Array,
+ ARRAY_SIZE(Init_Gesture_Array));
+ if (ret < 0) {
+ dev_err(&data->client->dev, "Multi-reg write failed (%d)\n", ret);
+ return ret;
+ }
+
+ dev_info(&data->client->dev, "Gesture Sensor Registers Initialized\n");
+ return 0;
+}
+
+static int paj7620_power_down(struct paj7620_data *data)
+{
+ int ret;
+ /* Deep sleep sequence */
+ ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x00);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_SLEEP_BANK0, 0x01);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x01);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_SLEEP_BANK1, 0x01);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int paj7620_runtime_suspend(struct device *dev)
+{
+ int ret;
+ struct paj7620_data *data = dev_get_drvdata(dev);
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x01);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_AUTO_STANDBY, 0x30);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int paj7620_runtime_resume(struct device *dev)
+{
+ int ret;
+ struct paj7620_data *data = dev_get_drvdata(dev);
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x01);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_AUTO_STANDBY, 0x00);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x00);
+ if (ret)
+ return ret;
+
+ usleep_range(1000, 2000); // Stabilization delay (1ms minimum)
+ return 0;
+}
+
+static const struct dev_pm_ops paj7620_pm_ops = {
+ SET_RUNTIME_PM_OPS(paj7620_runtime_suspend, paj7620_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
+};
+
+static const struct regmap_config paj7620_reg_config = {
+ .reg_bits = 8, .val_bits = 8, .max_register = 0xEF,
+};
+
+static int paj7620_probe(struct i2c_client *client)
+{
+ struct paj7620_data *data;
+ int ret;
+
+ data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->client = client;
+ i2c_set_clientdata(client, data);
+
+ data->supplies[0].supply = "vdd";
+ data->supplies[1].supply = "vbus";
+ data->supplies[2].supply = "vled";
+
+ ret = devm_regulator_bulk_get(&client->dev, ARRAY_SIZE(data->supplies), data->supplies);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Failed to get regulators\n");
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(data->supplies), data->supplies);
+ if (ret)
+ return ret;
+
+ data->regmap = devm_regmap_init_i2c(client, &paj7620_reg_config);
+ if (IS_ERR(data->regmap))
+ return PTR_ERR(data->regmap);
+
+ ret = paj7620_init(data);
+ if (ret)
+ goto err_reg;
+
+ data->idev = devm_input_allocate_device(&client->dev);
+ if (!data->idev) {
+ ret = -ENOMEM; goto err_reg;
+ }
+
+ data->idev->name = "PAJ7620 Gesture Sensor";
+ data->idev->id.bustype = BUS_I2C;
+
+ input_set_capability(data->idev, EV_KEY, KEY_UP);
+ input_set_capability(data->idev, EV_KEY, KEY_DOWN);
+ input_set_capability(data->idev, EV_KEY, KEY_LEFT);
+ input_set_capability(data->idev, EV_KEY, KEY_RIGHT);
+ input_set_capability(data->idev, EV_KEY, KEY_ENTER);
+ input_set_capability(data->idev, EV_KEY, KEY_BACK);
+ input_set_capability(data->idev, EV_KEY, KEY_NEXT);
+ input_set_capability(data->idev, EV_KEY, KEY_PREVIOUS);
+ input_set_capability(data->idev, EV_KEY, KEY_MENU);
+
+ ret = input_register_device(data->idev);
+ if (ret)
+ goto err_reg;
+
+ pm_runtime_set_active(&client->dev);
+ pm_runtime_enable(&client->dev);
+ pm_runtime_set_autosuspend_delay(&client->dev, 2000);
+ pm_runtime_use_autosuspend(&client->dev);
+
+ ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+ paj7620_irq_thread, IRQF_ONESHOT,
+ "paj7620", data);
+ if (ret)
+ goto err_reg;
+
+ dev_info(&client->dev, "Gesture Sensor Initialized\n");
+ return 0;
+
+err_reg:
+ dev_err_probe(&client->dev, ret, "%s: failed with error %d\n", __func__, ret);
+ if (pm_runtime_enabled(&client->dev)) {
+ pm_runtime_disable(&client->dev);
+ pm_runtime_dont_use_autosuspend(&client->dev);
+ }
+ regulator_bulk_disable(ARRAY_SIZE(data->supplies), data->supplies);
+ return ret;
+}
+
+static void paj7620_remove(struct i2c_client *client)
+{
+ int ret;
+ struct paj7620_data *data = i2c_get_clientdata(client);
+
+ pm_runtime_get_sync(&client->dev);
+ pm_runtime_disable(&client->dev);
+ pm_runtime_dont_use_autosuspend(&client->dev);
+ pm_runtime_put_noidle(&client->dev);
+
+ ret = paj7620_power_down(data);
+ if (ret)
+ dev_err(&data->client->dev, "Sensor power down failed\n");
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(data->supplies), data->supplies);
+ if (ret)
+ dev_err(&data->client->dev, "Sensor regulator disable failed\n");
+}
+
+static const struct of_device_id paj7620_of_match[] = {
+ { .compatible = "pixart,paj7620" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, paj7620_of_match);
+
+static struct i2c_driver paj7620_driver = {
+ .driver = {
+ .name = "paj7620",
+ .of_match_table = paj7620_of_match,
+ .pm = &paj7620_pm_ops,
+ },
+ .probe = paj7620_probe,
+ .remove = paj7620_remove,
+};
+module_i2c_driver(paj7620_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Harpreet Saini");
+MODULE_DESCRIPTION("PAJ7620 Gesture Input Driver");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 3/4] arm64: dts: qcom: hamoa-pmics: define VADC for pmk8550
From: Jishnu Prakash @ 2026-04-17 5:27 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260404-dell-xps-9345-ec-v2-3-c977c3caa81f@vinarskis.com>
On 4/4/2026 6:25 PM, Aleksandrs Vinarskis wrote:
> Follow pattern of pmk8350 to add missing pmk8550 VADC to hamoa.
> Register address of 0x9000 matches example schema for spmi-adc5-gen3.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi b/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi
> index 6a31a0adf8be472badea502a916cdbc9477e9f2b..cc69d299bc356d90aa1483f347f5eee43b853e45 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi
> @@ -218,6 +218,32 @@ pon_resin: resin {
> };
> };
>
> + pmk8550_vadc: adc@9000 {
> + compatible = "qcom,spmi-adc5-gen3";
> + reg = <0x9000>, <0x9100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
> + <0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
> + #io-channel-cells = <1>;
> + #thermal-sensor-cells = <1>;
> +
> + channel@3 {
> + reg = <0x3>;
> + label = "pmk8550_die_temp";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@44 {
> + reg = <0x44>;
> + label = "pmk8550_xo_therm";
> + qcom,pre-scaling = <1 1>;
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,adc-tm;
There's a small problem here - if you add the "qcom,adc-tm" property
under any channels, the auxiliary TM driver will be loaded to handle
this functionality and it will attempt to register such channels as
thermal devices. Since there is no thermal-zone node added for this
channel, you will get an error from here.
If you intend this channel to be used for ADC_TM functionality, a
thermal zone node for this channel has to be added. If this functionality
is not needed, it's better to remove the "qcom,adc-tm" property.
Thanks,
Jishnu
> + };
> + };
> +
> pmk8550_rtc: rtc@6100 {
> compatible = "qcom,pmk8350-rtc";
> reg = <0x6100>, <0x6200>;
>
^ permalink raw reply
* [PATCH v2 1/2] drivers/of: validate live-tree string properties before string use
From: Pengpeng Hou @ 2026-04-17 12:36 UTC (permalink / raw)
To: Rob Herring, Saravana Kannan; +Cc: devicetree, linux-kernel, pengpeng
In-Reply-To: <20260403183501.1-drivers-of-live-tree-pengpeng@iscas.ac.cn>
`populate_properties()` stores live-tree property values as raw byte
sequences plus a separate `length`. They are not globally guaranteed to
be NUL-terminated.
`of_prop_next_string()` iterates string-list properties by walking raw
bytes, `__of_node_is_type()` checks `device_type`,
`__of_device_is_status()` checks `status`, and
`of_alias_from_compatible()` reads the first `compatible` entry. These
paths must validate that the relevant string fits within the property
bounds before they hand it to C string helpers.
Validate these live-tree string properties within their declared bounds.
In particular, make `of_prop_next_string()` reject malformed entries
before returning them, use `of_property_match_string()` for
`device_type`, and add unit coverage for malformed first and trailing
string-list entries.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- use of_property_match_string() for device_type as suggested by
Rob Herring
- rework of_prop_next_string() so the first returned string is validated
through the same bounded path
- add of_unittest_property_string() coverage for malformed first and
trailing string-list entries
drivers/of/base.c | 36 ++++++++++++----------
drivers/of/property.c | 27 +++++++++++++++++-----
drivers/of/unittest.c | 32 ++++++++++++++++++++++++++++++++
3 files changed, 72 insertions(+), 23 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 57420806c1a2..96e4d7a7d5b8 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -82,9 +82,10 @@ EXPORT_SYMBOL(of_node_name_prefix);
static bool __of_node_is_type(const struct device_node *np, const char *type)
{
- const char *match = __of_get_property(np, "device_type", NULL);
+ if (!np || !type)
+ return false;
- return np && match && type && !strcmp(match, type);
+ return of_property_match_string(np, "device_type", type) == 0;
}
#define EXCLUDED_DEFAULT_CELLS_PLATFORMS ( \
@@ -491,22 +492,22 @@ static bool __of_device_is_status(const struct device_node *device,
return false;
status = __of_get_property(device, "status", &statlen);
- if (status == NULL)
+ if (!status || statlen <= 0)
+ return false;
+ if (strnlen(status, statlen) >= statlen)
return false;
- if (statlen > 0) {
- while (*strings) {
- unsigned int len = strlen(*strings);
+ while (*strings) {
+ unsigned int len = strlen(*strings);
- if ((*strings)[len - 1] == '-') {
- if (!strncmp(status, *strings, len))
- return true;
- } else {
- if (!strcmp(status, *strings))
- return true;
- }
- strings++;
+ if ((*strings)[len - 1] == '-') {
+ if (!strncmp(status, *strings, len))
+ return true;
+ } else {
+ if (!strcmp(status, *strings))
+ return true;
}
+ strings++;
}
return false;
@@ -1217,10 +1218,11 @@ EXPORT_SYMBOL(of_find_matching_node_and_match);
int of_alias_from_compatible(const struct device_node *node, char *alias, int len)
{
const char *compatible, *p;
- int cplen;
+ int ret;
- compatible = of_get_property(node, "compatible", &cplen);
- if (!compatible || strlen(compatible) > cplen)
+ ret = of_property_read_string_index(node, "compatible", 0,
+ &compatible);
+ if (ret)
return -ENODEV;
p = strchr(compatible, ',');
strscpy(alias, p ? p + 1 : compatible, len);
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 50d95d512bf5..e97bfe357808 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -648,16 +648,31 @@ EXPORT_SYMBOL_GPL(of_prop_next_u32);
const char *of_prop_next_string(const struct property *prop, const char *cur)
{
- const void *curv = cur;
+ const char *curv;
+ const char *end;
+ size_t len;
- if (!prop)
+ if (!prop || !prop->value || !prop->length)
return NULL;
- if (!cur)
- return prop->value;
+ curv = cur ? cur : prop->value;
+ end = prop->value + prop->length;
- curv += strlen(cur) + 1;
- if (curv >= prop->value + prop->length)
+ if (curv < (const char *)prop->value || curv >= end)
+ return NULL;
+
+ if (cur) {
+ len = strnlen(curv, end - curv);
+ if (len >= end - curv)
+ return NULL;
+
+ curv += len + 1;
+ if (curv >= end)
+ return NULL;
+ }
+
+ len = strnlen(curv, end - curv);
+ if (len >= end - curv)
return NULL;
return curv;
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 29402958f11c..ee53363dfa84 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -713,6 +713,7 @@ static void __init of_unittest_parse_phandle_with_args_map(void)
static void __init of_unittest_property_string(void)
{
const char *strings[4];
+ const struct property *prop;
struct device_node *np;
int rc;
@@ -789,6 +790,37 @@ static void __init of_unittest_property_string(void)
strings[1] = NULL;
rc = of_property_read_string_array(np, "phandle-list-names", strings, 1);
unittest(rc == 1 && strings[1] == NULL, "Overwrote end of string array; rc=%i, str='%s'\n", rc, strings[1]);
+
+ /* of_prop_next_string() tests */
+ prop = of_find_property(np, "phandle-list-names", NULL);
+ strings[0] = of_prop_next_string(prop, NULL);
+ unittest(strings[0] && !strcmp(strings[0], "first"),
+ "of_prop_next_string() failure; got '%s'\n", strings[0]);
+ strings[0] = of_prop_next_string(prop, strings[0]);
+ unittest(strings[0] && !strcmp(strings[0], "second"),
+ "of_prop_next_string() failure; got '%s'\n", strings[0]);
+ strings[0] = of_prop_next_string(prop, strings[0]);
+ unittest(strings[0] && !strcmp(strings[0], "third"),
+ "of_prop_next_string() failure; got '%s'\n", strings[0]);
+ strings[0] = of_prop_next_string(prop, strings[0]);
+ unittest(!strings[0],
+ "of_prop_next_string() should return NULL at end of list\n");
+
+ prop = of_find_property(np, "unterminated-string", NULL);
+ strings[0] = of_prop_next_string(prop, NULL);
+ unittest(!strings[0],
+ "of_prop_next_string() should reject unterminated first string\n");
+
+ prop = of_find_property(np, "unterminated-string-list", NULL);
+ strings[0] = of_prop_next_string(prop, NULL);
+ unittest(strings[0] && !strcmp(strings[0], "first"),
+ "of_prop_next_string() failure; got '%s'\n", strings[0]);
+ strings[0] = of_prop_next_string(prop, strings[0]);
+ unittest(strings[0] && !strcmp(strings[0], "second"),
+ "of_prop_next_string() failure; got '%s'\n", strings[0]);
+ strings[0] = of_prop_next_string(prop, strings[0]);
+ unittest(!strings[0],
+ "of_prop_next_string() should reject unterminated trailing string\n");
}
#define propcmp(p1, p2) (((p1)->length == (p2)->length) && \
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v2 2/2] drivers/of: validate status properties in reconfig state changes
From: Pengpeng Hou @ 2026-04-17 12:40 UTC (permalink / raw)
To: Rob Herring, Saravana Kannan; +Cc: devicetree, linux-kernel, pengpeng
In-Reply-To: <20260417223003.1-drivers-of-live-tree-v2-pengpeng@iscas.ac.cn>
Live-tree reconfiguration properties also carry raw values plus explicit
lengths. `of_reconfig_get_state_change()` currently treats `status`
property values as NUL-terminated strings and feeds them straight into
`strcmp()`.
Factor the `"okay"` / `"ok"` check out into a helper that first verifies
that the property contains a bounded C string within `prop->length`.
Malformed `status` updates should be treated as not enabling the node.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- no change; carried in v2 because patch 1/2 was reworked
drivers/of/dynamic.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 1a06175def37..efee59ed371a 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -74,6 +74,20 @@ static const char *action_names[] = {
[OF_RECONFIG_UPDATE_PROPERTY] = "UPDATE_PROPERTY",
};
+static bool of_property_status_ok(const struct property *prop)
+{
+ const char *status;
+
+ if (!prop || !prop->value || prop->length <= 0)
+ return false;
+
+ status = prop->value;
+ if (strnlen(status, prop->length) >= prop->length)
+ return false;
+
+ return !strcmp(status, "okay") || !strcmp(status, "ok");
+}
+
#define _do_print(func, prefix, action, node, prop, ...) ({ \
func("changeset: " prefix "%-15s %pOF%s%s\n", \
##__VA_ARGS__, action_names[action], node, \
@@ -135,11 +149,9 @@ int of_reconfig_get_state_change(unsigned long action, struct of_reconfig_data *
if (prop && !strcmp(prop->name, "status")) {
is_status = 1;
- status_state = !strcmp(prop->value, "okay") ||
- !strcmp(prop->value, "ok");
+ status_state = of_property_status_ok(prop);
if (old_prop)
- old_status_state = !strcmp(old_prop->value, "okay") ||
- !strcmp(old_prop->value, "ok");
+ old_status_state = of_property_status_ok(old_prop);
}
switch (action) {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: input: Add PixArt PAJ7620 gesture sensor
From: Harpreet Saini @ 2026-04-17 5:25 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: David Lechner, Harpreet Saini, devicetree, linux-input,
linux-kernel
In-Reply-To: <20260417052527.62535-1-sainiharpreet29@yahoo.com>
Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
---
.../bindings/input/pixart,paj7620.yaml | 70 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
2 files changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/pixart,paj7620.yaml
diff --git a/Documentation/devicetree/bindings/input/pixart,paj7620.yaml b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
new file mode 100644
index 000000000000..d4f58b712810
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org
+$schema: http://devicetree.org
+
+title: PixArt PAJ7620 Gesture Sensor
+
+maintainers:
+ - Harpreet Saini <sainiharpreet29@yahoo.com>
+
+description: |
+ The PixArt PAJ7620 is a gesture recognition sensor with an integrated
+ infrared LED and CMOS array. It communicates over an I2C interface and
+ provides gesture data via a dedicated interrupt pin.
+
+properties:
+ compatible:
+ const: pixart,paj7620
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Main power supply.
+
+ vbus-supply:
+ description: I/O and I2C bus power supply.
+
+ vled-supply:
+ description: Power for the integrated IR LED.
+
+ # Added per reviewer request for completeness
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+ - vbus-supply
+ - vled-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gesture@73 {
+ compatible = "pixart,paj7620";
+ reg = <0x73>;
+ interrupt-parent = <&gpio>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <®_3v3>;
+ vbus-supply = <®_1v8>;
+ vled-supply = <®_3v3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index ee7fd3cfe203..d73a0bf62b62 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1273,6 +1273,8 @@ patternProperties:
description: Pine64
"^pineriver,.*":
description: Shenzhen PineRiver Designs Co., Ltd.
+ "^pixart,.*":
+ description: PixArt Imaging Inc.
"^pixcir,.*":
description: PIXCIR MICROELECTRONICS Co., Ltd
"^plantower,.*":
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] input: misc: Add PixArt PAJ7620 gesture sensor
From: Harpreet Saini @ 2026-04-17 5:25 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: David Lechner, Harpreet Saini, devicetree, linux-input,
linux-kernel
In-Reply-To: <20260417052527.62535-1-sainiharpreet29.ref@yahoo.com>
This series adds support for the PixArt PAJ7620 gesture sensor.
Following review feedback on v1, the driver has been moved from IIO
to the Input subsystem as gestures are user-interaction events.
The bindings have been updated to include mandatory power supplies
and GPIO controller properties.
Changes in v2:
- Moved driver from drivers/iio/light to drivers/input/misc
- Updated DT bindings to include mandatory vdd, vbus, and vled supplies
- Added Runtime PM support with autosuspend logic
- Combined bindings and driver into a single series
Harpreet Saini (2):
dt-bindings: input: Add PixArt PAJ7620 gesture sensor
input: misc: Add PixArt PAJ7620 gesture sensor driver
.../bindings/input/pixart,paj7620.yaml | 70 ++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/paj7620.c | 350 ++++++++++++++++++
5 files changed, 435 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/pixart,paj7620.yaml
create mode 100644 drivers/input/misc/paj7620.c
--
2.43.0
^ 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