* [PATCH net-next 00/10] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-03-29 13:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw multiplexer that
manages the traffic in a TDM manner. As a result multiple net_devices can
connect to the same GDM{3,4} port and there is a theoretical "1:n"
relation between GDM ports and net_devices.
┌─────────────────────────────────┐
│ │ ┌──────┐
│ P1 GDM1 ├────►MT7530│
│ │ └──────┘
│ │ ETH0 (DSA conduit)
│ │
│ PSE/FE │
│ │
│ │
│ │ ┌─────┐
│ P0 CDM1 ├────►QDMA0│
│ P4 P9 GDM4 │ └─────┘
└──┬─────────────────────────┬────┘
│ │
┌──▼──┐ ┌────▼────┐
│ PPE │ │ MUX │
└─────┘ └─┬─────┬─┘
│ │
┌──▼──┐┌─▼───┐
│ ETH ││ USB │
└─────┘└─────┘
ETH1 ETH2
This series introduces support for multiple net_devices connected to the
same Frame Engine (FE) GDM port (GDM3 or GDM4) via an external hw
multiplexer. Please note GDM1 or GDM2 does not support the connection with
the external multiplexer.
---
Lorenzo Bianconi (10):
dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
net: airoha: Rely on net_device pointer in HTB callbacks
net: airoha: Rely on net_device pointer in ETS callbacks
net: airoha: Introduce airoha_gdm_dev struct
net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
net: airoha: Rely on airoha_gdm_dev pointer in airhoa_is_lan_gdm_port()
net: airoha: Support multiple net_devices for a single FE GDM port
net: airoha: Do not stop GDM port if it is shared
net: airoha: Rename get_src_port_id callback in get_sport
.../devicetree/bindings/net/airoha,en7581-eth.yaml | 44 +-
drivers/net/ethernet/airoha/airoha_eth.c | 626 +++++++++++++--------
drivers/net/ethernet/airoha/airoha_eth.h | 30 +-
drivers/net/ethernet/airoha/airoha_ppe.c | 42 +-
4 files changed, 497 insertions(+), 245 deletions(-)
---
base-commit: 68bb4adb58e114336826e2ecc15ecf62e2890d3e
change-id: 20260324-airoha-eth-multi-serdes-fb4b556ee756
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Jernej Škrabec @ 2026-03-29 13:03 UTC (permalink / raw)
To: Michal Piekos
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <n2bupd37br2mp7ls6c5z5ueoancr53tn4mywg2vvrlpyhmkex4@lxe6tfdhwz5e>
Dne nedelja, 29. marec 2026 ob 14:07:19 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> On Sun, Mar 29, 2026 at 01:53:45PM +0200, Jernej Škrabec wrote:
> > Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> > > Add support for timer by reusing existing sun4i timer driver.
> > >
> > > H616 timer is compatible with earlier sunxi timer variants and provides
> > > both clocksource and clockevent functionality. It runs from 24 MHz
> > > oscillator. It can serve as broadcast clockevent for wake up from idle
> > > states.
> > >
> > > Tested on Orange Pi Zero 3:
> > > - timer is registered as clocksource:
> > > - switching clocksource at runtime works
> > > - timer operates as a broadcast clockevent device
> > > - no regression observed compared to arch_sys_counter
> > >
> > > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > > ---
> > > Test results:
> > >
> > > Clocksource switching:
> > > cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> > > arch_sys_counter timer
> > > echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > > [ 5031.105997] clocksource: Switched to clocksource timer
> > >
> > > Clockevent configuration:
> > > cat /proc/timer_list
> > > ...
> > > Tick Device: mode: 1
> > > Broadcast device
> > > Clock Event Device: sun4i_tick
> > > max_delta_ns: 178956969070
> > > min_delta_ns: 1000
> > > mult: 51539608
> > > shift: 31
> > > mode: 1
> > > next_event: 9223372036854775807 nsecs
> > > set_next_event: sun4i_clkevt_next_event
> > > shutdown: sun4i_clkevt_shutdown
> > > periodic: sun4i_clkevt_set_periodic
> > > oneshot: sun4i_clkevt_set_oneshot
> > > resume: sun4i_clkevt_shutdown
> > > event_handler: tick_handle_oneshot_broadcast
> > > ...
> > >
> > > Cyclictest measurements:
> > > Dominated by system scheduler latency and do not reflect clocksource
> > > precision.
> > > ---
> > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > index 8d1110c14bad..bf054869e78b 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> > > };
> > > };
> > >
> > > + timer0: timer@3009000 {
> > > + compatible = "allwinner,sun50i-h616-timer",
> > > + "allwinner,sun8i-a23-timer";
> >
> > You have to add above combo to DT bindings.
> >
> > Best regards,
> > Jernej
>
> Not sure I understand your comment correctly but binding for h616 is already
> there:
>
> Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml:21-27
> - items:
> - enum:
> - allwinner,sun20i-d1-timer
> - allwinner,sun50i-a64-timer
> - allwinner,sun50i-h6-timer
> - allwinner,sun50i-h616-timer
> - const: allwinner,sun8i-a23-timer
>
> BR
> Michal
Sorry, sometimes tooling fails me. All good.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
>
> >
> > > + reg = <0x03009000 0xa0>;
> > > + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&osc24M>;
> > > + };
> > > +
> > > watchdog: watchdog@30090a0 {
> > > compatible = "allwinner,sun50i-h616-wdt",
> > > "allwinner,sun6i-a31-wdt";
> > >
> > > ---
> > > base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> > > change-id: 20260328-h616-timer-046e6ac3549e
> > >
> > > Best regards,
> > >
> >
> >
> >
> >
>
^ permalink raw reply
* Re: [PATCH v2 0/3] media: camss: Link CAMSS power domain on MSM8996
From: Christopher Obbard @ 2026-03-29 13:00 UTC (permalink / raw)
To: Yassine Oudjana, Robert Foss, Todor Tomov, Bryan O'Donoghue,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Hans Verkuil
Cc: Yassine Oudjana, Vladimir Zapolskiy, linux-media, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20230526180712.8481-1-y.oudjana@protonmail.com>
Hi Yassine,
On Fri, 2023-05-26 at 21:07 +0300, Yassine Oudjana wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
>
> CAMSS on MSM8996 has been broken since commit
> 46cc03175498 ("media: camss: Split power domain management").
> This would happen when trying to start streaming:
>
> [ 199.097810] ------------[ cut here ]------------
> [ 199.097893] camss_top_ahb_clk status stuck at 'off'
> [ 199.097913] WARNING: CPU: 3 PID: 728 at drivers/clk/qcom/clk-branch.c:91 clk_branch_wait+0x140/0x160
> ...
> [ 199.100064] clk_branch_wait+0x140/0x160
> [ 199.100112] clk_branch2_enable+0x30/0x40
> [ 199.100159] clk_core_enable+0x6c/0xb0
> [ 199.100211] clk_enable+0x2c/0x50
> [ 199.100257] camss_enable_clocks+0x94/0xe0 [qcom_camss]
> [ 199.100342] csiphy_set_power+0x154/0x2a0 [qcom_camss]
> ...
> [ 199.101594] ---[ end trace 0000000000000000 ]---
> [ 199.101736] qcom-camss a34000.camss: clock enable failed: -16
> [ 199.101813] qcom-camss a34000.camss: Failed to power up pipeline: -16
>
> Turns out camss_top_ahb_clk needs the CAMSS power domain to be on. Before
> the change, VFE power domains were enabled before CSIPHY enabled clocks,
> and since the CAMSS power domain was their parent, it got enabled as well.
> With the VFE power domains now enabled after CSIPHY is powered on, the
> CAMSS power domain remains off and things go south when CSIPHY tries to
> enable camss_top_ahb_clk.
>
> Link the CAMSS power domain in camss_configure_pd to make sure it gets
> enabled before CSIPHY tries to enable clocks.
Do you have any plans to spin another version of this patch series ?
Cheers!
Chris
^ permalink raw reply
* [PATCH 3/3] arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
index 29b298af0d739100d33ff43a8b955a37821b3ef7..1b5ba3c47164f28756bb99210a5961bfaa881220 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
@@ -292,7 +292,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x94>;
+ fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1d4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
--
2.37.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
index 31a3ca137e63640a2387d3497274f10a6b8c6766..48a687926aa1b88a3d8bef25ff97bebec3777b00 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
@@ -283,7 +283,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x84>;
+ fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1c4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
--
2.37.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
While at here, also correct interrupt type as IRQ_TYPE_LEVEL_LOW.
Fixes: cbd3ef64eb9d1 ("arm64: dts: Add support for Emtop SoM & Baseboard")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
index 67d22d3768aa8ae7343cffeebcfdde89ed25cc2d..507d1824d99d99b1f795b14aea538444c9476f65 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
@@ -60,7 +60,7 @@ pmic@25 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
regulators {
buck1: BUCK1 {
@@ -194,7 +194,7 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
pinctrl_pmic: emtop-pmic-grp {
fsl,pins = <
- MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
>;
};
--
2.37.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: imx8m: Correct PAD settings for PMIC_nINT (2nd part)
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
There was a patchset for i.MX8MP [1], but after further check,
i.MX8MM/N were missed, there are three boards that might also has
interrupt storm issue. I not have the boards, per NXP board design
, PMIC_nINT requires CPU internal pull up, I think most vendors will
follow NXP design. So updates the i.MX8MM/N boards, but I not have
the boards for testing. If board owners would give a test, that would
be great.
[1] https://lore.kernel.org/all/20260326-imx8mp-dts-fix-v2-v2-0-62c4ce727448@nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 ++--
arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260329-imx8m-regulator-4e2e3f1b6ed5
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH 2/2 v2] devicetree: spi: add spi-mosi-idle-low property support
From: charles-antoine.couret @ 2026-03-29 12:58 UTC (permalink / raw)
To: broonie, robh, krzk+dt, conor+dt
Cc: linux-spi, devicetree, linux-kernel, Charles-Antoine Couret
From: Charles-Antoine Couret <charles-antoine.couret@mind.be>
This flag means that device requires the MOSI line to be low
when it's in idle state.
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@mind.be>
---
Documentation/devicetree/bindings/spi/spi-controller.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml
index 3b8e990e30c4..5f5b143cb27b 100644
--- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -132,6 +132,11 @@ patternProperties:
description:
The device requires inverse clock polarity (CPOL) mode.
+ spi-mosi-idle-low:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The device requires the MOSI line to be low when it's in idle state.
+
required:
- compatible
- reg
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: st: spear: remove undocumented thermal_flags property
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
spear13xx.dtsi defines a thermal_flags property in spear thermal sensor
node which is both unused in kernel and undocumented in spear thermal
sensor's binding.
There were no dtbs_check warnings associated with this property as the
underlying spear thermal binding was not converted to DTSchema.
Most likely st,thermal-flags is a misspelling of thermal_flags in
spear13xx.dtsi. Since both st/spear1310.dtsi and st/spear1340.dtsi
define st,thermal-flags property in spear thermal sensor node, we can
safely remove this property from spear13xx.dtsi.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v2:
- Reword the commit message and subject to correct explanation in patch 2
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 159e941708ca..0bb88f2d4ef5 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -332,7 +332,6 @@ wdt@ec800620 {
thermal@e07008c4 {
compatible = "st,thermal-spear1340";
reg = <0xe07008c4 0x4>;
- thermal_flags = <0x7000>;
};
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry, Krzysztof Kozlowski
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v2:
- No changes
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt
deleted file mode 100644
index 93e3b67c102d..000000000000
--- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* SPEAr Thermal
-
-Required properties:
-- compatible : "st,thermal-spear1340"
-- reg : Address range of the thermal registers
-- st,thermal-flags: flags used to enable thermal sensor
-
-Example:
-
- thermal@fc000000 {
- compatible = "st,thermal-spear1340";
- reg = <0xfc000000 0x1000>;
- st,thermal-flags = <0x7000>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
new file mode 100644
index 000000000000..e3462a974691
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr Thermal Sensor
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+properties:
+ compatible:
+ const: st,thermal-spear1340
+
+ reg:
+ maxItems: 1
+
+ st,thermal-flags:
+ description: flags used to enable thermal sensor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - st,thermal-flags
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* [PATCH v3 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
This patch series converts SPEAr Thermal Sensor bindings to DT schema
and removes the thermal_flags property from spear13xx.dtsi.
Changes since v2:
- Reword the commit message and subject to correct explanation in patch 2
- No changes in patch 1
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Gopi Krishna Menon (2):
dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
ARM: dts: st: spear: remove undocumented thermal_flags property
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
3 files changed, 36 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
--
2.52.0
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Michal Piekos @ 2026-03-29 12:07 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <5977334.DvuYhMxLoT@jernej-laptop>
On Sun, Mar 29, 2026 at 01:53:45PM +0200, Jernej Škrabec wrote:
> Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> > Add support for timer by reusing existing sun4i timer driver.
> >
> > H616 timer is compatible with earlier sunxi timer variants and provides
> > both clocksource and clockevent functionality. It runs from 24 MHz
> > oscillator. It can serve as broadcast clockevent for wake up from idle
> > states.
> >
> > Tested on Orange Pi Zero 3:
> > - timer is registered as clocksource:
> > - switching clocksource at runtime works
> > - timer operates as a broadcast clockevent device
> > - no regression observed compared to arch_sys_counter
> >
> > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > ---
> > Test results:
> >
> > Clocksource switching:
> > cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> > arch_sys_counter timer
> > echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > [ 5031.105997] clocksource: Switched to clocksource timer
> >
> > Clockevent configuration:
> > cat /proc/timer_list
> > ...
> > Tick Device: mode: 1
> > Broadcast device
> > Clock Event Device: sun4i_tick
> > max_delta_ns: 178956969070
> > min_delta_ns: 1000
> > mult: 51539608
> > shift: 31
> > mode: 1
> > next_event: 9223372036854775807 nsecs
> > set_next_event: sun4i_clkevt_next_event
> > shutdown: sun4i_clkevt_shutdown
> > periodic: sun4i_clkevt_set_periodic
> > oneshot: sun4i_clkevt_set_oneshot
> > resume: sun4i_clkevt_shutdown
> > event_handler: tick_handle_oneshot_broadcast
> > ...
> >
> > Cyclictest measurements:
> > Dominated by system scheduler latency and do not reflect clocksource
> > precision.
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > index 8d1110c14bad..bf054869e78b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> > };
> > };
> >
> > + timer0: timer@3009000 {
> > + compatible = "allwinner,sun50i-h616-timer",
> > + "allwinner,sun8i-a23-timer";
>
> You have to add above combo to DT bindings.
>
> Best regards,
> Jernej
Not sure I understand your comment correctly but binding for h616 is already
there:
Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml:21-27
- items:
- enum:
- allwinner,sun20i-d1-timer
- allwinner,sun50i-a64-timer
- allwinner,sun50i-h6-timer
- allwinner,sun50i-h616-timer
- const: allwinner,sun8i-a23-timer
BR
Michal
>
> > + reg = <0x03009000 0xa0>;
> > + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > watchdog: watchdog@30090a0 {
> > compatible = "allwinner,sun50i-h616-wdt",
> > "allwinner,sun6i-a31-wdt";
> >
> > ---
> > base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> > change-id: 20260328-h616-timer-046e6ac3549e
> >
> > Best regards,
> >
>
>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: qcom-pm8xxx-xoadc: add support for reading channel labels
From: Andy Shevchenko @ 2026-03-29 11:54 UTC (permalink / raw)
To: Antony Kurniawan Soemardi
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, linux-arm-msm, devicetree, linux-kernel,
linux-iio, phone-devel
In-Reply-To: <c8e6166f-e9fc-430e-b290-a97c2aae2b31@smankusors.com>
On Fri, Mar 27, 2026 at 07:05:04PM +0000, Antony Kurniawan Soemardi wrote:
> On 3/27/2026 2:04 AM, Andy Shevchenko wrote:
> > On Thu, Mar 26, 2026 at 12:00:52PM +0000, Antony Kurniawan Soemardi wrote:
> > > On 3/26/2026 5:18 PM, Andy Shevchenko wrote:
...
> > > > > + if (!ch) {
> > > > > + dev_err(adc->dev, "no such channel %lu\n", chan->address);
> > > > > + return -EINVAL;
> > > > > + }
> > > >
> > > > Isn't it a dead code? Also poisoning dmesg with this recurrent message is
> > > > not good idea to begin with (the user space will have a door to flood it,
> > > > which might be considered as an assistance to hackers to clear immediate
> > > > logs after a successful attack).
> > >
> > > Good point about the successful attack hint! I was copying the existing
> > > code from pm8xxx_read_raw. Do you think those checks are unnecessary for
> > > pm8xxx_read_raw as well?
> >
> > Yes, I think they are not as the returned code should be enough to identify
> > the problem. (For no such channel I would rather see -ENOENT, but we can't
> > simply replace that in the existing code as it's part of ABI.)
>
> Just to re-clarify, do you mean for both pm8xxx_read_label &
> pm8xxx_read_raw:
> 1. if the check fails, it should only return -EINVAL without any
> logging; or
> 2. remove the checks because there's no way it's not found?
The first one. And yeah, -EINVAL in the both cases for the sake of consistency.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 1/8] mmc: sdhci-of-k1: enable essential clock, infrastructure for SD operation
From: Vincent Legoll @ 2026-03-29 11:53 UTC (permalink / raw)
To: Iker Pedrosa
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel, Anand Moon, Trevor Gamblin
In-Reply-To: <55c580a0-61cd-435e-bff0-f5f54cbe6948@online.fr>
On 3/29/26 11:20, Vincent Legoll wrote:
> I applied this series on top of
> cbfffcca2bf0622b601b7eaf477aa29035169184 (linux mainline from
> yesterday) and successfully booted the resulting kernel from an SD
> card on an OrangePi-RV2 (with the vendor u-boot from the SPI flash).
>
> So if you want, you can add my: Tested-by: Vincent Legoll
> <legoll@online.fr> # OrangePi-RV2 to the relevant patches from this
> series Thanks Regards
Same for series applied on next-20260327:
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
P.S.: Sorry for the formatting, struggling with thunderbird.
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Jernej Škrabec @ 2026-03-29 11:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Michal Piekos
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
In-Reply-To: <20260329-h616-timer-v1-1-5966d0420a66@mmpsystems.pl>
Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> Add support for timer by reusing existing sun4i timer driver.
>
> H616 timer is compatible with earlier sunxi timer variants and provides
> both clocksource and clockevent functionality. It runs from 24 MHz
> oscillator. It can serve as broadcast clockevent for wake up from idle
> states.
>
> Tested on Orange Pi Zero 3:
> - timer is registered as clocksource:
> - switching clocksource at runtime works
> - timer operates as a broadcast clockevent device
> - no regression observed compared to arch_sys_counter
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> Test results:
>
> Clocksource switching:
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> arch_sys_counter timer
> echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> [ 5031.105997] clocksource: Switched to clocksource timer
>
> Clockevent configuration:
> cat /proc/timer_list
> ...
> Tick Device: mode: 1
> Broadcast device
> Clock Event Device: sun4i_tick
> max_delta_ns: 178956969070
> min_delta_ns: 1000
> mult: 51539608
> shift: 31
> mode: 1
> next_event: 9223372036854775807 nsecs
> set_next_event: sun4i_clkevt_next_event
> shutdown: sun4i_clkevt_shutdown
> periodic: sun4i_clkevt_set_periodic
> oneshot: sun4i_clkevt_set_oneshot
> resume: sun4i_clkevt_shutdown
> event_handler: tick_handle_oneshot_broadcast
> ...
>
> Cyclictest measurements:
> Dominated by system scheduler latency and do not reflect clocksource
> precision.
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> index 8d1110c14bad..bf054869e78b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> };
> };
>
> + timer0: timer@3009000 {
> + compatible = "allwinner,sun50i-h616-timer",
> + "allwinner,sun8i-a23-timer";
You have to add above combo to DT bindings.
Best regards,
Jernej
> + reg = <0x03009000 0xa0>;
> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h616-wdt",
> "allwinner,sun6i-a31-wdt";
>
> ---
> base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> change-id: 20260328-h616-timer-046e6ac3549e
>
> Best regards,
>
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Michal Piekos @ 2026-03-29 11:43 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
Add support for timer by reusing existing sun4i timer driver.
H616 timer is compatible with earlier sunxi timer variants and provides
both clocksource and clockevent functionality. It runs from 24 MHz
oscillator. It can serve as broadcast clockevent for wake up from idle
states.
Tested on Orange Pi Zero 3:
- timer is registered as clocksource:
- switching clocksource at runtime works
- timer operates as a broadcast clockevent device
- no regression observed compared to arch_sys_counter
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Test results:
Clocksource switching:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
arch_sys_counter timer
echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
[ 5031.105997] clocksource: Switched to clocksource timer
Clockevent configuration:
cat /proc/timer_list
...
Tick Device: mode: 1
Broadcast device
Clock Event Device: sun4i_tick
max_delta_ns: 178956969070
min_delta_ns: 1000
mult: 51539608
shift: 31
mode: 1
next_event: 9223372036854775807 nsecs
set_next_event: sun4i_clkevt_next_event
shutdown: sun4i_clkevt_shutdown
periodic: sun4i_clkevt_set_periodic
oneshot: sun4i_clkevt_set_oneshot
resume: sun4i_clkevt_shutdown
event_handler: tick_handle_oneshot_broadcast
...
Cyclictest measurements:
Dominated by system scheduler latency and do not reflect clocksource
precision.
---
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index 8d1110c14bad..bf054869e78b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
};
};
+ timer0: timer@3009000 {
+ compatible = "allwinner,sun50i-h616-timer",
+ "allwinner,sun8i-a23-timer";
+ reg = <0x03009000 0xa0>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
watchdog: watchdog@30090a0 {
compatible = "allwinner,sun50i-h616-wdt",
"allwinner,sun6i-a31-wdt";
---
base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
change-id: 20260328-h616-timer-046e6ac3549e
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
From: Dmitry Baryshkov @ 2026-03-29 11:08 UTC (permalink / raw)
To: Canfeng Zhuang
Cc: konradybcio, andersson, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-arm-kernel
In-Reply-To: <20260327083101.1343613-3-canfeng.zhuang@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 04:31:01PM +0800, Canfeng Zhuang wrote:
> The monaco-evk mezzanine connector supports a robot expansion board that
> requires UART6, which is currently disabled. This prevents the expansion
> board from exchanging data and control commands.
>
> Enable UART6 and assign the serial2 alias to provide stable device
> enumeration for the expansion board.
>
> Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco-evk.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> index 565418b86b2a..0b26861eac02 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> @@ -21,6 +21,7 @@ aliases {
> ethernet0 = ðernet0;
> i2c1 = &i2c1;
> serial0 = &uart7;
> + serial2 = &uart6;
What happened to serial1?
> };
>
> chosen {
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: sram: document glymur as compatible
From: Dmitry Baryshkov @ 2026-03-29 11:05 UTC (permalink / raw)
To: Ananthu C V
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260327-glymur-imem-v4-1-8fe0f20ad9fd@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 03:24:35AM -0700, Ananthu C V wrote:
> Add compatible for Qualcomm's glymur IMEM, a block of sram which
> can fall back to mmio-sram.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> index c451140962c8..bd62711dc630 100644
> --- a/Documentation/devicetree/bindings/sram/sram.yaml
> +++ b/Documentation/devicetree/bindings/sram/sram.yaml
> @@ -34,6 +34,7 @@ properties:
> - nvidia,tegra186-sysram
> - nvidia,tegra194-sysram
> - nvidia,tegra234-sysram
> + - qcom,glymur-imem
Is it different from the Kaanapali one?
> - qcom,kaanapali-imem
> - qcom,rpm-msg-ram
> - rockchip,rk3288-pmu-sram
>
> --
> 2.43.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Dmitry Baryshkov @ 2026-03-29 10:57 UTC (permalink / raw)
To: Gopikrishna Garmidi
Cc: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel, sibi.sankar, rajendra.nayak
In-Reply-To: <83c78333-4db9-4943-b90f-164981bb68d8@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 06:16:59PM +0530, Gopikrishna Garmidi wrote:
>
>
> On 3/26/2026 7:55 PM, Krzysztof Kozlowski wrote:
> > On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
> > > The display, peripherals (touchpad/touchscreen/keypad), usb and their
> > > dependent device nodes are common to both Glymur and Mahua CRDs,
> > > so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
> > > reuse.
> > >
> >
> > Same questions as for earlier tries (why this has to be repeated?), e.g.
> > x1-crd: Please describe here what is the actual common hardware. In
> > terms of physical hardware, not what you want to share.
> >
>
> Hi krzysztof,
>
> Thanks for the review,
>
> Will update the commit message in the next re-spin.
Before you respin, you can actually respond to the question. Do Glymur
and Mahua CRD actually share those devices (in case of USB that would
mean having the same baseboard with different SoCs being wired) or is it
just "oh, this looks similar enough, let's create a common file".
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Dmitry Baryshkov @ 2026-03-29 10:54 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <0322e0b3-bce8-4415-90b2-d14445986e23@kernel.org>
On Fri, Mar 27, 2026 at 11:40:51PM +0000, Bryan O'Donoghue wrote:
> On 27/03/2026 23:23, Dmitry Baryshkov wrote:
> > On Sat, Mar 28, 2026 at 01:12:22AM +0200, Vladimir Zapolskiy wrote:
> > > On 3/28/26 00:29, Bryan O'Donoghue wrote:
> > > > On 27/03/2026 20:51, Dmitry Baryshkov wrote:
> > > > > > That's just not true. If you read the camx source code you can see
> > > > > > split/combo mode 2+1 1+1 data/clock mode requires special programming of the
> > > > > > PHY to support.
> > > > > This needs to be identified from the data-lanes / clock-lanes topology.
> > > > > And once you do that, there would be (probably) no difference in the
> > > > > hardware definition.
> > > > >
> > > > >
> > > > > In other words, I'd also ask to drop this mode from the DT. This
> > > > > infromation can and should be deduced from other, already-defined
> > > > > properties.
> > > >
> > > > It still needs to be communicated to the PHY from the controller,
> > > > however that is not a problem I am trying to solve now.
> > > >
> > > > If I can't get consensus for PHY_QCOM_CSI2_MODE_SPLIT_DPHY then so be it.
> > > >
> > > > I'll aim for DPHY only and we can come back to this topic when someone
> > > > actually tries to enable it.
> > > >
> > >
> > > DPHY may be the only supported phy type in the driver, it does not matter
> > > at this point, however it's totally essential to cover the called by you
> > > 'split mode' right from the beginning in the renewed device tree binding
> > > descriptions of CAMSS IPs to progress further.
> >
> > Okay. How would we describe that there are two sensors connected to the
> > single PHY anyway? How would it be described with the current bindings?
> >
> > --
> > With best wishes
> > Dmitry
>
> Assuming you add endpoints to the PHY i.e. that is what Neil appears to be
> asking for and I personally am _fine_ with that, then it should just be
>
> port@0
> port@1
>
> if port@1 exists, you know you are in split-phy mode.
>
> Its actually straight forward enough, really. To be clear though I can write
> that yaml - the _most_ support I'm willing to put into the PHY code is to
> detect the port@1 and say "nope not supported yet", since like CPHY its not.
SGTM. But let's define the schema for those usecases.
>
> ---
> bod
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 0/3] thermal: spacemit: Add support for SpacemiT K1 SoC thermal sensor
From: Gong Shuai @ 2026-03-29 10:45 UTC (permalink / raw)
To: shuweiwoo
Cc: alex, aou, conor+dt, daniel.lezcano, devicetree, dlan, krzk+dt,
krzysztof.kozlowski, linux-kernel, linux-pm, linux-riscv,
lukasz.luba, p.zabel, palmer, pjw, rafael, robh, rui.zhang,
spacemit, gsh517025
In-Reply-To: <20260119-patchv2-k1-thermal-v3-0-3d82c9ebe8a4@163.com>
Hi Shuwei,
> Introduce support for the on-die thermal sensor found
> on the SpacemiT K1 SoC.
>
> Include the device tree binding documentation in YAML format, the
> thermal sensor driver implementation, and the device tree changes to
> enable the sensor on K1 SoC.
>
> ---
> Changes in v3:
> - Fix indentation and variable types
> - Simplify clock management and redundant assignments
> - Link to v2: https://lore.kernel.org/r/20251216-patchv2-k1-thermal-v1-0-d4b31fe9c904@163.com
>
> Changes in v2:
> - Move driver to drivers/thermal/spacemit/ and update Kconfig/Makefile
> - Address reviewer feedback on style and structure
> - Improve variable naming and comments
> - Link to v1: https://lore.kernel.org/r/20251127-b4-k1-thermal-v1-0-f32ce47b1aba@163.com
>
> ---
> Shuwei Wu (3):
> dt-bindings: thermal: Add SpacemiT K1 thermal sensor
> thermal: spacemit: k1: Add thermal sensor support
> riscv: dts: spacemit: Add thermal sensor for K1 SoC
>
> .../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++
> arch/riscv/boot/dts/spacemit/k1.dtsi | 101 ++++++++
> drivers/thermal/Kconfig | 2 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/spacemit/Kconfig | 19 ++
> drivers/thermal/spacemit/Makefile | 3 +
> drivers/thermal/spacemit/k1_tsensor.c | 281 +++++++++++++++++++++
> 7 files changed, 483 insertions(+)
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251215-patchv2-k1-thermal-5ffb838fc1cc
>
> Best regards,
> --
> Shuwei Wu <shuweiwoo@163.com>
This patch series works well on OrangePi-RV2 with mainline kernel 7.0.0-rc5
$ cat /sys/class/thermal/thermal_zone*/type
soc-thermal
package-thermal
gpu-thermal
cluster0-thermal
cluster1-thermal
$ cat /sys/class/thermal/thermal_zone*/temp
35000
37000
36000
36000
37000
$ sensors
cluster1_thermal-virtual-0
Adapter: Virtual device
temp1: +38.0 C
gpu_thermal-virtual-0
Adapter: Virtual device
temp1: +36.0 C
soc_thermal-virtual-0
Adapter: Virtual device
temp1: +36.0 C
cluster0_thermal-virtual-0
Adapter: Virtual device
temp1: +37.0 C
package_thermal-virtual-0
Adapter: Virtual device
temp1: +37.0 C
Tested-by: Gong Shuai <gsh517025@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH RFC v2 08/17] RISC-V: QoS: add resctrl interface for CBQRI controllers
From: guo.wenjia23 @ 2026-03-29 10:27 UTC (permalink / raw)
To: fustini
Cc: pjw, palmer, aou, alex, rkrcmar, samuel.holland, aricciardi,
npitre, mindal, atish.patra, atishp, vasu, ved, cuiyunhui, cp0613,
zhiwei_liu, liwei1518, liu.qingtao2, reinette.chatre, tony.luck,
babu.moger, peternewman, fenghua.yu, james.morse, ben.horgan,
Dave.Martin, fustini, linux-kernel, linux-riscv, x86, robh,
rafael, lenb, robert.moore, sunilvl, krzk+dt, conor+dt,
paul.walmsley, linux-acpi, acpica-devel, devicetree
In-Reply-To: <20260128-ssqosid-cbqri-v2-8-dca586b091b9@kernel.org>
Hi Drew,
On Thu, Jan 29, 2026 at 4:28 AM Drew Fustini <fustini@kernel.org> wrote:>
> Add interface for CBQRI controller drivers to make use of the resctrl
> filesystem.
>
> Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Drew Fustini <fustini@kernel.org>
> ---
> arch/riscv/kernel/qos/qos_resctrl.c | 1192 +++++++++++++++++++++++++++++++++++
> 1 file changed, 1192 insertions(+)
>
> ...
>
> +
> +int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> + u32 closid, enum resctrl_conf_type t, u32 cfg_val)
> +{
> + struct cbqri_controller *ctrl;
> + struct cbqri_resctrl_dom *dom;
> + struct cbqri_config cfg;
> + int err = 0;
> +
> + dom = container_of(d, struct cbqri_resctrl_dom, resctrl_ctrl_dom);
> + ctrl = dom->hw_ctrl;
> +
> + if (!r->alloc_capable)
> + return -EINVAL;
> +
> + switch (r->rid) {
> + case RDT_RESOURCE_L2:
> + case RDT_RESOURCE_L3:
> + cfg.cbm = cfg_val;
> + err = cbqri_apply_cache_config(dom, closid, t, &cfg);
> + break;
> + case RDT_RESOURCE_MBA:
> + /* covert from percentage to bandwidth blocks */
> + cfg.rbwb = cfg_val * ctrl->bc.nbwblks / 100;
Should use bc.mrbwb to calculate rbwb?
I think bc.nbwblks represent the available bw blks in the controller. It should should decrease as they are allocated.
> + err = cbqri_apply_bw_config(dom, closid, t, &cfg);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return err;
> +}
>
> ...
>
> +u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> + u32 closid, enum resctrl_conf_type type)
> +{
> + struct cbqri_resctrl_dom *hw_dom;
> + struct cbqri_controller *ctrl;
> + int reg_offset;
> + u32 percent;
> + u32 rbwb;
> + u64 reg;
> + int err;
> +
> + hw_dom = container_of(d, struct cbqri_resctrl_dom, resctrl_ctrl_dom);
> +
> + ctrl = hw_dom->hw_ctrl;
> +
> + if (!r->alloc_capable)
> + return resctrl_get_default_ctrl(r);
> +
> + switch (r->rid) {
> + case RDT_RESOURCE_L2:
> + case RDT_RESOURCE_L3:
> + /* Clear cc_block_mask before read limit operation */
> + cbqri_set_cbm(ctrl, 0);
> +
> + /* Capacity read limit operation for RCID (closid) */
> + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT, type, closid);
> + if (err < 0) {
> + pr_err("%s(): operation failed: err = %d", __func__, err);
> + return resctrl_get_default_ctrl(r);
> + }
> +
> + /* Read capacity block mask for RCID (closid) */
> + reg_offset = CBQRI_CC_BLOCK_MASK_OFF;
> + reg = ioread64(ctrl->base + reg_offset);
> +
> + /* Update the config value for the closid in this domain */
> + hw_dom->ctrl_val[closid] = reg;
> + return hw_dom->ctrl_val[closid];
> +
> + case RDT_RESOURCE_MBA:
> + /* Capacity read limit operation for RCID (closid) */
> + err = cbqri_bc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT, closid);
> + if (err < 0) {
> + pr_err("%s(): operation failed: err = %d", __func__, err);
> + return resctrl_get_default_ctrl(r);
> + }
> +
> + hw_dom->ctrl_val[closid] = cbqri_get_rbwb(ctrl);
> +
> + /* Convert from bandwidth blocks to percent */
> + rbwb = hw_dom->ctrl_val[closid];
> + rbwb *= 100;
> + percent = rbwb / ctrl->bc.nbwblks;
> + if (rbwb % ctrl->bc.nbwblks)
Same Question.
> + percent++;
> + return percent;
> +
> + default:
> + return resctrl_get_default_ctrl(r);
> + }
> +}
Sorry for my previous reply on old patch. Please ignore it. I’m re-sending this comment on v2.
Thank,
Wenjia
郭文佳10158971
^ permalink raw reply
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Dmitry Baryshkov @ 2026-03-29 10:44 UTC (permalink / raw)
To: Richard Acayan
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
In-Reply-To: <20260328014041.83777-4-mailingradian@gmail.com>
On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> the first 6 CPUs are in the little cluster and the next 2 are in the big
> cluster. Define the clusters in the match data and define the different
> cluster configuration for SDM670.
>
> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
> the cluster.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 13 deletions(-)
>
> +static const struct lmh_soc_data sdm670_lmh_data = {
> + .enable_algos = true,
> + .node_ids = {
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + },
> +};
> +
> +static const struct lmh_soc_data sdm845_lmh_data = {
> + .enable_algos = true,
> + .node_ids = {
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + },
> +};
These tables made me wonder, can we determine this information from the
DT? For example, by reading the qcom,freq-domain property. But...
> +
> +static const struct lmh_soc_data sm8150_lmh_data = {
> + .enable_algos = false,
> + .node_ids = {
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + },
> +};
... this might be problematic, unless this entry is broken. On SM8150 we
have three freq domains, but up to now we were programming two clustern
nodes. Of course it is possible to define that node_id is 0 for freq
domain 0 and 1 for domains 1 and 2.
> +
> static const struct of_device_id lmh_table[] = {
> - { .compatible = "qcom,sc8180x-lmh", },
> - { .compatible = "qcom,sdm845-lmh", .data = (void *)LMH_ENABLE_ALGOS},
> - { .compatible = "qcom,sm8150-lmh", },
> + { .compatible = "qcom,sc8180x-lmh", .data = &sm8150_lmh_data },
> + { .compatible = "qcom,sdm670-lmh", .data = &sdm670_lmh_data },
> + { .compatible = "qcom,sdm845-lmh", .data = &sdm845_lmh_data },
> + { .compatible = "qcom,sm8150-lmh", .data = &sm8150_lmh_data },
> {}
> };
> MODULE_DEVICE_TABLE(of, lmh_table);
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: Add Motorola edge 30 (dubai) DTS
From: Val Packett @ 2026-03-29 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kees Cook, Tony Luck, Guilherme G. Piccoli
Cc: Val Packett, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329103055.96649-1-val@packett.cool>
The Motorola edge 30 is a smartphone released in 2022.
This commit has the following features working:
- Display (simplefb)
- Touchscreen
- Power and volume buttons
- Storage (UFS 3.1)
- Battery (ADSP battmgr)
- USB (Type-C, 2.0, dual-role)
- Wi-Fi and Bluetooth (WCN6750 hw1.0)
Signed-off-by: Val Packett <val@packett.cool>
---
My new main phone, it's very cool :)
Left out for now, will send after this lands:
- actual panel (Novatek NT37701 based)
- apparently the first to need different prepare commands depending on
refresh rate, have a WIP patch to pass the info already, expecting that
to go through some discussion though..
- seems impossible to find model numbers, there are 2 vendors (Tianma
and CSOT) but there's no info online for a 6.55" NT37701 based panel
made by either company
- audio (Awinic AW88261 + WCD9375)
- waiting for the Senary MI2S series to land for the speakers
- only have the top (aux) mic working but not the bottom (main) one o.0
- camera (Samsung S5KJN1 as ultrawide)
- still polishing the tiny driver from downstream for the WL2864C PMIC
Did not bring up yet:
- other cameras (OV50A main, OV32B40 front): need drivers >_<
- haptics (AW86224): needs to be added to AW86927 driver (similar regs)
ath11k bdf sent:
https://lists.infradead.org/pipermail/ath11k/2026-March/008314.html
Thanks,
~val
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sm7325-motorola-dubai.dts | 1474 +++++++++++++++++
2 files changed, 1475 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index c46d94bb6dd5..c4d5dba342e3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -334,6 +334,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm6375-sony-xperia-murray-pdx225.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7125-xiaomi-curtana.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7125-xiaomi-joyeuse.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7225-fairphone-fp4.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm7325-motorola-dubai.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7325-nothing-spacewar.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-microsoft-surface-duo.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts b/arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts
new file mode 100644
index 000000000000..2be4f235a80b
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts
@@ -0,0 +1,1474 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) 2026, Val Packett <val@packett.cool>
+ */
+
+/dts-v1/;
+
+/* PM7250B is configured to use SID8/9 */
+#define PM7250B_SID 8
+#define PM7250B_SID1 9
+
+#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pm7325.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "sm7325.dtsi"
+#include "pm7325.dtsi"
+#include "pm7250b.dtsi"
+#include "pm8350c.dtsi" /* PM7350C */
+#include "pmk8350.dtsi" /* PMK7325 */
+
+/ {
+ model = "Motorola edge 30";
+ compatible = "motorola,dubai", "qcom,sm7325";
+ chassis-type = "handset";
+
+ aliases {
+ bluetooth0 = &bluetooth;
+ serial0 = &uart5;
+ serial1 = &uart7;
+ wifi0 = &wifi;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ stdout-path = "serial0:115200n8";
+
+ framebuffer0: framebuffer@e1000000 {
+ compatible = "simple-framebuffer";
+ reg = <0x0 0xe1000000 0x0 (1080 * 2400 * 4)>;
+ width = <1080>;
+ height = <2400>;
+ stride = <(1080 * 4)>;
+ format = "a8r8g8b8";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&kypd_vol_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&pm7325_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm7325-pmic-glink",
+ "qcom,qcm6490-pmic-glink",
+ "qcom,pmic-glink";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ orientation-gpios = <&tlmm 140 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_sbu: endpoint {
+ remote-endpoint = <&fsa4480_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ramoops@ae000000 {
+ compatible = "ramoops";
+ reg = <0x0 0xae000000 0x0 0xc0000>;
+ console-size = <0x40000>;
+ mem-type = <2>;
+ pmsg-size = <0x40000>;
+ record-size = <0x3f800>;
+ };
+
+ removed@c0000000 {
+ reg = <0x0 0xc0000000 0x0 0x5100000>;
+ no-map;
+ };
+
+ cont-splash@e1000000 {
+ reg = <0x0 0xe1000000 0x0 (1080 * 2400 * 4)>;
+ no-map;
+ };
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ size = <0x0 0x8000000>;
+ reusable;
+ linux,cma-default;
+ };
+ };
+
+ thermal-zones {
+ cam-flash-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 2>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ chg-skin-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pm7250b_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ chg-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 4>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ conn-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pm7250b_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-1-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 5>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-2-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 6>;
+
+ /* Reports negative temperature. */
+ status = "disabled";
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ quiet-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ sdm-skin-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 3>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ xo-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
+ // S2B is really ebi.lvl but it's there for supply map completeness sake.
+ vreg_s2b_0p7: smpb2-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s2b_0p7";
+
+ regulator-min-microvolt = <65535>;
+ regulator-max-microvolt = <65535>;
+ regulator-always-on;
+ vin-supply = <&vph_pwr>;
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ };
+
+ wcn6750-pmu {
+ compatible = "qcom,wcn6750-pmu";
+ pinctrl-0 = <&bt_en>;
+ pinctrl-names = "default";
+ vddaon-supply = <&mos_0p95_aon_s10c>;
+ vddasd-supply = <&vreg_l11c_2p8>;
+ vddpmu-supply = <&mos_0p95_dig_s10c>;
+ vddio-supply = <&vdd18_io>;
+ vddrfa0p8-supply = <&vdd09_pmu_rfa_i>;
+ vddrfa1p2-supply = <&vdd13_pmu_rfa_i>;
+ vddrfa1p7-supply = <&vdd19_pmu_rfa_i>;
+ vddrfa2p2-supply = <&vdd22_wlpa_s1c>;
+
+ bt-enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm7325-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s8-supply = <&vph_pwr>;
+
+ vdd-l1-l4-l12-l15-supply = <&vreg_s7b_0p952>;
+ vdd-l2-l7-supply = <&vreg_bob>;
+ vdd-l3-supply = <&vreg_s2b_0p7>;
+ vdd-l5-supply = <&vreg_s2b_0p7>;
+ vdd-l6-l9-l10-supply = <&vreg_s8b_1p256>;
+ vdd-l8-supply = <&vreg_s7b_0p952>;
+ vdd-l11-l17-l18-l19-supply = <&vreg_s1b_1p856>;
+ vdd-l13-supply = <&vreg_s7b_0p952>;
+ vdd-l14-l16-supply = <&vreg_s8b_1p256>;
+
+ /*
+ * S2, L4-L5 are ARCs:
+ * S2 - ebi.lvl,
+ * L4 - lmx.lvl,
+ * l5 - lcx.lvl.
+ *
+ * L10 are unused.
+ */
+
+ vdd19_pmu_rfa_i:
+ vreg_s1b_1p856: smps1 {
+ regulator-name = "vreg_s1b_1p856";
+ regulator-min-microvolt = <1840000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ mos_0p95_aon_s10c:
+ mos_0p95_dig_s10c:
+ vdd09_pmu_rfa_i:
+ vreg_s7b_0p952: smps7 {
+ regulator-name = "vreg_s7b_0p952";
+ regulator-min-microvolt = <535000>;
+ regulator-max-microvolt = <1120000>;
+ };
+
+ vdd13_pmu_rfa_i:
+ vreg_s8b_1p256: smps8 {
+ regulator-name = "vreg_s8b_1p256";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
+ };
+
+ vreg_l1b_0p912: ldo1 {
+ regulator-name = "vreg_l1b_0p912";
+ regulator-min-microvolt = <825000>;
+ regulator-max-microvolt = <925000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_usbhs_3p1:
+ vreg_l2b_3p072: ldo2 {
+ regulator-name = "vreg_l2b_3p072";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3b_0p6: ldo3 {
+ regulator-name = "vreg_l3b_0p6";
+ regulator-min-microvolt = <312000>;
+ regulator-max-microvolt = <910000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_dsi_0_1p2:
+ vdd_a_ufs_0_1p2:
+ vreg_l6b_1p2: ldo6 {
+ regulator-name = "vreg_l6b_1p2";
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_2p96: ldo7 {
+ regulator-name = "vreg_l7b_2p96";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_0p904: ldo8 {
+ regulator-name = "vreg_l8b_0p904";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_1p2: ldo9 {
+ regulator-name = "vreg_l9b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p776: ldo11 {
+ regulator-name = "vreg_l11b_1p776";
+ regulator-min-microvolt = <1504000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_0p8: ldo12 {
+ regulator-name = "vreg_l12b_0p8";
+ regulator-min-microvolt = <751000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_0p8: ldo13 {
+ regulator-name = "vreg_l13b_0p8";
+ regulator-min-microvolt = <530000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_1p2: ldo14 {
+ regulator-name = "vreg_l14b_1p2";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_0p88: ldo15 {
+ regulator-name = "vreg_l15b_0p88";
+ regulator-min-microvolt = <765000>;
+ regulator-max-microvolt = <1020000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_1p2: ldo16 {
+ regulator-name = "vreg_l16b_1p2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_1p8: ldo17 {
+ regulator-name = "vreg_l17b_1p8";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l18b_1p8: ldo18 {
+ regulator-name = "vreg_l18b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd18_io:
+ vreg_l19b_1p8: ldo19 {
+ regulator-name = "vreg_l19b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8350c-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s9-supply = <&vph_pwr>;
+ vdd-s10-supply = <&vph_pwr>;
+
+ vdd-l1-l12-supply = <&vreg_s1b_1p856>;
+ vdd-l2-l8-supply = <&vreg_s1b_1p856>;
+ vdd-l3-l4-l5-l7-l13-supply = <&vreg_bob>;
+ vdd-l6-l9-l11-supply = <&vreg_bob>;
+ vdd-l10-supply = <&vreg_s7b_0p952>;
+
+ vdd-bob-supply = <&vph_pwr>;
+
+ /*
+ * S2, S5, S7, S10 are ARCs:
+ * S2 - cx.lvl,
+ * S5 - mss.lvl,
+ * S7 - gfx.lvl,
+ * S10 - mx.lvl.
+ */
+
+ vdd22_wlpa_s1c:
+ vreg_s1c_2p2: smps1 {
+ regulator-name = "vreg_s1c_2p2";
+ regulator-min-microvolt = <2190000>;
+ regulator-max-microvolt = <2210000>;
+ };
+
+ vreg_s9c_0p676: smps9 {
+ regulator-name = "vreg_s9c_0p676";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1170000>;
+ };
+
+ vdd_a_usbhs_1p8:
+ vdd_qfprom:
+ vreg_l1c_1p8: ldo1 {
+ regulator-name = "vreg_l1c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ iovdd_ts:
+ vreg_l2c_1p8: ldo2 {
+ regulator-name = "vreg_l2c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_ts:
+ vreg_l3c_3p0: ldo3 {
+ regulator-name = "vreg_l3c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c_1p8_3p0: ldo4 {
+ regulator-name = "vreg_l4c_1p8_3p0";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5c_1p8_3p0: ldo5 {
+ regulator-name = "vreg_l5c_1p8_3p0";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c_2p96: ldo6 {
+ regulator-name = "vreg_l6c_2p96";
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_3p0: ldo7 {
+ regulator-name = "vreg_l7c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c_1p8: ldo8 {
+ regulator-name = "vreg_l8c_1p8";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c_3p3: ldo9 {
+ regulator-name = "vreg_l9c_2p96";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_dsi_0_0p9:
+ vdd_a_ufs_0_core:
+ vdd_a_usbhs_core:
+ vreg_l10c_0p88: ldo10 {
+ regulator-name = "vreg_l10c_0p88";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11c_2p8: ldo11 {
+ regulator-name = "vreg_l11c_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ disp_iovcc_1p8:
+ vreg_l12c_1p8: ldo12 {
+ regulator-name = "vreg_l12c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ disp_vci_3p0:
+ vreg_l13c_3p0: ldo13 {
+ regulator-name = "vreg_l13c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ audio_sw_vcc:
+ vreg_bob: bob {
+ regulator-name = "vreg_bob";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+ };
+};
+
+&gcc {
+ protected-clocks = <GCC_CFG_NOC_LPASS_CLK>,
+ <GCC_MSS_CFG_AHB_CLK>,
+ <GCC_MSS_OFFLINE_AXI_CLK>,
+ <GCC_MSS_Q6SS_BOOT_CLK_SRC>,
+ <GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+ <GCC_MSS_SNOC_AXI_CLK>,
+ <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+ <GCC_QSPI_CORE_CLK>,
+ <GCC_QSPI_CORE_CLK_SRC>,
+ <GCC_SEC_CTRL_CLK_SRC>,
+ <GCC_WPSS_AHB_BDG_MST_CLK>,
+ <GCC_WPSS_AHB_CLK>,
+ <GCC_WPSS_RSCP_CLK>;
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/sm7325/motorola/dubai/a660_zap.mbn";
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+
+ status = "okay";
+
+ typec-mux@42 {
+ compatible = "fcs,fsa4480";
+ reg = <0x42>;
+
+ interrupts-extended = <&tlmm 6 IRQ_TYPE_LEVEL_LOW>;
+
+ vcc-supply = <&audio_sw_vcc>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ fsa4480_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+ };
+};
+
+&ipa {
+ firmware-name = "qcom/sm7325/motorola/dubai/yupik_ipa_fws.mbn";
+ memory-region = <&ipa_fw_mem>;
+
+ qcom,gsi-loader = "self";
+
+ status = "okay";
+};
+
+&pm7250b_adc {
+ channel@4e {
+ reg = <ADC5_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "chg_skin_therm";
+ };
+
+ channel@4f {
+ reg = <ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "conn_therm";
+ };
+};
+
+&pm7250b_adc_tm {
+ status = "okay";
+
+ chg-skin-therm@0 {
+ reg = <0>;
+ io-channels = <&pm7250b_adc ADC5_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ conn-therm@1 {
+ reg = <1>;
+ io-channels = <&pm7250b_adc ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
+&pm7250b_gpios {
+ gpio-line-names = "FG_ALERT_N", /* GPIO_1 */
+ "SLAVECP_INT",
+ "NC",
+ "NC",
+ "NC",
+ "DOUBLER_STAT",
+ "NC",
+ "NC",
+ "NC",
+ "NC", /* GPIO_10 */
+ "NC",
+ "NC";
+};
+
+&pm7325_gpios {
+ gpio-line-names = "PA_THERM1", /* GPIO_1 */
+ "NC",
+ "NC",
+ "PA_THERM2",
+ "CBL_PWR_N",
+ "KYPD_VOL_UP_N",
+ "NC",
+ "NC",
+ "NC",
+ "NC"; /* GPIO_10 */
+
+ kypd_vol_up_n: kypd-volp-n-state {
+ pins = "gpio6";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ bias-pull-up;
+ input-enable;
+ power-source = <1>;
+ };
+};
+
+&pm8350c_gpios {
+ gpio-line-names = "NC", /* GPIO_1 */
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC"; /* GPIO_9 */
+};
+
+&pm8350c_flash {
+ status = "okay";
+
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <4>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <400000>;
+ };
+
+ led-1 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <2>, <3>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <400000>;
+ };
+};
+
+&pmk8350_adc_tm {
+ status = "okay";
+
+ xo-therm@0 {
+ reg = <0>;
+ io-channels = <&pmk8350_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ quiet-therm@1 {
+ reg = <1>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ cam-flash-therm@2 {
+ reg = <2>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ sdm-skin-therm@3 {
+ reg = <3>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ chg-therm@4 {
+ reg = <4>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ pa-therm-1@5 {
+ reg = <5>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_GPIO1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ pa-therm-2@6 {
+ reg = <6>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_GPIO4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
+&pmk8350_gpios {
+ gpio-line-names = "NC", /* GPIO_0 */
+ "NC",
+ "TP_PMK_GPIO_3",
+ "PMK_OPTION"; /* GPIO_4 */
+};
+
+&pmk8350_rtc {
+ status = "okay";
+};
+
+&pmk8350_vadc {
+ status = "okay";
+
+ channel@44 {
+ reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pmk8350_xo_therm";
+ };
+
+ channel@144 {
+ reg = <PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_quiet_therm";
+ };
+
+ channel@145 {
+ reg = <PM7325_ADC7_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_cam_flash_therm";
+ };
+
+ channel@146 {
+ reg = <PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_sdm_skin_therm";
+ };
+
+ channel@147 {
+ reg = <PM7325_ADC7_AMUX_THM4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_chg_therm";
+ };
+
+ channel@14a {
+ reg = <PM7325_ADC7_GPIO1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_pa_therm1";
+ };
+
+ channel@14d {
+ reg = <PM7325_ADC7_GPIO4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_pa_therm2";
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qfprom {
+ vcc-supply = <&vdd_qfprom>;
+};
+
+&qup_spi13_cs {
+ drive-strength = <6>;
+ bias-pull-down;
+};
+
+&qup_spi13_data_clk {
+ drive-strength = <6>;
+ bias-pull-down;
+};
+
+&qup_uart5_rx {
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qup_uart5_tx {
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qup_uart7_cts {
+ /*
+ * Configure a bias-bus-hold on CTS to lower power
+ * usage when Bluetooth is turned off. Bus hold will
+ * maintain a low power state regardless of whether
+ * the Bluetooth module drives the pin in either
+ * direction or leaves the pin fully unpowered.
+ */
+ bias-bus-hold;
+};
+
+&qup_uart7_rts {
+ /* We'll drive RTS, so no pull */
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qup_uart7_rx {
+ /*
+ * Configure a pull-up on RX. This is needed to avoid
+ * garbage data when the TX pin of the Bluetooth module is
+ * in tri-state (module powered off or not driving the
+ * signal yet).
+ */
+ bias-pull-up;
+};
+
+&qup_uart7_tx {
+ /* We'll drive TX, so no pull */
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm7325/motorola/dubai/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm7325/motorola/dubai/cdsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/sm7325/motorola/dubai/modem.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_wpss {
+ firmware-name = "qcom/sm7325/motorola/dubai/wpss.mbn";
+
+ status = "okay";
+};
+
+&rmtfs_mem {
+ qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>,
+ <QCOM_SCM_VMID_NAV>;
+};
+
+&spi13 {
+ status = "okay";
+
+ touchscreen@0 {
+ compatible = "goodix,gt9916";
+ reg = <0>;
+
+ interrupts-extended = <&tlmm 81 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&tlmm 105 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&vdd_ts>;
+ vddio-supply = <&iovdd_ts>;
+
+ spi-max-frequency = <1000000>;
+
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <2400>;
+
+ pinctrl-0 = <&ts_int_n>, <&ts_reset_n>;
+ pinctrl-names = "default";
+ };
+};
+
+&tlmm {
+ gpio-line-names = "NC", /* GPIO_0 */
+ "NC",
+ "NC",
+ "NC",
+ "SMARTPA_I2C_SDA",
+ "SMARTPA_I2C_SCK",
+ "AUD_4480_DET",
+ "AUD_4480_INT",
+ "FASTCHARGE_I2C_SDA",
+ "FASTCHARGE_I2C_SCL",
+ "SM_GPSLNA_EN_GPIO10", /* GPIO_10 */
+ "NC",
+ "PERI_I2C_SDA",
+ "PERI_I2C_SCL",
+ "NC",
+ "NC",
+ "APPS_I2C_SDA",
+ "APPS_I2C_SCL",
+ "NC",
+ "DISP_LDO_EN",
+ "CAM_FW_RST_N", /* GPIO_20 */
+ "CAM_RM_RST_N",
+ "DBG_UART_TXD",
+ "DBG_UART_RXD",
+ "TOPSB_INT_N",
+ "MCAM_LDO_EN",
+ "HOST2WLAN_SOL",
+ "WLAN2HOST_SOL",
+ "UART_BT_RTS_AP_CTS",
+ "UART_BT_CTS_AP_RTS",
+ "UART_BT_RX_AP_TX", /* GPIO_30 */
+ "UART_BT_TX_AP_RX",
+ "FRONT_60M_INT",
+ "FRONT_60M_RST",
+ "FP_INT",
+ "FP_RST",
+ "NFC_I2C_SDA",
+ "NFC_I2C_SCL",
+ "NFC_EN",
+ "NFC_CLK_REQ",
+ "NFC_SE_SPI_NREST", /* GPIO_40 */
+ "NFC_IRQ",
+ "RF_LDO_GPIO42_EN",
+ "GOOGLE_KEY_INT", /* no such key exists */
+ "DISP_RST_N",
+ "SB_INT_N",
+ "HAP_RST_N",
+ "HAP_INT",
+ "ESE_SPI_MISO",
+ "ESE_SPI_MOSI",
+ "ESE_SPI_CLK", /* GPIO_50 */
+ "ESE_SPI_CS",
+ "TP_SPI_MISO",
+ "TP_SPI_MOSI",
+ "TP_SPI_CLK",
+ "TP_SPI_CS_N",
+ "FP_SPI_MISO",
+ "FP_SPI_MOSI",
+ "FP_SPI_CLK",
+ "FP_SPI_CS_N",
+ "HW_ID_1", /* GPIO_60 */
+ "HW_ID_2",
+ "CAM_PMU_EN",
+ "WIDE_DVDD_LDO_EN",
+ "CAM_MCLK0",
+ "CAM_MCLK1",
+ "CAM_MCLK2",
+ "CAM_MCLK3",
+ "NC",
+ "CCI_I2C_SDA0",
+ "CCI_I2C_SCL0", /* GPIO_70 */
+ "CCI_I2C_SDA1",
+ "CCI_I2C_SCL1",
+ "CCI_I2C_SDA2",
+ "CCI_I2C_SCL2",
+ "CCI_I2C_SDA3",
+ "CCI_I2C_SCL3",
+ "CAM_RT_RST_N",
+ "CAM_RU_RST_N",
+ "FCAM_LDO_EN",
+ "DISP_TE", /* GPIO_80 */
+ "TP_INT_N",
+ "FORCED_USB_BOOT",
+ "SM_CDC_RST_N",
+ "WLAN_EN",
+ "BT_EN",
+ "WCN_SW_CTRL",
+ "PCIE0_RESET_N",
+ "PCIE0_CLK_REQ_N",
+ "PCIE0_WAKE_N",
+ "MOS_AS_EN", /* GPIO_90 */
+ "NC",
+ "",
+ "NC",
+ "BT_FM_SLIMBUS_CLK",
+ "BT_FM_SLIMBUS_DATA",
+ "NC",
+ "RFCONN_DET_1",
+ "RF_CON_DET_2",
+ "RF_CON_DET_3",
+ "NC", /* GPIO_100 */
+ "NC",
+ "NC",
+ "ACCEL_INT",
+ "NC",
+ "TP_RST_N",
+ "NC",
+ "NC",
+ "NC",
+ "UIM2_DATA",
+ "UIM2_CLK", /* GPIO_110 */
+ "UIM2_RESET",
+ "UIM2_PRESENT",
+ "UIM1_DATA",
+ "UIM1_CLK",
+ "UIM1_RESET",
+ "UIM1_PRESENT",
+ "SM_RFFE0_CLK",
+ "SM_RFFE0_DATA",
+ "SM_RFFE1_CLK",
+ "SM_RFFE1_DATA", /* GPIO_120 */
+ "PA_MUTING",
+ "SM_GRFC5",
+ "LAA_RX",
+ "SM_GRFC7",
+ "SM_RFFE4_CLK",
+ "SM_RFFE4_DATA",
+ "WLAN_COEX_UART_RX",
+ "WLAN_COEX_UART_TX",
+ "NC",
+ "NC", /* GPIO_130 */
+ "SM_GRFC12",
+ "NC",
+ "QLINK0_REQUEST",
+ "QLINK0_ENABLE",
+ "QLINK0_WMSS_RESET_N",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "USB_CC_DIR", /* GPIO_140 */
+ "SAR_INT_N",
+ "PROX_INT_N",
+ "",
+ "SM_SWR_TX_CLK",
+ "SM_SWR_TX_DATA0",
+ "SM_SWR_TX_DATA1",
+ "SM_SWR_RX_CLK",
+ "SM_SWR_RX_DATA0",
+ "SM_SWR_RX_DATA1",
+ "NC", /* GPIO_150 */
+ "NC",
+ "NC",
+ "NC",
+ "SB_MI2S_SCK",
+ "SB_MI2S_WS",
+ "SB_MI2S_RXDAT_AP_TX",
+ "SB_MI2S_TXDAT_AP_RX",
+ "NC",
+ "SNS_I3C0_SDA",
+ "SNS_I3C0_SCL", /* GPIO_160 */
+ "SSC_I2C4_SDA",
+ "SSC_I2C4_SCL",
+ "MAG_I2C_SDA",
+ "MAG_I2C_SCL",
+ "NC",
+ "NC",
+ "",
+ "",
+ "",
+ "", /* GPIO_170 */
+ "SSC_BT_UART4_TX",
+ "SSC_BT_UART4_RX",
+ "NC",
+ "NC";
+ gpio-reserved-ranges = <48 4>, /* SPI (eSE - embedded Secure Element) */
+ <56 4>; /* SPI (fingerprint reader) */
+
+ qup_uart7_sleep_cts: qup-uart7-sleep-cts-state {
+ pins = "gpio28";
+ function = "gpio";
+ /*
+ * Configure a bias-bus-hold on CTS to lower power
+ * usage when Bluetooth is turned off. Bus hold will
+ * maintain a low power state regardless of whether
+ * the Bluetooth module drives the pin in either
+ * direction or leaves the pin fully unpowered.
+ */
+ bias-bus-hold;
+ };
+
+ qup_uart7_sleep_rts: qup-uart7-sleep-rts-state {
+ pins = "gpio29";
+ function = "gpio";
+ /*
+ * Configure pull-down on RTS. As RTS is active low
+ * signal, pull it low to indicate the BT SoC that it
+ * can wakeup the system anytime from suspend state by
+ * pulling RX low (by sending wakeup bytes).
+ */
+ bias-pull-down;
+ };
+
+ qup_uart7_sleep_tx: qup-uart7-sleep-tx-state {
+ pins = "gpio30";
+ function = "gpio";
+ /*
+ * Configure pull-up on TX when it isn't actively driven
+ * to prevent BT SoC from receiving garbage during sleep.
+ */
+ bias-pull-up;
+ };
+
+ qup_uart7_sleep_rx: qup-uart7-sleep-rx-state {
+ pins = "gpio31";
+ function = "gpio";
+ /*
+ * Configure a pull-up on RX. This is needed to avoid
+ * garbage data when the TX pin of the Bluetooth module
+ * is floating which may cause spurious wakeups.
+ */
+ bias-pull-up;
+ };
+
+ oled_reset_n: oled-reset-n-state {
+ pins = "gpio44";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ aw86224_reset_default: aw86224-reset-default-state {
+ pins = "gpio46";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ aw86224_int_default: aw86224-int-default-state {
+ pins = "gpio47";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ mdp_vsync_p: mdp-vsync-p-state {
+ pins = "gpio80";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ ts_int_n: ts-int-n-state {
+ pins = "gpio81";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ bt_en: bt-en-state {
+ pins = "gpio85";
+ function = "gpio";
+ output-low;
+ bias-disable;
+ };
+
+ ts_reset_n: ts-int-n-state {
+ pins = "gpio105";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&uart7 {
+ /delete-property/ interrupts;
+ interrupts-extended = <&intc GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>,
+ <&tlmm 31 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-1 = <&qup_uart7_sleep_cts>,
+ <&qup_uart7_sleep_rts>,
+ <&qup_uart7_sleep_tx>,
+ <&qup_uart7_sleep_rx>;
+ pinctrl-names = "default",
+ "sleep";
+
+ status = "okay";
+
+ bluetooth: bluetooth {
+ compatible = "qcom,wcn6750-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+
+ max-speed = <3200000>;
+
+ qcom,local-bd-address-broken;
+ };
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l7b_2p96>;
+ vcc-max-microamp = <800000>;
+
+ vccq-supply = <&vreg_l9b_1p2>;
+ vccq-max-microamp = <900000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vdd_a_ufs_0_core>;
+ vdda-pll-supply = <&vdd_a_ufs_0_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ /* USB 2.0 only */
+ qcom,select-utmi-as-pipe-clk;
+ maximum-speed = "high-speed";
+
+ /* Remove USB3 phy */
+ phys = <&usb_1_hsphy>;
+ phy-names = "usb2-phy";
+
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vdd_a_usbhs_core>;
+ vdda18-supply = <&vdd_a_usbhs_1p8>;
+ vdda33-supply = <&vdd_a_usbhs_3p1>;
+
+ status = "okay";
+};
+
+&venus {
+ firmware-name = "qcom/sm7325/motorola/dubai/vpu20_1v.mbn";
+
+ status = "okay";
+};
+
+&wifi {
+ qcom,calibration-variant = "Motorola_dubai";
+
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: qcom: Add SM7325 Motorola edge 30 (dubai)
From: Val Packett @ 2026-03-29 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Val Packett, linux-arm-msm, devicetree, linux-kernel
Motorola edge 30 (motorola,dubai) is a smartphone based on the
SM7325 SoC.
Signed-off-by: Val Packett <val@packett.cool>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index ca880c105f3b..58f1621bb855 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1038,6 +1038,7 @@ properties:
- items:
- enum:
+ - motorola,dubai
- nothing,spacewar
- const: qcom,sm7325
--
2.53.0
^ permalink raw reply related
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