* [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
* Re: [PATCH 2/2] spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5
From: Fenglin Wu @ 2026-04-17 5:24 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <c5d1578d-729d-4c09-b761-c67e6d3be745@oss.qualcomm.com>
On 4/2/2026 12:18 PM, Fenglin Wu wrote:
>
> On 4/1/2026 7:22 PM, Dmitry Baryshkov wrote:
>> On Wed, Apr 01, 2026 at 02:41:24AM -0700, Fenglin Wu wrote:
>>> PMIC arbiter v8.5 is an extension of PMIC arbiter v8 that updated
>>> the definition of the channel status register bit fields. Add support
>>> to handle this difference.
>>>
>>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>>> ---
>>> drivers/spmi/spmi-pmic-arb.c | 69
>>> ++++++++++++++++++++++++++++++++++++++------
>>> 1 file changed, 60 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/spmi/spmi-pmic-arb.c
>>> b/drivers/spmi/spmi-pmic-arb.c
>>> index 69f8d456324a..deeaa39bb647 100644
>>> --- a/drivers/spmi/spmi-pmic-arb.c
>>> +++ b/drivers/spmi/spmi-pmic-arb.c
>>> @@ -28,6 +28,7 @@
>>> #define PMIC_ARB_VERSION_V5_MIN 0x50000000
>>> #define PMIC_ARB_VERSION_V7_MIN 0x70000000
>>> #define PMIC_ARB_VERSION_V8_MIN 0x80000000
>>> +#define PMIC_ARB_VERSION_V8P5_MIN 0x80050000
>>> #define PMIC_ARB_INT_EN 0x0004
>>> #define PMIC_ARB_FEATURES 0x0004
>>> @@ -63,11 +64,34 @@
>>> #define SPMI_OWNERSHIP_PERIPH2OWNER(X) ((X) & 0x7)
>>> /* Channel Status fields */
>>> -enum pmic_arb_chnl_status {
>>> - PMIC_ARB_STATUS_DONE = BIT(0),
>>> - PMIC_ARB_STATUS_FAILURE = BIT(1),
>>> - PMIC_ARB_STATUS_DENIED = BIT(2),
>>> - PMIC_ARB_STATUS_DROPPED = BIT(3),
>>> +struct pmic_arb_chnl_status_mask {
>>> + u8 done;
>>> + u8 failure;
>>> + u8 crc;
>>> + u8 parity;
>>> + u8 nack;
>>> + u8 denied;
>>> + u8 dropped;
>>> +};
>>> +
>>> +static const struct pmic_arb_chnl_status_mask chnl_status_mask = {
>>> + .done = BIT(0),
>>> + .failure = BIT(1),
>>> + .crc = 0,
>>> + .parity = 0,
>>> + .nack = 0,
>>> + .denied = BIT(2),
>>> + .dropped = BIT(3),
>>> +};
>>> +
>>> +static const struct pmic_arb_chnl_status_mask chnl_status_mask_v8p5
>>> = {
>>> + .done = BIT(0),
>>> + .failure = BIT(1),
>>> + .crc = BIT(2),
>>> + .parity = BIT(3),
>>> + .nack = BIT(4),
>>> + .denied = BIT(5),
>>> + .dropped = BIT(6),
>> Would it be better to extract generation-specific callback to decode the
>> error rather than defining the list of masks?
>
> Are you proposing to add a callback in pmic_arb_ver_ops, like
> '*check_chnl_status', and create separate implementations for PMIC
> arbiter versions before and after v8.5?
>
> This approach would add more extensive code changes with some code
> duplication, especially for handling common error bits shared across
> all versions—even if they only print error messages and return an
> error code. Is that a concern?
>
> Fenglin
Hi Dmitry,
Please let me know if this your preferred way and if you are fine with
the concern that I mentioned.
I can come up with this approach and post a new patch.
Thanks
Fenglin
^ permalink raw reply
* [net-next v2 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
Add default disable split header flag in all the starfive
soc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 91698c763dac..9146b498658d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -145,7 +145,7 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
}
dwmac->dev = &pdev->dev;
- plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+ plat_dat->flags |= (STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | STMMAC_FLAG_SPH_DISABLE);
plat_dat->bsp_priv = dwmac;
plat_dat->dma_cfg->dche = true;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-17 5:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAABR9nF131G3K3-vUdaDwHuQ7MCCLd-VO5syLApE_qsn+J49kA@mail.gmail.com>
Hi Geert,
Thanks you for your review and suggestion.
I think this approach looks very good.
> clock-names:
> minItems: 1
> maxItems: 8
> items:
> - fck # Main FSI module clock
> - spu # optional SPU bus/bridge clock [...]
> - icka # optional CPG DIV6 functional clocks for FSI port A
> - ickb # optional CPG DIV6 functional clocks for FSI port B
> [...]
Just to confirm: using this approach with a fixed order and optional
entries as described would not be
considered "flexible" in the sense that Krzysztof objected to, right?
Best regards,
Phuc
^ permalink raw reply
* Re: [net-next v2 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Rob Herring (Arm) @ 2026-04-17 4:36 UTC (permalink / raw)
To: Minda Chen
Cc: Paolo Abeni, Jakub Kicinski, Alexandre Torgue, Maxime Coquelin,
Emil Renner Berthing, Andrew Lunn, David S . Miller, linux-stm32,
devicetree, netdev, Krzysztof Kozlowski, Rob Herring,
linux-kernel, Eric Dumazet, Conor Dooley
In-Reply-To: <20260417024523.107786-4-minda.chen@starfivetech.com>
On Fri, 17 Apr 2026 10:45:21 +0800, Minda Chen wrote:
> JHB100 SGMII interface tx/rx mac clock is split and require to
> set clock rate in 10M/100M/1000M speed. So dts need to add a
> new rx clock in code, dts and dt binding doc.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> .../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
> 1 file changed, 36 insertions(+), 6 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml:56:8: [warning] wrong indentation: expected 8 but found 7 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260417024523.107786-4-minda.chen@starfivetech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: cdns: Convert xtfpga I2S to dt-schema
From: Max Filippov @ 2026-04-17 4:11 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260416152329.6016-1-chaitanya.msabnis@gmail.com>
On Thu, Apr 16, 2026 at 8:25 AM Chaitanya Sabnis
<chaitanya.msabnis@gmail.com> wrote:
>
> Convert the Cadence XTensa FPGA I2S controller plain-text binding
> documentation to standard dt-schema (YAML).
>
> The hardware requires exactly one memory region, one interrupt line,
> and one phandle to the master clock. Verified these constraints against
> the driver source in sound/soc/xtensa/xtfpga-i2s.c.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
> ---
> .../bindings/sound/cdns,xtfpga-i2s.txt | 18 -------
> .../bindings/sound/cdns,xtfpga-i2s.yaml | 48 +++++++++++++++++++
> 2 files changed, 48 insertions(+), 18 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
> create mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
> deleted file mode 100644
> index 860fc0da39c0..000000000000
> --- a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
> +++ /dev/null
> @@ -1,18 +0,0 @@
> -Bindings for I2S controller built into xtfpga Xtensa bitstreams.
> -
> -Required properties:
> -- compatible: shall be "cdns,xtfpga-i2s".
> -- reg: memory region (address and length) with device registers.
> -- interrupts: interrupt for the device.
> -- clocks: phandle to the clk used as master clock. I2S bus clock
> - is derived from it.
> -
> -Examples:
> -
> - i2s0: xtfpga-i2s@d080000 {
> - #sound-dai-cells = <0>;
> - compatible = "cdns,xtfpga-i2s";
> - reg = <0x0d080000 0x40>;
> - interrupts = <2 1>;
> - clocks = <&cdce706 4>;
> - };
> diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
> new file mode 100644
> index 000000000000..9a4a9db3c159
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/cdns,xtfpga-i2s.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence XTensa FPGA I2S Controller
When put like this it looks like an official name, but it's not and it misses an
important bit: 'xtfpga' is a group name for very specific FPGAs bitstreams
generated for xtensa cores, spelling it as XTensa FPGA makes it less
obvious what it is. I'd suggest keeping the original description.
For other changes:
Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>
> +
> +maintainers:
> + - Max Filippov <jcmvbkbc@gmail.com>
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +properties:
> + compatible:
> + const: cdns,xtfpga-i2s
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> + description: phandle to the clk used as master clock. I2S bus clock is derived from it.
> +
> + "#sound-dai-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + i2s@d080000 {
> + compatible = "cdns,xtfpga-i2s";
> + reg = <0x0d080000 0x40>;
> + interrupts = <2 1>;
> + clocks = <&cdce706 4>;
> + #sound-dai-cells = <0>;
> + };
> --
> 2.43.0
>
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v5 12/14] ASoC: rsnd: src: Add SRC reset and clock support for RZ/G3E
From: Kuninori Morimoto @ 2026-04-17 3:53 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <20260415124731.3684773-13-john.madieu.xa@bp.renesas.com>
Hi John
> The RZ/G3E SoC requires explicit SCU (Sampling Rate Converter Unit)
> reset and clock management unlike previous R-Car generations:
>
> - scu_clk: SCU module clock
> - scu_clkx2: SCU double-rate clock
> - scu_supply_clk: SCU supply clock
>
> Without these clocks enabled, the SRC module cannot operate on RZ/G3E.
> Add support for the shared SCU reset controller used by the SRC modules
> on the Renesas RZ/G3E SoC. All SRC instances are gated by the same "scu"
> reset line.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
(snip)
> +struct rsnd_src_ctrl {
> + struct clk *scu;
> + struct clk *scu_x2;
> + struct clk *scu_supply;
> +};
I noticed that "scu_supply" is used in init/quit, but scu/scu_x2 are
enabled when probe time only ?
I guess this is because it is needed for whole SRC ?
If so, it need to count whole SRC user and enable/disable it when
1st/last user.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v5 13/14] ASoC: rsnd: Support unprefixed DT node names for RZ/G3E
From: Kuninori Morimoto @ 2026-04-17 3:44 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <20260415124731.3684773-14-john.madieu.xa@bp.renesas.com>
Hi John
Thank you for your patch
> The RZ/G3E device tree binding uses standard unprefixed node names
> ('ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu', 'dai') instead of the
> legacy 'rcar_sound,' prefixed names used by R-Car bindings.
>
> Convert rsnd_parse_of_node() from a macro into a function that tries
> the legacy prefixed name first, then falls back to the unprefixed
> name by stripping the "rcar_sound," prefix. This makes the driver
> work transparently with both old and new bindings.
>
> While at it, update the of_node_name_eq() calls in core.c which compare
> against RSND_NODE_DAI directly (bypassing rsnd_parse_of_node()),
> and fix the related comments in ssiu.c, ssi.c, and dma.c that
> reference hardcoded "rcar_sound,ssiu" / "rcar_sound,ssi" names.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
(snip)
> +struct device_node *rsnd_parse_of_node(struct rsnd_priv *priv, const char *name)
> +{
> + struct device_node *np = rsnd_priv_to_dev(priv)->of_node;
> + struct device_node *node;
> + const char *unprefixed;
> +
> + node = of_get_child_by_name(np, name);
> + if (node)
> + return node;
> +
> + /*
> + * RZ/G3E binding uses unprefixed node names (e.g. "ssi" instead
> + * of "rcar_sound,ssi"). Try stripping the "rcar_sound," prefix.
> + */
> + unprefixed = strchr(name, ',');
> + if (unprefixed)
> + node = of_get_child_by_name(np, unprefixed + 1);
> +
> + return node;
> +}
I think it is better to have name get function, and use it on parse func ?
char *rsnd_xx_name(node, name)
{
char *sub_name;
/* name = "rcar_sound,ssi" */
ret = of_node_name_eq(node, name);
if (ret == 0)
return name;
/* sub_name = "ssi" */
sub_name = strchr(name, ",");
ret = of_node_name_eq(node, sub_name);
if (ret == 0)
return sub_name;
return NULL;
}
> @@ -1273,7 +1294,8 @@ static int rsnd_dai_of_node(struct rsnd_priv *priv, int *is_graph)
> of_node_put(node);
>
> for_each_child_of_node_scoped(np, node) {
> - if (!of_node_name_eq(node, RSND_NODE_DAI))
> + if (!of_node_name_eq(node, RSND_NODE_DAI) &&
> + !of_node_name_eq(node, "dai"))
> continue;
If driver is handling almost same things individually and/or randomly in per
each places, it will eventually lose consistency.
rsnd_xx_name() can keep consistency ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-17 3:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAMuHMdVPbcz4rF8ojEcvxp1NaM2mbQ2o+HZLwnnjNnX8uHf4HA@mail.gmail.com>
Hi Geert,
Thanks for your feedback.
> Where does this match the driver?
> Usually the functional clock is called "fck".
Regarding the clock name "own", I used it because of the following
implementation in the current driver:
clock->own = devm_clk_get(dev, NULL);
if (IS_ERR(clock->own))
return -EINVAL;
The driver currently fetches the first clock in the list (index 0) and
stores it in a variable named own.
That is why I named it "own" in the DT bindings to match.
However, I have noticed that other DTS files commonly use "fck" for
the functional clock.
Are you suggesting that I should also rename the variable from "own"
to "fck" in the driver code ??
For example:
clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
clock-names = "fck";
But from the hardware manual, MSTP refers to a "Module Stop Clock",
not a "functional clock".
So I'm not sure if using "fck" here is appropriate. Could you explain
the reasoning behind calling this clock "fck"?
Regarding the FSI clocks, they can be categorized into two types:
audio clocks and module clocks (which may include bus/bridge clocks).
The driver itself does not explicitly handle the enabling/disabling of
the module clock; it only manages the audio clocks.
From my code tracing:
At boot: The kernel automatically attaches the PM domain and
prepares the clocks during device initialization.
During playback (aplay): The FSI driver doesn't enable the module
clock directly. Instead, it is handled via:
genpd_runtime_resume -> pm_clk_resume -> clk_core_enable ->
cpg_mstp_clock_endisable.
Since this module clock is essential for register access, it must
always be the first entry in the clocks property (index 0) so
devm_clk_get(dev, NULL)
can fetch it correctly, right?
Please let me know if my understanding is incorrect.
Best regards,
Phuc
^ permalink raw reply
* RE: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Torreno, Alexis Czezar @ 2026-04-17 3:32 UTC (permalink / raw)
To: Guenter Roeck, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <a142d5ce-e4a3-4f50-8009-f796609fb13c@roeck-us.net>
> >>
> >> It's an output on this device seemingly. I don't care if the driver
> >> ignores it, but for completeness (and we like completeness with
> >> bindings) I think it should be documented as an interrupt or gpio.
> >
> > Alright, I'll add it as an interrupt: optional power-good signal
> >
>
> Uuh, that really doesn't make any sense. Please at least make it a gpio pin,
> matching pwr-good-gpios of ti,tps65185.yaml.
>
I see, will do.
^ permalink raw reply
* Re: [PATCH v5 11/14] ASoC: rsnd: adg: Add per-SSI ADG and SSIF supply clock management
From: Kuninori Morimoto @ 2026-04-17 3:32 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <20260415124731.3684773-12-john.madieu.xa@bp.renesas.com>
Hi John
Thank you for the patch
> RZ/G3E's ADG module requires explicit clock management for SSI audio
> interfaces that differs from R-Car Gen2/Gen3/Gen4:
>
> - Per-SSI ADG clocks (adg.ssi.N) for each SSI module
> - A shared SSIF supply clock for the SSI subsystem
>
> These clocks are acquired using optional APIs, making them transparent
> to platforms that do not require them.
>
> Clock prepare/unprepare is handled in rsnd_adg_clk_control(), which
> is called from probe, remove, suspend and resume (all sleepable
> contexts). The trigger path (atomic context) only calls
> clk_enable/clk_disable, which is atomic-safe and requires no
> additional splitting.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
(snip)
> @@ -424,9 +455,35 @@ int rsnd_adg_clk_control(struct rsnd_priv *priv, int enable)
> if (ret < 0)
> rsnd_adg_clk_disable(priv);
>
> + /* RZ/G3E: per-SSI ADG and SSIF supply clocks */
> + if (enable) {
> + for (i = 0; i < ADG_SSI_MAX; i++) {
> + ret = clk_prepare(adg->clk_adg_ssi[i]);
> + if (ret < 0) {
> + while (--i >= 0)
> + clk_unprepare(adg->clk_adg_ssi[i]);
> + rsnd_adg_clk_disable(priv);
> + return ret;
> + }
> + }
> + ret = clk_prepare(adg->clk_ssif_supply);
> + if (ret < 0) {
> + for (i = 0; i < ADG_SSI_MAX; i++)
> + clk_unprepare(adg->clk_adg_ssi[i]);
> + rsnd_adg_clk_disable(priv);
> + return ret;
> + }
> + }
> +
> /* disable adg */
> - if (!enable)
> + if (!enable) {
> + /* RZ/G3E: unprepare per-SSI and supply clocks */
> + clk_unprepare(adg->clk_ssif_supply);
> + for (i = 0; i < ADG_SSI_MAX; i++)
> + clk_unprepare(adg->clk_adg_ssi[i]);
> +
> clk_disable_unprepare(adg->adg);
> + }
>
> return ret;
> }
As mentioned in comment, to avoid duplicate code (like above), it will
call rsnd_adg_clk_disable() in case of rollback, too.
/*
* rsnd_adg_clk_enable() might return error (_disable() will not).
* We need to rollback in such case
*/
if (ret < 0)
rsnd_adg_clk_disable(priv);
Because of this style, I guess "enable" need to call clk_prepare() for *all*
clk without loop break, even though it returuns error. And call clk_unprepare()
for *all* clk when "rollback" and/or "disable".
Enable
for (i = 0; i < ADG_SSI_MAX; i++)
ret |= clk_prepare(...);
^^
ret |= clk_prepare(...);
^^
...
if (ret < 0)
rsnd_adg_clk_disable(priv);
Disable
clk_unprepare(...);
for (i = 0; i < ADG_SSI_MAX; i++)
clk_unprepare(...);
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Guenter Roeck @ 2026-04-17 3:22 UTC (permalink / raw)
To: Torreno, Alexis Czezar, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <PH0PR03MB635166088B7C473CF59F17D1F1202@PH0PR03MB6351.namprd03.prod.outlook.com>
On 4/16/26 18:04, Torreno, Alexis Czezar wrote:
>
>>>>
>>>> On the previous version, you got an LLM comment about not having the
>>>> interrupts property amongst other things.
>>>> I think the other things got implemented, but I didn't see any reply
>>>> to the bot about that?
>
> I wasn't sure if it was that type of bot. I'll try replying on the other patch review.
> I just added a note in the cover letter change log about the lacking smbalert.
>
>>>> I think the answer is that it shouldn't because the pin it
>>>> referenced doesn't exist, but when looking at the schematic I have
>>>> to wonder if
>>>
>>> I had to look this up in the datasheet. A SMBus chip with no alert pin
>>> is a bit odd, but you are correct.
>>>
>>>> there should be an interrupts property for dealing with "pgood"?
>>>>
>>> FWIW, I have never seen that. Normally such pins are used to take
>>> devices out of reset.
>>
>> It's an output on this device seemingly. I don't care if the driver ignores it, but
>> for completeness (and we like completeness with
>> bindings) I think it should be documented as an interrupt or gpio.
>
> Alright, I'll add it as an interrupt: optional power-good signal
>
Uuh, that really doesn't make any sense. Please at least make it a gpio pin,
matching pwr-good-gpios of ti,tps65185.yaml.
Guenter
^ permalink raw reply
* [net-next v2 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-17 2:45 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260417024523.107786-1-minda.chen@starfivetech.com>
Remove JH8100 dt-bindings because do not support it now.
StarFive have stopped JH8100 developing and will release it
outside.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 ++++---------------
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 313a15331661..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -30,10 +30,6 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
- - items:
- - const: starfive,jh8100-dwmac
- - const: starfive,jh7110-dwmac
- - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -120,25 +116,11 @@ allOf:
minItems: 3
maxItems: 3
- if:
- properties:
- compatible:
- contains:
- const: starfive,jh8100-dwmac
- then:
- properties:
- resets:
- maxItems: 1
-
- reset-names:
- const: stmmaceth
- else:
- properties:
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
2.17.1
^ permalink raw reply related
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-17 3:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260416203905.GA29913@bhelgaas>
> On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > Introduce generic helper functions to parse Root Port device tree
> > nodes and extract common properties like reset GPIOs. This allows
> > multiple PCI host controller drivers to share the same parsing logic.
> >
> > Define struct pci_host_port to hold common Root Port properties
> > (currently only reset GPIO descriptor) and add
> > pci_host_common_parse_ports() to parse Root Port nodes from device
> tree.
>
> Are the Root Port and the RC the only possible places for 'reset' GPIO
> descriptions in DT? I think PERST# routing is outside the PCIe spec, so it
> seems like a system could provide a PERST# GPIO routed to any Switch
> Upstream Port or Endpoint (I assume a PERST# connected to a switch would
> apply to both the upstream port and the downstream ports).
Hi Bjorn,
Thanks for the feedback. You're right that PERST# routing could theoretically be
connected to any device in the hierarchy. However, for this patch series, I've focused
on the most common use case in practice: use Root Port level PERST# instead of the
legacy Root Complex level PERST#.
Root Port level PERST# - This is the primary target, where each Root Port has individual
control over devices connected to it.
RC level PERST# - Legacy binding support, where a single GPIO controls all ports.
We can extend this framework later if real hardware emerges that needs Switch or
EP-level PERST# control. I can add a comment documenting this limitation if needed.
BTW, Mani and Rob had some great discussions in dt-schema about PERST# and WAKE#
sideband signals settings.
You can check here:
https://github.com/devicetree-org/dt-schema/issues/168
https://github.com/devicetree-org/dt-schema/pull/126
https://github.com/devicetree-org/dt-schema/pull/170
Best Regards
Sherry
^ permalink raw reply
* Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Xuyang Dong @ 2026-04-17 3:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel, linux-pwm,
devicetree, linux-kernel, ningyu, linmin, xuxiang, wangguosheng,
pinkesh.vaghela
In-Reply-To: <aeE-D5vC453uqtm6@monoceros>
>
> Hello,
>
> I suggest
>
> dt-bindings: pwm: dwc: Add optional reset
>
> as shortlog.
>
Hi Uwe,
Thanks, I'll address this in the next version.
Best regards,
Xuyang Dong
^ permalink raw reply
* Re: Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Xuyang Dong @ 2026-04-17 3:11 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, ukleinek, robh, krzk+dt, conor+dt, ben-linux,
ben.dooks, p.zabel, linux-pwm, devicetree, linux-kernel, ningyu,
linmin, xuxiang, wangguosheng, pinkesh.vaghela
In-Reply-To: <20260416-flashcard-shadily-a0ddd2f12ff8@spud>
> > > > >
> > > > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > > > domain:
> > > > > The presetn signal resets logic in pclk domain.
> > > > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > > > The resets are active-low.
> > > > >
> > > > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> > > >
> > > > This commit implies that your hardware differs from existing devices,
> > > > I think you should add a device-specific compatible.
> > > >
> >
> > Hi Conor and Krzysztof,
> >
> > The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
> > separate reset signals dedicated to each clock domain". They are:
> > The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
> > The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
> > the timer clock in DT).
> >
> > These reset signals are optional; it is up to the designer's
> > implementation.
>
> Right, and it's that "designer's implementation" that warrants a
> device-specific compatible.
>
Hi Conor,
The YAML update for the new device-specific compatible is as follows:
properties:
compatible:
oneOf:
- const: snps,dw-apb-timers-pwm2
- items:
- enum:
- snps,dw-apb-timers-pwm-2.13a
- const: snps,dw-apb-timers-pwm2
reg:
maxItems: 1
"#pwm-cells":
const: 3
clocks:
items:
- description: Interface bus clock
- description: PWM reference clock
clock-names:
items:
- const: bus
- const: timer
resets:
items:
- description: Interface bus reset
- description: PWM timer logic reset
snps,pwm-number:
$ref: /schemas/types.yaml#/definitions/uint32
description: The number of PWM channels configured for this instance
enum: [1, 2, 3, 4, 5, 6, 7, 8]
required:
- compatible
- reg
- clocks
- clock-names
allOf:
- $ref: pwm.yaml#
- if:
properties:
compatible:
contains:
const: snps,dw-apb-timers-pwm-2.13a
then:
required:
- resets
In your opinion, is this modification accurate?
Best regards,
Xuyang Dong
> >
> > According to [1], the applied YAML is also based on 2.13a, so our
> > hardware is the same as the existing devices. It's just that these two
> > reset signals were missing from the original YAML binding.
> >
> > [1] https://lore.kernel.org/linux-pwm/8bb5103d-803e-90d2-fd93-132bb2aac2d6@sifive.com/
> >
> > > > > ---
> > > > > .../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > > index 7523a89a1773..a8bbad0360f8 100644
> > > > > --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > > +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > > > @@ -43,6 +43,9 @@ properties:
> > > > > - const: bus
> > > > > - const: timer
> > > > >
> > > > > + resets:
> > > > > + maxItems: 2
> > >
> > > And this should really be listed with description, because order is
> > > fixed.
> > >
> >
> > The description of resets will be listed in next version.
> >
> > Best regards,
> > Xuyang Dong
^ permalink raw reply
* Re: [PATCH 1/2] drivers/of: validate live-tree string properties before string use
From: Pengpeng Hou @ 2026-04-17 3:06 UTC (permalink / raw)
To: Rob Herring; +Cc: Saravana Kannan, devicetree, linux-kernel, pengpeng
In-Reply-To: <20260403183501.1-drivers-of-live-tree-pengpeng@iscas.ac.cn>
Hi Rob,
Thanks, I'll respin this.
I'll switch the `device_type` match to `of_property_match_string()`,
rework `of_prop_next_string()` so the `cur == NULL` case flows through a
cleaner iterator path without validating each returned string twice, and
add a unittest for that first-iteration case.
Thanks,
Pengpeng
^ 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