* [PATCH] usb: mtu3: allocate phys with ssusb
From: Rosen Penev @ 2026-04-11 3:57 UTC (permalink / raw)
To: linux-usb
Cc: Chunfeng Yun, Greg Kroah-Hartman, Kees Cook, Gustavo A. R. Silva,
moderated list:MEDIATEK USB3 DRD IP DRIVER,
moderated list:MEDIATEK USB3 DRD IP DRIVER, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member to combine allocations. Allows removal of a
pointless branch. A size of 0 means phys are not allocated.
Add __counted_by for extra runtime analysis.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/usb/mtu3/mtu3.h | 2 +-
drivers/usb/mtu3/mtu3_plat.c | 18 ++++++------------
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index ba5a63669e5f..d71849388602 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -252,7 +252,6 @@ struct ssusb_mtk {
struct mtu3 *u3d;
void __iomem *mac_base;
void __iomem *ippc_base;
- struct phy **phys;
int num_phys;
int wakeup_irq;
/* common power & clock */
@@ -272,6 +271,7 @@ struct ssusb_mtk {
struct regmap *uwk;
u32 uwk_reg_base;
u32 uwk_vers;
+ struct phy *phys[] __counted_by(num_phys);
};
/**
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index cc8a864dbd63..11a919fc3d47 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -240,17 +240,6 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
if (ret)
return ret;
- ssusb->num_phys = of_count_phandle_with_args(node,
- "phys", "#phy-cells");
- if (ssusb->num_phys > 0) {
- ssusb->phys = devm_kcalloc(dev, ssusb->num_phys,
- sizeof(*ssusb->phys), GFP_KERNEL);
- if (!ssusb->phys)
- return -ENOMEM;
- } else {
- ssusb->num_phys = 0;
- }
-
for (i = 0; i < ssusb->num_phys; i++) {
ssusb->phys[i] = devm_of_phy_get_by_index(dev, node, i);
if (IS_ERR(ssusb->phys[i])) {
@@ -330,12 +319,17 @@ static int mtu3_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct ssusb_mtk *ssusb;
int ret = -ENOMEM;
+ int num_phys;
+ num_phys = of_count_phandle_with_args(dev->of_node,
+ "phys", "#phy-cells");
/* all elements are set to ZERO as default value */
- ssusb = devm_kzalloc(dev, sizeof(*ssusb), GFP_KERNEL);
+ ssusb = devm_kzalloc(dev, struct_size(ssusb, phys, num_phys), GFP_KERNEL);
if (!ssusb)
return -ENOMEM;
+ ssusb->num_phys = num_phys;
+
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret) {
dev_err(dev, "No suitable DMA config available\n");
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan @ 2026-04-11 3:00 UTC (permalink / raw)
To: Mathieu Poirier, Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <adkcugNgyrkHtUML@p14s>
> Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> SM CPU/LMM reset vector
>
> On Thu, Apr 09, 2026 at 08:30:54AM +0800, Peng Fan wrote:
> > On Wed, Apr 08, 2026 at 09:46:32AM -0600, Mathieu Poirier wrote:
> > >On Wed, Apr 08, 2026 at 01:30:16AM +0000, Peng Fan wrote:
> > >> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass
> bootaddr
> > >> > to SM CPU/LMM reset vector
> > >> >
> > >> [...]
> > >> >
> > >> > >
> > >> > > Aligning the ELF entry point with the hardware reset base on
> > >> > Cortex‑M
> > >> > > systems is possible, but it comes with several risks.
> > >> >
> > >> > I'm not asking to align the ELF entry point with the hardware
> reset base.
> > >> > All I want is to have the correct start address embedded in the
> > >> > ELF file to avoid having to use a mask.
> > >>
> > >> I see, per my understanding:
> > >> FreeRTOS typically exposes __isr_vector, which corresponds to the
> > >> hardware reset / vector table base.
> > >> Zephyr (Cortex‑M) exposes _vector_table, which serves the same
> purpose.
> > >> I am not certain about other RTOSes, but the pattern seems
> consistent:
> > >> the vector table base is already available as a named ELF symbol.
> > >>
> > >> Given that, if the preferred approach is to parse the ELF and
> > >> explicitly retrieve the hardware reset base, I can update the
> implementation accordingly.
> > >> If you prefer to parse the elf file to get the hardware reset base,
> > >> I could update to use them.
> > >>
> > >> Options1: Something as below:
> > >> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c 2.
> Use
> > >> below in imx_rproc.c ret = rproc_elf_find_symbol(rproc, fw,
> > >> "__isr_vector", &vector_base); if (ret)
> > >> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table",
> > >> &vector_base);
> > >>
> > >> if (!ret)
> > >> rproc->bootaddr = vector_base
> > >> else
> > >> dev_info(dev, "no __isr_vector or __vector_table\n")
> > >
> > >No
> >
> > If your concern is about rproc->bootaddr, I could introduce
> > imx_rproc->vector_base for i.MX. Please help detail a bit.
> >
> > >
> > >>
> > >> This makes the hardware reset base explicit, avoids masking
> e_entry.
> > >>
> > >> Option 2: User‑provided reset symbol via sysfs As an alternative,
> > >> we could expose a sysfs attribute, e.g. reset_symbol, allowing
> > >> users to specify the symbol name to be used as the reset base:
> > >>
> > >> echo __isr_vector >
> /sys/class/remoteproc/remoteprocX/reset_symbol
> > >>
> > >
> > >Definitely not.
> > >
> > >The definition of e_entry in the specification is clear, i.e "the
> > >address of the entry point from where the process starts executing".
> > >If masking is required because the tool that puts the image together
> > >gets the wrong address, then it should be fixed.
> >
> > The hardware reset base is the address from which the hardware
> fetches
> > the initial stack pointer and program counter values and loads them
> > into the SP and PC registers. In contrast, bootaddr (i.e. e_entry)
> > represents the address at which the CPU starts executing code (the
> PC
> > value after reset). As you pointed out earlier, this distinction is clear.
> >
> > In our case, we need to obtain the hardware reset base and pass that
> > value to the system firmware. However, e_entry should not be set to
> > the hardware reset base. Doing so would introduce the issues I
> > described in [1]. This means we should not modify the Zephyr or
> > FreeRTOS build outputs to make e_entry equal to the hardware reset
> base.
>
>
> As I said earlier, I am _not_ suggesting to make e_entry equal to the
> hardware reset base.
Let me try to restate my understanding more precisely and please
correct me if I am still missing the point.
From your comment:
"
If masking is required because the tool that puts the image together gets the
wrong address, then it should be fixed.
"
I understand this as saying that masking e_entry is not acceptable, because
e_entry already has a clear and correct meaning: it is the execution entry
address, and the kernel should not reinterpret or “fix up” that value.
At the same time, we still need to provide the hardware reset vector base
to the system firmware, and that value is distinct from e_entry.
On i.MX94/5 platforms the reset base is software‑programmable, but that
information is not represented by e_entry, nor is there currently a
separate place in the remoteproc framework to convey a reset‑vector
base independent of the execution entry point.
Given these constraints, I see limited options on the kernel side.
One conservative approach would be to rely on a fixed, platform‑defined
reset base for the affected SoCs. And update RTOS linking script to put
the vector to the location of fixed hardware reset base.
Thanks,
Peng
>
> We are going in circles here.
>
> >
> > Given these constraints, the feasible solutions I can see are either:
> > - option 1 (explicitly retrieving the hardware reset base), or
> > - continuing to use masking.
> >
> > Please suggest.
> >
> > [1]
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> lore
> > .kernel.org%2Fall%2Facs2PAZq2k3zjmDW%40shlinux89%2F&data=0
> 5%7C02%7Cpen
> >
> g.fan%40nxp.com%7C8a5ce35d492b4adb2d3b08de97192cbb%7C686
> ea1d3bc2b4c6fa
> >
> 92cd99c5c301635%7C0%7C0%7C639114331565834960%7CUnknow
> n%7CTWFpbGZsb3d8e
> >
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> kFOIjoiTWF
> >
> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pnkirz3BMEuLsJU9
> MHQNon84HIyMX
> > 08x1wCK04dS7VU%3D&reserved=0
> >
> > Thanks,
> > Peng
> >
> > >
> > >> The remoteproc core would then resolve that symbol from the ELF
> and
> > >> set rproc->bootaddr accordingly.
> > >> This provides maximum flexibility but does introduce a new
> > >> user‑visible ABI, so I see it more as an opt‑in or fallback
> mechanism.
> > >>
> > >> Please let me know which approach you prefer, and I will update
> > >> this series accordingly in v3..
> > >>
> > >> Thanks,
> > >> Peng.
> > >>
> > >>
> > >> >
> > >> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2,
> Debuggers
> > >> > > may attempt to set breakpoints or start execution at the entry
> > >> > > symbol
> > >> > >
^ permalink raw reply
* [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
- eMMC module, you can optionally solder a SPI NOR in place and turn
off the eMMC
- PCIe-attached NIC (pcie2x1l1)
- PCIe NVMe slot (pcie2x1l2)
- AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
- BCM4345C5 Bluetooth
- es8388 audio
- USB 2.0 and USB 3.0
- Two HDMI ports, the second is connected to the SoC's DP controller
driven by a transparent LT8711UXD bridge that has firmware onboard and
needs no node defined.
Vendors description and links to schematics available:
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../display/rockchip/rockchip,dw-dp.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
4 files changed, 372 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
index 6345f0132d43..079a912d97f1 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
@@ -57,6 +57,13 @@ properties:
- const: i2s
- const: spdif
+ hpd-gpios:
+ maxItems: 1
+ description:
+ GPIO used for hot plug detection when the controller's native HPD
+ input is not connected. If not specified, the controller uses its
+ internal HPD detection mechanism.
+
phys:
maxItems: 1
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4d384f153c13..c99dca2ae9e7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
new file mode 100644
index 000000000000..84c83aa69f63
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,352 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Pro";
+ compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio;
+ };
+
+ dp-con {
+ compatible = "dp-connector";
+
+ port {
+ dp_con_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s2_2ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm15 0 1000000 0>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm3 0 1000000 0>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-levels = <0 50 100 150 200 255>;
+ fan-supply = <&vcc5v0_sys>;
+ pwms = <&pwm2 0 20000000 0>;
+ };
+
+ vcc3v3_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc3v3_phy1: regulator-vcc3v3-phy1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_phy1";
+ startup-delay-us = <50000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc5v0_otg: regulator-vcc5v0-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_otg_en>;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "vcc5v0_otg";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+
+ typea_con: usb-a-connector {
+ compatible = "usb-a-connector";
+ data-role = "host";
+ label = "USB3 Type-A";
+ power-role = "source";
+ vbus-supply = <&vcc5v0_otg>;
+ };
+};
+
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <&dp_con_in>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m4_xfer>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ es8388: audio-codec@11 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x11>;
+ #sound-dai-cells = <0>;
+ AVDD-supply = <&vcc_3v3_s0>;
+ DVDD-supply = <&vcc_1v8_s0>;
+ HPVDD-supply = <&vcc_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clock-rates = <12288000>;
+ assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
+ clocks = <&cru I2S2_2CH_MCLKOUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_mclk>;
+ };
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m3_xfer>;
+ status = "okay";
+};
+
+&i2s2_2ch {
+ pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
+ &i2s2m1_sdi &i2s2m1_sdo>;
+ status = "okay";
+};
+
+&package_thermal {
+ polling-delay = <1000>;
+
+ cooling-maps {
+ map0 {
+ trip = <&package_fan0>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map1 {
+ trip = <&package_fan1>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ package_fan0: package-fan0 {
+ hysteresis = <2000>;
+ temperature = <55000>;
+ type = "active";
+ };
+
+ package_fan1: package-fan1 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+};
+
+/* NVMe */
+&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
+ reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ supports-clkreq;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+};
+
+/* NIC */
+&pcie2x1l2 {
+ reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_phy1>;
+ status = "okay";
+};
+
+&pinctrl {
+ bluetooth {
+ bt_wake_gpio: bt-wake-pin {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host_irq: bt-wake-host-irq {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb {
+ vcc5v0_otg_en: vcc5v0-otg-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wlan {
+ wifi_host_wake_irq: wifi-host-wake-irq {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
+&pwm15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm15m2_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m1_pins>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3m2_pins>;
+ status = "okay";
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&sdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ ap6256: wifi@1 {
+ compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-names = "host-wake";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_irq>;
+ };
+};
+
+&uart9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wakeup";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1500000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
+ shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
+&usb_host0_xhci {
+ dr_mode = "host";
+};
+
+&usbdp_phy0 {
+ rockchip,dp-lane-mux = <0 1>;
+};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index fd23ca2834b0..b58f57b69b22 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -8,6 +8,7 @@
*/
#include <linux/bitfield.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
#include <linux/iopoll.h>
#include <linux/irq.h>
#include <linux/media-bus-format.h>
@@ -330,6 +331,8 @@ struct dw_dp {
u8 pixel_mode;
DECLARE_BITMAP(sdp_reg_bank, SDP_REG_BANK_SIZE);
+
+ struct gpio_desc *hpd_gpiod;
};
enum {
@@ -481,6 +484,9 @@ static bool dw_dp_hpd_detect(struct dw_dp *dp)
{
u32 value;
+ if (dp->hpd_gpiod)
+ return gpiod_get_value_cansleep(dp->hpd_gpiod);
+
regmap_read(dp->regmap, DW_DP_HPD_STATUS, &value);
return FIELD_GET(HPD_STATE, value) == DW_DP_HPD_STATE_PLUG;
@@ -2002,6 +2008,12 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
return ERR_CAST(dp->regmap);
}
+ dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
+ if (IS_ERR(dp->hpd_gpiod)) {
+ dev_err_probe(dev, PTR_ERR(dp->hpd_gpiod), "failed to get hpd GPIO\n");
+ return ERR_CAST(dp->hpd_gpiod);
+ }
+
dp->phy = devm_of_phy_get(dev, dev->of_node, NULL);
if (IS_ERR(dp->phy)) {
dev_err_probe(dev, PTR_ERR(dp->phy), "failed to get phy\n");
--
2.53.0
^ permalink raw reply related
* [PATCH v6 2/3] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
boards also use gmac for ethernet where the Pro has a PCIe attached NIC.
I have not changed the definitions from what was in rk3588s-orangepi-5.dtsi
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 +++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +-----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 209 insertions(+), 189 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..b04dd667605d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcc_3v3_s0>;
+ DVDD-supply = <&vcc_1v8_s0>;
+ HPVDD-supply = <&vcc_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..5c154cc6c62a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
vbus_typec: regulator-vbus-typec {
compatible = "regulator-fixed";
enable-active-high;
@@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
vin-supply = <&vcc5v0_sys>;
};
- vcc5v0_sys: regulator-vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
@@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_3v3_s3>;
};
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
};
&combphy0_ps {
@@ -161,20 +111,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +206,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,18 +219,6 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
@@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
};
};
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
-};
-
&rknn_core_0 {
npu-supply = <&vdd_npu_s0>;
sram-supply = <&vdd_npu_s0>;
@@ -841,26 +696,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +708,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +719,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +727,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/3] Add support for Orange Pi 5 Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
From: Dennis Gilmore <dennis@ausil.us>
This series adds initial support for Orange Pi 5 Pro. The PCIe attached network
driver(dwmac-motorcomm) was just added.
The series was tested against Linux 7.0-rc7
Please take a look.
Thank you,
Dennis Gilmore
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5 https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4 https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3 https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purppose
- actually clean up the delete lines and comments missed in v2
- link to v2 https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- Link to v1 https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (3):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/rockchip/rockchip,dw-dp.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 ++++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +---------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
9 files changed, 582 insertions(+), 189 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
^ permalink raw reply
* [PATCH] arm: Kconfig: fix duplicate words in help text
From: Michael Ugrin @ 2026-04-11 1:19 UTC (permalink / raw)
To: Russell King
Cc: Arnd Bergmann, Kees Cook, linux-arm-kernel, linux-kernel,
Michael Ugrin
Remove two instances of duplicate words in Kconfig help text.
Signed-off-by: Michael Ugrin <mugrinphoto@gmail.com>
---
arch/arm/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec33376f8e2ba..e62af2a34f59f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1486,7 +1486,7 @@ config ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND
bool "Extend with bootloader kernel arguments"
help
The command-line arguments provided by the boot loader will be
- appended to the the device tree bootargs property.
+ appended to the device tree bootargs property.
endchoice
@@ -1628,7 +1628,7 @@ config DMI
continue to boot on existing non-UEFI platforms.
NOTE: This does *NOT* enable or encourage the use of DMI quirks,
- i.e., the the practice of identifying the platform via DMI to
+ i.e., the practice of identifying the platform via DMI to
decide whether certain workarounds for buggy hardware and/or
firmware need to be enabled. This would require the DMI subsystem
to be enabled much earlier than we do on ARM, which is non-trivial.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: Jie Gan @ 2026-04-11 1:08 UTC (permalink / raw)
To: James Clark, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-6-55d3ef997c48@linaro.org>
Hi James,
On 4/7/2026 10:05 PM, James Clark wrote:
> Any IMPDEF events not printed out from a known core's IMPDEF list or for
> a completely unknown core will still not be shown to the user. Fix this
> by printing the remaining bits as comma separated raw numbers, e.g.
> "IMPDEF:1,2,3,4".
>
> Suggested-by: Al Grant <al.grant@arm.com>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index b74f887a48f2..c65b22a2179c 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -8,6 +8,7 @@
> #include <string.h>
> #include <endian.h>
> #include <byteswap.h>
> +#include <linux/bitmap.h>
> #include <linux/bitops.h>
> #include <stdarg.h>
> #include <linux/kernel.h>
> @@ -365,6 +366,23 @@ static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> payload);
> }
>
> + /*
> + * Print remaining IMPDEF bits that weren't printed above as raw
> + * "IMPDEF:1,2,3,4" etc.
> + */
> + if (payload) {
> + int i;
> +
> + arm_spe_pkt_out_string(&err, &buf, &buf_len, " IMPDEF:");
> + for_each_set_bit(i, &payload, 64) {
for_each_set_bit(i, &payload, 64) passes &payload where payload is u64.
The macro expands to find_next_bit(const unsigned long *addr, ...). On a
32-bit host unsigned long is 32 bits wide, so only the low 32 bits of
payload would be scanned; bits 32–63 would be silently ignored. While
perf is almost always built on a 64-bit host today, the tools/ tree is
explicitly portable and the compiler will emit a -Wpointer-arith /
-Wincompatible-pointer-types warning on a 32-bit build.
Thanks,
Jie
> + const char *sep = payload & (payload - 1) ? "," : "";
> +
> + arm_spe_pkt_out_string(&err, &buf, &buf_len, "%d%s", i,
> + sep);
> + payload &= ~BIT_ULL(i);
> + }
> + }
> +
> return err;
> }
>
>
^ permalink raw reply
* Re: [PATCH v3 0/8] perf libunwind multiple remote support
From: Ian Rogers @ 2026-04-11 1:04 UTC (permalink / raw)
To: acme
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260404054032.1538095-1-irogers@google.com>
On Fri, Apr 3, 2026 at 10:40 PM Ian Rogers <irogers@google.com> wrote:
>
> Fix the libunwind build for when libdw and libunwind are feature
> detected, currently failing with a duplicate symbol.
>
> Refactor the libunwind support so that whenever a remote target is
> available, perf functions using the ELF machine can use that remote
> target regardless of what the host/local machine is. Migrate existing
> libunwind supported architectures like powerpc, arm64 and loongarch so
> that they can work in a cross-architecture way. Add support for
> RISC-V. Make the code more regular in function names, etc. and avoid
> including a C-file. This increases the lines of code. It is similar in
> style to the unwind-libdw implementation. It is hoped that the more
> uniform nature of the code with help with refactoring the perf
> registers for SIMD/APX support.
>
> Aside from local host testing these patches are under tested, in part
> as I'm failing to see how to build libunwind with support for multiple
> remote targets. Please could I get help in testing.
>
> v3: Minor whitespace clean up and warn when a dynamic choice of libdw
> or libunwind is selected for unwinding and support is missing (Arnaldo).
Hi Arnaldo,
anything else outstanding from this series?
Thanks,
Ian
> v2: Move two fixes patches to position 1 and 2 in the series. Fix
> struct naming inconsistency, Andrew Jones
> <andrew.jones@oss.qualcomm.com>. Fix other inconsistencies and
> potential non-x86 build issues.
> https://lore.kernel.org/lkml/20260305221927.3237145-1-irogers@google.com/
>
> v1: https://lore.kernel.org/lkml/20260224142938.26088-1-irogers@google.com/
>
> Ian Rogers (8):
> perf unwind: Refactor get_entries to allow dynamic libdw/libunwind
> selection
> perf build loongarch: Remove reference to missing file
> tools build: Deduplicate test-libunwind for different architectures
> perf build: Be more programmatic when setting up libunwind variables
> perf unwind-libunwind: Make libunwind register reading cross platform
> perf unwind-libunwind: Move flush/finish access out of local
> perf unwind-libunwind: Remove libunwind-local
> perf unwind-libunwind: Add RISC-V libunwind support
>
> tools/build/feature/Makefile | 38 +-
> tools/build/feature/test-libunwind-aarch64.c | 27 -
> tools/build/feature/test-libunwind-arm.c | 28 -
> .../test-libunwind-debug-frame-aarch64.c | 17 -
> .../feature/test-libunwind-debug-frame-arm.c | 17 -
> .../feature/test-libunwind-debug-frame.c | 1 -
> tools/build/feature/test-libunwind-x86.c | 28 -
> tools/build/feature/test-libunwind-x86_64.c | 28 -
> tools/build/feature/test-libunwind.c | 1 -
> tools/perf/Makefile.config | 215 ++---
> tools/perf/arch/arm/util/Build | 2 -
> tools/perf/arch/arm/util/unwind-libunwind.c | 50 --
> tools/perf/arch/arm64/util/Build | 1 -
> tools/perf/arch/arm64/util/unwind-libunwind.c | 17 -
> tools/perf/arch/loongarch/util/Build | 3 -
> .../arch/loongarch/util/unwind-libunwind.c | 82 --
> tools/perf/arch/mips/Build | 1 -
> tools/perf/arch/mips/util/Build | 1 -
> tools/perf/arch/mips/util/unwind-libunwind.c | 22 -
> tools/perf/arch/powerpc/util/Build | 1 -
> .../perf/arch/powerpc/util/unwind-libunwind.c | 92 --
> tools/perf/arch/x86/util/Build | 3 -
> tools/perf/arch/x86/util/unwind-libunwind.c | 115 ---
> tools/perf/builtin-inject.c | 4 +
> tools/perf/builtin-report.c | 4 +
> tools/perf/builtin-script.c | 4 +
> tools/perf/util/Build | 5 +-
> tools/perf/util/libunwind-arch/Build | 11 +
> .../perf/util/libunwind-arch/libunwind-arch.c | 319 +++++++
> .../perf/util/libunwind-arch/libunwind-arch.h | 296 +++++++
> .../perf/util/libunwind-arch/libunwind-arm.c | 290 ++++++
> .../util/libunwind-arch/libunwind-arm64.c | 289 ++++++
> .../perf/util/libunwind-arch/libunwind-i386.c | 312 +++++++
> .../util/libunwind-arch/libunwind-loongarch.c | 297 +++++++
> .../perf/util/libunwind-arch/libunwind-mips.c | 299 +++++++
> .../util/libunwind-arch/libunwind-ppc32.c | 301 +++++++
> .../util/libunwind-arch/libunwind-ppc64.c | 303 +++++++
> .../util/libunwind-arch/libunwind-riscv.c | 297 +++++++
> .../perf/util/libunwind-arch/libunwind-s390.c | 299 +++++++
> .../util/libunwind-arch/libunwind-x86_64.c | 320 +++++++
> tools/perf/util/libunwind/arm64.c | 40 -
> tools/perf/util/libunwind/x86_32.c | 41 -
> tools/perf/util/maps.c | 29 +-
> tools/perf/util/maps.h | 4 +-
> tools/perf/util/symbol_conf.h | 10 +
> tools/perf/util/thread.c | 29 +-
> tools/perf/util/unwind-libdw.c | 2 +-
> tools/perf/util/unwind-libunwind-local.c | 832 ------------------
> tools/perf/util/unwind-libunwind.c | 679 ++++++++++++--
> tools/perf/util/unwind.c | 98 +++
> tools/perf/util/unwind.h | 77 +-
> 51 files changed, 4549 insertions(+), 1732 deletions(-)
> delete mode 100644 tools/build/feature/test-libunwind-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-x86.c
> delete mode 100644 tools/build/feature/test-libunwind-x86_64.c
> delete mode 100644 tools/perf/arch/arm/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/arm64/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/loongarch/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/mips/Build
> delete mode 100644 tools/perf/arch/mips/util/Build
> delete mode 100644 tools/perf/arch/mips/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/powerpc/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/x86/util/unwind-libunwind.c
> create mode 100644 tools/perf/util/libunwind-arch/Build
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arch.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arch.h
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arm.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arm64.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-i386.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-loongarch.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-mips.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-ppc32.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-ppc64.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-riscv.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-s390.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-x86_64.c
> delete mode 100644 tools/perf/util/libunwind/arm64.c
> delete mode 100644 tools/perf/util/libunwind/x86_32.c
> delete mode 100644 tools/perf/util/unwind-libunwind-local.c
> create mode 100644 tools/perf/util/unwind.c
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
^ permalink raw reply
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Nicolin Chen @ 2026-04-11 0:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410232500.GD2588311@nvidia.com>
On Fri, Apr 10, 2026 at 08:25:00PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2026 at 03:06:32PM -0700, Nicolin Chen wrote:
> > On Thu, Apr 09, 2026 at 09:27:34PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> > By taking a closer look, I think either the arm_smmu_domain_inv call
> > above or any concurrent arm_smmu_mm_arch_invalidate_secondary_tlbs
> > call is a NOP now?
>
> That sounds right, with all the changes there should be no cache
> flushing on the free path since it is now always flushed on detach, so
> the arm_smmu_domain_inv() should be deleted here too.
Yea, I did that.
> > We reworked the ASID lifecycle, which now ends when the last device
> > detaches. So, ASID was free-ed in arm_smmu_iotlb_tag_free() that did
> > a per-ASID flush also.
>
> Yes, so the comment is:
>
> Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs() op can
> still be called/running at this point. Like the normal detach flow
> the RCU protected ASID may still experiance harmless invalidation.
> However unlike normal domains the SVA invalidation will continue
> into free until the mmu_notifier_put().
I updated that in my words but this reads more accurate. I will
use this (fixing the typo experiance).
Thanks
Nicolin
^ permalink raw reply
* [PATCH v2 0/3] pmdomain: core: add support for domain hierarchies in DT
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
Currently, PM domains can only support hierarchy for simple
providers (e.g. ones with #power-domain-cells = 0).
Add support for oncell providers as well by adding a new property
`power-domains-child-ids` to describe the parent/child relationship.
Also adds the first user of the new API: the Arm SCMI PM domain driver.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
This idea was previously discussed on the arm-scmi mailing list[1]
where this approach was proposed by Ulf, and then an initial RFC[2]
implementation was made. From there, it was suggested by Rob[3] to
use a nexus node map instead, which led to several more versions
attempting to implement that, culminating in v5[4], where Rob and
Geert then had second thoughts about the power-domain-map approach.
Therefore, I've gone back to the approach in the initial RFC[2] to use
the child-ids approach.
Changes compared to initial RFC[2]
- dropped RFC
- rewrote the parse/add function to use iterators/helpers from of.h
- add a remove function for cleanup
- use child domain language instead of subdomain
[1] https://lore.kernel.org/arm-scmi/CAPDyKFo_P129sVirHHYjOQT+QUmpymcRJme9obzKJeRgO7B-1A@mail.gmail.com/
[2] https://lore.kernel.org/all/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com/
[3] https://lore.kernel.org/all/20250528203532.GA704342-robh@kernel.org/
[4] https://lore.kernel.org/r/20260122-pmdomain-hierarchy-onecell-v5-0-76855ec856bd@baylibre.com
Changes in v2:
- dt-bindings: fix warinings from make dt_binding_check
- scmi_pm_domain: switch to dev_err()
- pmdomain: core: fix locking around add/remove domains
- pmdomain: error unwind if any children fail to be added
- pmdomain: fix node reference leak
- pmdomain: ensure power-domains and child-ids properties are same
length before iterating
- Link to v1: https://patch.msgid.link/20260310-topic-lpm-pmdomain-child-ids-v1-0-5361687a18ff@baylibre.com
---
Kevin Hilman (TI) (3):
dt-bindings: power: Add power-domains-child-ids property
pmdomain: core: add support for power-domains-child-ids
pmdomain: arm_scmi: add support for domain hierarchies
Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
drivers/pmdomain/core.c | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 16 ++++++++++++++++
4 files changed, 229 insertions(+), 1 deletion(-)
---
base-commit: f7b88edb52c8dd01b7e576390d658ae6eef0e134
change-id: 20260310-topic-lpm-pmdomain-child-ids-e3d57ae57040
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 3/3] pmdomain: arm_scmi: add support for domain hierarchies
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
After primary SCMI pmdomain is created, use new of_genpd helper which
checks for child domain mappings defined in power-domains-child-ids.
Also remove any child domain mappings when SCMI domain is removed.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index b5e2ffd5ea64..6d33b3d62ef3 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -114,6 +114,14 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
dev_set_drvdata(dev, scmi_pd_data);
+ /*
+ * Parse (optional) power-domains-child-ids property to
+ * establish parent-child relationships
+ */
+ ret = of_genpd_add_child_ids(np, scmi_pd_data);
+ if (ret < 0 && ret != -ENOENT)
+ dev_err(dev, "Failed to add child domain hierarchy: %d\n", ret);
+
return 0;
err_rm_genpds:
for (i = num_domains - 1; i >= 0; i--)
@@ -129,9 +137,13 @@ static void scmi_pm_domain_remove(struct scmi_device *sdev)
struct device *dev = &sdev->dev;
struct device_node *np = dev->of_node;
+ scmi_pd_data = dev_get_drvdata(dev);
+
+ /* Remove any parent-child relationships established at probe time */
+ of_genpd_remove_child_ids(np, scmi_pd_data);
+
of_genpd_del_provider(np);
- scmi_pd_data = dev_get_drvdata(dev);
for (i = 0; i < scmi_pd_data->num_domains; i++) {
if (!scmi_pd_data->domains[i])
continue;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] pmdomain: core: add support for power-domains-child-ids
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
Currently, PM domains can only support hierarchy for simple
providers (e.g. ones with #power-domain-cells = 0).
Add support for oncell providers as well by adding a new property
`power-domains-child-ids` to describe the parent/child relationship.
For example, an SCMI PM domain provider has multiple domains, each of
which might be a child of diffeent parent domains. In this example,
the parent domains are MAIN_PD and WKUP_PD:
scmi_pds: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
power-domains = <&MAIN_PD>, <&WKUP_PD>;
power-domains-child-ids = <15>, <19>;
};
With this example using the new property, SCMI PM domain 15 becomes a
child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
WKUP_PD.
To support this feature, add two new core functions
- of_genpd_add_child_ids()
- of_genpd_remove_child_ids()
which can be called by pmdomain providers to add/remove child domains
if they support the new property power-domains-child-ids.
The add function is "all or nothing". If it cannot add all of the
child domains in the list, it will unwind any additions already made
and report a failure.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/core.c | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 16 ++++++++++++++++
2 files changed, 182 insertions(+)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 61c2277c9ce3..f978477dd546 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2909,6 +2909,172 @@ static struct generic_pm_domain *genpd_get_from_provider(
return genpd;
}
+/**
+ * of_genpd_add_child_ids() - Parse power-domains-child-ids property
+ * @np: Device node pointer associated with the PM domain provider.
+ * @data: Pointer to the onecell data associated with the PM domain provider.
+ *
+ * Parse the power-domains and power-domains-child-ids properties to establish
+ * parent-child relationships for PM domains. The power-domains property lists
+ * parent domains, and power-domains-child-ids lists which child domain IDs
+ * should be associated with each parent.
+ *
+ * Uses "all or nothing" semantics: either all relationships are established
+ * successfully, or none are (any partially-added relationships are unwound
+ * on error).
+ *
+ * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
+ */
+int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ struct of_phandle_args parent_args;
+ struct generic_pm_domain *parent_genpd, *child_genpd;
+ struct generic_pm_domain **pairs; /* pairs[2*i]=parent, pairs[2*i+1]=child */
+ u32 child_id;
+ int i, ret, count, child_count, added = 0;
+
+ /* Check if both properties exist */
+ count = of_count_phandle_with_args(np, "power-domains", "#power-domain-cells");
+ if (count <= 0)
+ return -ENOENT;
+
+ child_count = of_property_count_u32_elems(np, "power-domains-child-ids");
+ if (child_count < 0)
+ return -ENOENT;
+ if (child_count != count)
+ return -EINVAL;
+
+ /* Allocate tracking array for error unwind (parent/child pairs) */
+ pairs = kmalloc_array(count * 2, sizeof(*pairs), GFP_KERNEL);
+ if (!pairs)
+ return -ENOMEM;
+
+ for (i = 0; i < count; i++) {
+ ret = of_property_read_u32_index(np, "power-domains-child-ids",
+ i, &child_id);
+ if (ret)
+ goto err_unwind;
+
+ /* Validate child ID is within bounds */
+ if (child_id >= data->num_domains) {
+ pr_err("Child ID %u out of bounds (max %u) for %pOF\n",
+ child_id, data->num_domains - 1, np);
+ ret = -EINVAL;
+ goto err_unwind;
+ }
+
+ /* Get the child domain */
+ child_genpd = data->domains[child_id];
+ if (!child_genpd) {
+ pr_err("Child domain %u is NULL for %pOF\n", child_id, np);
+ ret = -EINVAL;
+ goto err_unwind;
+ }
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", i,
+ &parent_args);
+ if (ret)
+ goto err_unwind;
+
+ /* Get the parent domain */
+ parent_genpd = genpd_get_from_provider(&parent_args);
+ of_node_put(parent_args.np);
+ if (IS_ERR(parent_genpd)) {
+ pr_err("Failed to get parent domain for %pOF: %ld\n",
+ np, PTR_ERR(parent_genpd));
+ ret = PTR_ERR(parent_genpd);
+ goto err_unwind;
+ }
+
+ /* Establish parent-child relationship */
+ ret = pm_genpd_add_subdomain(parent_genpd, child_genpd);
+ if (ret) {
+ pr_err("Failed to add child domain %u to parent in %pOF: %d\n",
+ child_id, np, ret);
+ goto err_unwind;
+ }
+
+ /* Track for potential unwind */
+ pairs[2 * added] = parent_genpd;
+ pairs[2 * added + 1] = child_genpd;
+ added++;
+
+ pr_debug("Added child domain %u (%s) to parent %s for %pOF\n",
+ child_id, child_genpd->name, parent_genpd->name, np);
+ }
+
+ kfree(pairs);
+ return 0;
+
+err_unwind:
+ /* Reverse all previously established relationships */
+ while (added-- > 0)
+ pm_genpd_remove_subdomain(pairs[2 * added], pairs[2 * added + 1]);
+ kfree(pairs);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_genpd_add_child_ids);
+
+/**
+ * of_genpd_remove_child_ids() - Remove parent-child PM domain relationships
+ * @np: Device node pointer associated with the PM domain provider.
+ * @data: Pointer to the onecell data associated with the PM domain provider.
+ *
+ * Reverses the effect of of_genpd_add_child_ids() by parsing the same
+ * power-domains and power-domains-child-ids properties and calling
+ * pm_genpd_remove_subdomain() for each established relationship.
+ *
+ * Returns 0 on success, -ENOENT if properties don't exist, or negative error
+ * code on failure.
+ */
+int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ struct of_phandle_args parent_args;
+ struct generic_pm_domain *parent_genpd, *child_genpd;
+ u32 child_id;
+ int i, ret, count, child_count;
+
+ /* Check if both properties exist */
+ count = of_count_phandle_with_args(np, "power-domains", "#power-domain-cells");
+ if (count <= 0)
+ return -ENOENT;
+
+ child_count = of_property_count_u32_elems(np, "power-domains-child-ids");
+ if (child_count < 0)
+ return -ENOENT;
+ if (child_count != count)
+ return -EINVAL;
+
+ for (i = 0; i < count; i++) {
+ if (of_property_read_u32_index(np, "power-domains-child-ids",
+ i, &child_id))
+ continue;
+
+ if (child_id >= data->num_domains || !data->domains[child_id])
+ continue;
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", i,
+ &parent_args);
+ if (ret)
+ continue;
+
+ parent_genpd = genpd_get_from_provider(&parent_args);
+ of_node_put(parent_args.np);
+ if (IS_ERR(parent_genpd))
+ continue;
+
+ child_genpd = data->domains[child_id];
+ pm_genpd_remove_subdomain(parent_genpd, child_genpd);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_genpd_remove_child_ids);
+
/**
* of_genpd_add_device() - Add a device to an I/O PM domain
* @genpdspec: OF phandle args to use for look-up PM domain
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index f67a2cb7d781..b44615d79af6 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -465,6 +465,10 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
int of_genpd_parse_idle_states(struct device_node *dn,
struct genpd_power_state **states, int *n);
void of_genpd_sync_state(struct device_node *np);
+int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data);
+int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data);
int genpd_dev_pm_attach(struct device *dev);
struct device *genpd_dev_pm_attach_by_id(struct device *dev,
@@ -534,6 +538,18 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
{
return ERR_PTR(-EOPNOTSUPP);
}
+
+static inline int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
#ifdef CONFIG_PM
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
Add binding documentation for the new power-domains-child-ids property,
which works in conjunction with the existing power-domains property to
establish parent-child relationships between a multi-domain power domain
provider and external parent domains.
Each element in the uint32 array identifies the child domain
ID (index) within the provider that should be made a child domain of
the corresponding phandle entry in power-domains. The two arrays must
have the same number of elements.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index b1147dbf2e73..163b0af158fd 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -68,6 +68,21 @@ properties:
by the given provider should be subdomains of the domain specified
by this binding.
+ power-domains-child-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ An array of child domain IDs that correspond to the power-domains
+ property. This property is only applicable to power domain providers
+ with "#power-domain-cells" > 0 (i.e., providers that supply multiple
+ power domains). It specifies which of the provider's child domains
+ should be associated with each parent domain listed in the power-domains
+ property. The number of elements in this array must match the number of
+ phandles in the power-domains property. Each element specifies the child
+ domain ID (index) that should be made a child domain of the corresponding
+ parent domain. This enables hierarchical power domain structures where
+ different child domains from the same provider can have different
+ parent domains.
+
required:
- "#power-domain-cells"
@@ -133,3 +148,22 @@ examples:
min-residency-us = <7000>;
};
};
+
+ - |
+ // Example: SCMI domain 15 -> MAIN_PD, SCMI domain 19 -> WKUP_PD
+ MAIN_PD: power-controller-main {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <0>;
+ };
+
+ WKUP_PD: power-controller-wkup {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <0>;
+ };
+
+ scmi_pds: power-controller-scmi {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <1>;
+ power-domains = <&MAIN_PD>, <&WKUP_PD>;
+ power-domains-child-ids = <15>, <19>;
+ };
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Jason Gunthorpe @ 2026-04-10 23:25 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <adl0aEfBAKmBsMs6@Asurada-Nvidia>
On Fri, Apr 10, 2026 at 03:06:32PM -0700, Nicolin Chen wrote:
> On Thu, Apr 09, 2026 at 09:27:34PM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > index 846a278fa5469..0e48264ccd01b 100644
> > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> > > */
> > > arm_smmu_domain_inv(smmu_domain);
> > >
> > > - /*
> > > - * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> > > - * still be called/running at this point. We allow the ASID to be
> > > - * reused, and if there is a race then it just suffers harmless
> > > - * unnecessary invalidation.
> > > - */
> > > - xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> > > -
> >
> > I don't think this artifact has disappeared so the comment should
> > probably remain too. It has become slightly different because it is
> > now running under RCU protections so it will clear alot faster.
>
> By taking a closer look, I think either the arm_smmu_domain_inv call
> above or any concurrent arm_smmu_mm_arch_invalidate_secondary_tlbs
> call is a NOP now?
That sounds right, with all the changes there should be no cache
flushing on the free path since it is now always flushed on detach, so
the arm_smmu_domain_inv() should be deleted here too.
> We reworked the ASID lifecycle, which now ends when the last device
> detaches. So, ASID was free-ed in arm_smmu_iotlb_tag_free() that did
> a per-ASID flush also.
Yes, so the comment is:
Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs() op can
still be called/running at this point. Like the normal detach flow
the RCU protected ASID may still experiance harmless invalidation.
However unlike normal domains the SVA invalidation will continue
into free until the mmu_notifier_put().
> So, when freeing the SVA domain here, the domain should have an empty
> invalidation array and the HW cache is flushed as well, right?
Yes, but the parallel thread is still possible even in free which is
unusual compared to normal domains where it is illegal to call
map/unmap concurrently with free.
Jason
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
From: patchwork-bot+netdevbpf @ 2026-04-10 23:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev, xuegang.lu
In-Reply-To: <20260408-airoha-reg_fe_pse_buf_set-v1-1-0c4fa8f4d1d9@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 12:20:09 +0200 you wrote:
> airoha_fe_set routine is used to set specified bits to 1 in the selected
> register. In the FE_PSE_BUF_SET case this can due to a overestimation of
> the required buffers for I/O queues since we can miss to set some bits
> of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw
> routine instead.
>
> Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()")
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
https://git.kernel.org/netdev/net/c/02f729643959
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Nicolin Chen @ 2026-04-10 23:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410214115.GC2588311@nvidia.com>
On Fri, Apr 10, 2026 at 06:41:15PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2026 at 02:23:48PM -0700, Nicolin Chen wrote:
>
> > Reworking the SVA code, I found arm_smmu_update_s1_domain_cd_entry
> > is marked as __maybe_unused and not getting called anywhere(?). Do
> > you recall why we kept it?
>
> I intended to send the vBTM support that uses it, and now that this is
> done it can work properly without races. So lets hang on, I was
> meaning to look at that soon
OK. I assume its caller would hold arm_smmu_asid_mutex, because
it's calling arm_smmu_find_iotlb_tag() now.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS suspend skip
From: Bjorn Helgaas @ 2026-04-10 22:53 UTC (permalink / raw)
To: Hongxing Zhu
Cc: mani@kernel.org, Frank Li, jingoohan1@gmail.com,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <AS8PR04MB883374CBFD3C97CE54DFB4C48C5BA@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 02:38:35AM +0000, Hongxing Zhu wrote:
> ...
> One additional note regarding NVMe: ASPM (Active State Power Management) is
> disabled locally on i.MX platforms for NVMe devices. This decision was made
> after encountering a system hang issue similar to the one reported by Hans a
> few months ago in his patch listed below.
> https://lore.kernel.org/linux-nvme/20250502032051.920990-1-hans.zhang@cixtech.com/
Where is ASPM disabled for i.MX? I don't see anything in pci-imx6.c.
It doesn't sound architecturally clean to me to disable ASPM based on
whether an NVMe device is involved.
^ permalink raw reply
* [GIT PULL] Qualcomm clock updates for v7.1
From: Bjorn Andersson @ 2026-04-10 22:38 UTC (permalink / raw)
To: Stephen Boyd, linux-clk
Cc: linux-arm-msm, linux-arm-kernel, Taniya Das, Val Packett,
Krzysztof Kozlowski, Konrad Dybcio, John Crispin, Abel Vesa,
Kathiravan Thirumoorthy, Pengyu Luo, Dmitry Baryshkov,
Jagadeesh Kona, Prasanna Tolety, Vladimir Zapolskiy, White Lewis
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-for-7.1
for you to fetch changes up to a4f780cd5c7aa8c0d2d044ffd153f7a3a13ca81e:
clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC (2026-04-08 21:00:09 -0500)
----------------------------------------------------------------
Qualcomm clock updates for v7.1
Add global TCSR, RPMh, and display clock controller support for the
Eliza platform.
Add TCSR, the multiple global, and the RPMh clock controller support
for the Nord platform.
Add GPU clock controller support for SM8750.
Introduce video and GPU clock controller support for Glymur.
Add global clock controller for IPQ5210.
Introduce various smaller display-related fixes across Kaanapali, Milos,
SC8280XP, SM4450, SM8250, and SA8775P.
Add missing GDSCs and fix retention flags for PCIe and USB power domains
on SC8180X. Also enable runtime PM support to ensure performance votes
are propagated to CX.
Mark the USB QTB clock as always-on on Hamoa, in order to ensure the
SMMU can work even when USB controller device is sleeping.
Add IPQ6018 and IPQ8074 support to the IPQ CMN PLL driver.
Add MDSS resets for SC7180, SM6115, and SM6125, to allow display
subsystem driver to reset the hardware from the state left by the
bootloader.
Introduce various cleanups across drivers.
----------------------------------------------------------------
Abel Vesa (3):
clk: qcom: Add TCSR clock driver for Eliza
clk: qcom: gcc-eliza: Enable FORCE_MEM_CORE_ON for UFS AXI PHY clock
dt-bindings: clock: qcom: Add missing power-domains property
Bjorn Andersson (5):
Merge branch '20260311-eliza-clocks-v6-1-453c4cf657a2@oss.qualcomm.com' into clk-for-7.1
Merge branch '20260303034847.13870-2-val@packett.cool' into clk-for-7.1
Merge branch '20260318-ipq5210_boot_to_shell-v2-1-a87e27c37070@oss.qualcomm.com' into clk-for-7.1
Merge branch '20260319-clk-qcom-dispcc-eliza-v3-1-d1f2b19a6e6b@oss.qualcomm.com' into clk-for-7.1
Merge branch '20260120-topic-7180_dispcc_bcr-v1-1-0b1b442156c3@oss.qualcomm.com' into clk-for-7.1
Dmitry Baryshkov (1):
clk: qcom: dispcc-glymur: use RCG2 ops for DPTX1 AUX clock source
Jagadeesh Kona (1):
clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON
John Crispin (5):
clk: qcom: gcc-ipq6018: mark gcc_xo_clk_src as critical
dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
clk: qcom: ipq-cmn-pll: Add IPQ6018 SoC support
dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
clk: qcom: ipq-cmn-pll: Add IPQ8074 SoC support
Kathiravan Thirumoorthy (2):
dt-bindings: clock: add Qualcomm IPQ5210 GCC
clk: qcom: add Global Clock controller (GCC) driver for IPQ5210 SoC
Konrad Dybcio (9):
clk: qcom: dispcc-glymur: Fix DSI byte clock rate setting
clk: qcom: dispcc-kaanapali: Fix DSI byte clock rate setting
clk: qcom: dispcc-milos: Fix DSI byte clock rate setting
clk: qcom: dispcc-sm4450: Fix DSI byte clock rate setting
clk: qcom: dispcc[01]-sa8775p: Fix DSI byte clock rate setting
dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets
clk: qcom: dispcc-sc7180: Add missing MDSS resets
dt-bindings: clock: qcom: Add SM8750 GPU clocks
clk: qcom: Add a driver for SM8750 GPU clocks
Krzysztof Kozlowski (12):
dt-bindings: clock: qcom,glymur-dispcc: De-acronymize SoC name
clk: qcom: De-acronymize Glymur SoC name
clk: qcom: kaanapali: Cleanup redundant header includes
clk: qcom: glymur: Cleanup redundant header includes
clk: qcom: sm8750: Cleanup redundant header includes
clk: qcom: milos: Cleanup redundant header includes
clk: qcom: eliza: Cleanup redundant header includes
dt-bindings: clock: qcom,eliza-dispcc: Add Eliza SoC display CC
clk: qcom: dispcc-eliza: Add Eliza display clock controller support
clk: qcom: videocc-glymur: Constify qcom_cc_desc
clk: qcom: Constify qcom_cc_driver_data
clk: qcom: Constify list of critical CBCR registers
Pengyu Luo (2):
clk: qcom: videocc-sm8350: use depend on instead of select
clk: qcom: rcg2: expand frac table for mdss_pixel_clk_src
Prasanna Tolety (1):
clk: qcom: rpmh: Add support for Nord rpmh clocks
Taniya Das (16):
dt-bindings: clock: qcom: document the Glymur GPU Clock Controller
clk: qcom: Add support for GPUCC and GXCLK for Glymur
dt-bindings: clock: qcom: Add GCC video axi reset clock for Glymur
dt-bindings: clock: qcom: Add video clock controller on Glymur SoC
clk: qcom: gcc-glymur: Add video axi clock resets for glymur
clk: qcom: videocc-glymur: Add video clock controller driver for Glymur
dt-bindings: clock: qcom: document the Eliza Global Clock Controller
dt-bindings: clock: qcom: Document the Eliza TCSR Clock Controller
dt-bindings: clock: qcom-rpmhcc: Add RPMHCC for Eliza
clk: qcom: rpmh: Add support for Eliza rpmh clocks
clk: qcom: Add support for Global clock controller on Eliza
dt-bindings: clock: qcom: Document the Nord SoC TCSR Clock Controller
dt-bindings: clock: qcom-rpmhcc: Add support for Nord SoCs
dt-bindings: clock: qcom: Add Nord Global Clock Controller
clk: qcom: Add TCSR clock driver for Nord SoC
clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC
Val Packett (13):
dt-bindings: clock: qcom,sm6115-dispcc: Define MDSS resets
dt-bindings: clock: qcom,dispcc-sm6125: Define MDSS resets
clk: qcom: dispcc-sm6115: Add missing MDSS resets
clk: qcom: dispcc-sm6125: Add missing MDSS resets
dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs
clk: qcom: gcc-sc8180x: Add missing GDSCs
clk: qcom: gcc-sc8180x: Use retention for USB power domains
clk: qcom: gcc-sc8180x: Use retention for PCIe power domains
clk: qcom: gcc-sc8180x: Enable runtime PM support
clk: qcom: gcc-sc8180x: Refactor to use qcom_cc_driver_data
clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk
clk: qcom: dispcc-sm8250: Enable parents for pixel clocks
clk: qcom: camcc-sc8180x: Refactor to use qcom_cc_driver_data
Vladimir Zapolskiy (1):
clk: qcom: gdsc: Fix error path on registration of multiple pm subdomains
White Lewis (1):
clk: qcom: dispcc-sc8280xp: remove CLK_SET_RATE_PARENT from byte_div_clk_src dividers
.../bindings/clock/qcom,eliza-dispcc.yaml | 96 +
.../bindings/clock/qcom,glymur-dispcc.yaml | 4 +-
.../bindings/clock/qcom,ipq5210-gcc.yaml | 62 +
.../bindings/clock/qcom,ipq9574-cmn-pll.yaml | 2 +
.../bindings/clock/qcom,kaanapali-gxclkctl.yaml | 2 +
.../devicetree/bindings/clock/qcom,milos-gcc.yaml | 16 +-
.../devicetree/bindings/clock/qcom,nord-gcc.yaml | 58 +
.../devicetree/bindings/clock/qcom,nord-negcc.yaml | 60 +
.../devicetree/bindings/clock/qcom,nord-nwgcc.yaml | 55 +
.../devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 +
.../bindings/clock/qcom,sm8450-gpucc.yaml | 27 +-
.../bindings/clock/qcom,sm8450-videocc.yaml | 3 +
.../bindings/clock/qcom,sm8550-tcsr.yaml | 4 +
drivers/clk/qcom/Kconfig | 94 +-
drivers/clk/qcom/Makefile | 9 +
drivers/clk/qcom/apss-ipq5424.c | 2 +-
drivers/clk/qcom/cambistmclkcc-kaanapali.c | 6 +-
drivers/clk/qcom/cambistmclkcc-sm8750.c | 4 +-
drivers/clk/qcom/camcc-kaanapali.c | 6 +-
drivers/clk/qcom/camcc-milos.c | 4 +-
drivers/clk/qcom/camcc-qcs615.c | 2 +-
drivers/clk/qcom/camcc-sc8180x.c | 67 +-
drivers/clk/qcom/camcc-sm8450.c | 4 +-
drivers/clk/qcom/camcc-sm8550.c | 4 +-
drivers/clk/qcom/camcc-sm8650.c | 4 +-
drivers/clk/qcom/camcc-sm8750.c | 4 +-
drivers/clk/qcom/camcc-x1e80100.c | 4 +-
drivers/clk/qcom/clk-rcg2.c | 2 +
drivers/clk/qcom/clk-rpmh.c | 46 +
drivers/clk/qcom/common.h | 4 +-
drivers/clk/qcom/dispcc-eliza.c | 2121 +++++++++++++
drivers/clk/qcom/dispcc-glymur.c | 12 +-
drivers/clk/qcom/dispcc-kaanapali.c | 8 +-
drivers/clk/qcom/dispcc-milos.c | 9 +-
drivers/clk/qcom/dispcc-qcs615.c | 4 +-
drivers/clk/qcom/dispcc-sc7180.c | 8 +
drivers/clk/qcom/dispcc-sc8280xp.c | 4 -
drivers/clk/qcom/dispcc-sm4450.c | 1 -
drivers/clk/qcom/dispcc-sm6115.c | 7 +
drivers/clk/qcom/dispcc-sm6125.c | 7 +
drivers/clk/qcom/dispcc-sm8250.c | 6 +-
drivers/clk/qcom/dispcc0-sa8775p.c | 2 -
drivers/clk/qcom/dispcc1-sa8775p.c | 2 -
drivers/clk/qcom/gcc-eliza.c | 3105 ++++++++++++++++++++
drivers/clk/qcom/gcc-glymur.c | 8 +-
drivers/clk/qcom/gcc-ipq5210.c | 2661 +++++++++++++++++
drivers/clk/qcom/gcc-ipq6018.c | 2 +-
drivers/clk/qcom/gcc-kaanapali.c | 5 +-
drivers/clk/qcom/gcc-milos.c | 4 +-
drivers/clk/qcom/gcc-nord.c | 1902 ++++++++++++
drivers/clk/qcom/gcc-sc8180x.c | 126 +-
drivers/clk/qcom/gcc-x1e80100.c | 1 +
drivers/clk/qcom/gdsc.c | 12 +-
drivers/clk/qcom/gpucc-glymur.c | 618 ++++
drivers/clk/qcom/gpucc-kaanapali.c | 5 +-
drivers/clk/qcom/gpucc-milos.c | 4 +-
drivers/clk/qcom/gpucc-qcs615.c | 4 +-
drivers/clk/qcom/gpucc-sm8750.c | 473 +++
drivers/clk/qcom/gxclkctl-kaanapali.c | 3 +-
drivers/clk/qcom/ipq-cmn-pll.c | 16 +
drivers/clk/qcom/negcc-nord.c | 1987 +++++++++++++
drivers/clk/qcom/nwgcc-nord.c | 688 +++++
drivers/clk/qcom/segcc-nord.c | 1609 ++++++++++
drivers/clk/qcom/tcsrcc-eliza.c | 179 ++
drivers/clk/qcom/tcsrcc-glymur.c | 3 +-
drivers/clk/qcom/tcsrcc-kaanapali.c | 1 -
drivers/clk/qcom/tcsrcc-nord.c | 337 +++
drivers/clk/qcom/tcsrcc-sm8750.c | 2 +-
drivers/clk/qcom/videocc-glymur.c | 532 ++++
drivers/clk/qcom/videocc-kaanapali.c | 4 +-
drivers/clk/qcom/videocc-milos.c | 4 +-
drivers/clk/qcom/videocc-qcs615.c | 4 +-
drivers/clk/qcom/videocc-sm8450.c | 4 +-
drivers/clk/qcom/videocc-sm8550.c | 4 +-
drivers/clk/qcom/videocc-sm8750.c | 5 +-
include/dt-bindings/clock/qcom,dispcc-sc7180.h | 7 +-
include/dt-bindings/clock/qcom,dispcc-sm6125.h | 6 +-
include/dt-bindings/clock/qcom,eliza-dispcc.h | 118 +
include/dt-bindings/clock/qcom,eliza-gcc.h | 210 ++
include/dt-bindings/clock/qcom,eliza-tcsr.h | 17 +
include/dt-bindings/clock/qcom,gcc-sc8180x.h | 5 +
include/dt-bindings/clock/qcom,glymur-gcc.h | 1 +
include/dt-bindings/clock/qcom,glymur-gpucc.h | 51 +
include/dt-bindings/clock/qcom,glymur-videocc.h | 45 +
include/dt-bindings/clock/qcom,ipq5210-gcc.h | 126 +
include/dt-bindings/clock/qcom,ipq6018-cmn-pll.h | 15 +
include/dt-bindings/clock/qcom,ipq8074-cmn-pll.h | 15 +
include/dt-bindings/clock/qcom,nord-gcc.h | 147 +
include/dt-bindings/clock/qcom,nord-negcc.h | 124 +
include/dt-bindings/clock/qcom,nord-nwgcc.h | 69 +
include/dt-bindings/clock/qcom,nord-segcc.h | 98 +
include/dt-bindings/clock/qcom,nord-tcsrcc.h | 26 +
include/dt-bindings/clock/qcom,sm6115-dispcc.h | 7 +-
include/dt-bindings/clock/qcom,sm8750-gpucc.h | 50 +
include/dt-bindings/reset/qcom,ipq5210-gcc.h | 127 +
95 files changed, 18239 insertions(+), 185 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,eliza-dispcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,ipq5210-gcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml
create mode 100644 drivers/clk/qcom/dispcc-eliza.c
create mode 100644 drivers/clk/qcom/gcc-eliza.c
create mode 100644 drivers/clk/qcom/gcc-ipq5210.c
create mode 100644 drivers/clk/qcom/gcc-nord.c
create mode 100644 drivers/clk/qcom/gpucc-glymur.c
create mode 100644 drivers/clk/qcom/gpucc-sm8750.c
create mode 100644 drivers/clk/qcom/negcc-nord.c
create mode 100644 drivers/clk/qcom/nwgcc-nord.c
create mode 100644 drivers/clk/qcom/segcc-nord.c
create mode 100644 drivers/clk/qcom/tcsrcc-eliza.c
create mode 100644 drivers/clk/qcom/tcsrcc-nord.c
create mode 100644 drivers/clk/qcom/videocc-glymur.c
create mode 100644 include/dt-bindings/clock/qcom,eliza-dispcc.h
create mode 100644 include/dt-bindings/clock/qcom,eliza-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,eliza-tcsr.h
create mode 100644 include/dt-bindings/clock/qcom,glymur-gpucc.h
create mode 100644 include/dt-bindings/clock/qcom,glymur-videocc.h
create mode 100644 include/dt-bindings/clock/qcom,ipq5210-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,ipq6018-cmn-pll.h
create mode 100644 include/dt-bindings/clock/qcom,ipq8074-cmn-pll.h
create mode 100644 include/dt-bindings/clock/qcom,nord-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-negcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-nwgcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-segcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-tcsrcc.h
create mode 100644 include/dt-bindings/clock/qcom,sm8750-gpucc.h
create mode 100644 include/dt-bindings/reset/qcom,ipq5210-gcc.h
^ permalink raw reply
* Re: [PATCH v4 06/10] iommu/arm-smmu-v3: Introduce INV_TYPE_S2_VMID_VSMMU
From: Nicolin Chen @ 2026-04-10 22:32 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260409235913.GZ3357077@nvidia.com>
On Thu, Apr 09, 2026 at 08:59:13PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:52PM -0700, Nicolin Chen wrote:
> > @@ -3246,7 +3248,10 @@ int arm_smmu_find_iotlb_tag(struct iommu_domain *domain,
> > tag->type = INV_TYPE_S1_ASID;
> > break;
> > case ARM_SMMU_DOMAIN_S2:
> > - tag->type = INV_TYPE_S2_VMID;
> > + if (to_vsmmu(domain))
> > + tag->type = INV_TYPE_S2_VMID_VSMMU;
> > + else
> > + tag->type = INV_TYPE_S2_VMID;
> > break;
>
> This shouldn't search, the vmid always comes from the vsmmu struct.
>
> arm_smmu_alloc_iotlb_tag() fixes it after, but the call in
> arm_smmu_attach_prepare_invs() should also only be using the
> vsmmu->vmid so this is a bug.
>
> Just set tag->id here and return. Move the tag->smmu up so that is
> safe.
Yea, I am changing it to this:
case ARM_SMMU_DOMAIN_S2:
- if (to_vsmmu(domain))
+ if (to_vsmmu(domain)) {
+ /*
+ * The VMID for a VSMMU must be pre-allocated during
+ * arm_vsmmu_init(). Return that directly.
+ */
+ WARN_ON(to_vsmmu(domain)->vmid == 0);
tag->type = INV_TYPE_S2_VMID_VSMMU;
- else
- tag->type = INV_TYPE_S2_VMID;
+ tag->id = to_vsmmu(domain)->vmid;
+ tag->smmu = smmu;
+ return 0;
+ }
+ tag->type = INV_TYPE_S2_VMID;
> > @@ -3357,7 +3369,7 @@ arm_smmu_master_build_invs(struct arm_smmu_master *master, bool ats_enabled,
> > return NULL;
> >
> > /* All the nested S1 ASIDs have to be flushed when S2 parent changes */
> > - if (nesting) {
> > + if (tag->type == INV_TYPE_S2_VMID_VSMMU) {
> > if (!arm_smmu_master_build_inv(master,
> > INV_TYPE_S2_VMID_S1_CLEAR,
> > tag->id, IOMMU_NO_PASID, 0))
>
> I think this function should not mix nesting and type at the same
> time..
>
> If INV_TYPE_S2_VMID_VSMMU means the tag is used as a nesting child
> then that should also drive the atc decision:
>
> if (!arm_smmu_master_build_inv(
> master, nesting ? INV_TYPE_ATS_FULL : INV_TYPE_ATS,
> master->streams[i].id, ssid, 0))
I am dropping the nest_parent and changing the 'nesting' here:
- const bool nesting = smmu_domain->nest_parent;
+ const bool nesting = tag->type == INV_TYPE_S2_VMID_VSMMU;
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Kevin Hilman @ 2026-04-10 22:25 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <CAPDyKFrR2zyMFXTAkKs1XRgB-u5jSP256g730s=7SLuOZKsKVg@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
>> >>
>> >> Currently, PM domains can only support hierarchy for simple
>> >> providers (e.g. ones with #power-domain-cells = 0).
>> >>
>> >> Add support for oncell providers as well by adding a new property
>> >> `power-domains-child-ids` to describe the parent/child relationship.
>> >>
>> >> For example, an SCMI PM domain provider has multiple domains, each of
>> >> which might be a child of diffeent parent domains. In this example,
>> >> the parent domains are MAIN_PD and WKUP_PD:
>> >>
>> >> scmi_pds: protocol@11 {
>> >> reg = <0x11>;
>> >> #power-domain-cells = <1>;
>> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
>> >> power-domains-child-ids = <15>, <19>;
>> >> };
>> >>
>> >> With this example using the new property, SCMI PM domain 15 becomes a
>> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
>> >> WKUP_PD.
>> >>
>> >> To support this feature, add two new core functions
>> >>
>> >> - of_genpd_add_child_ids()
>> >> - of_genpd_remove_child_ids()
>> >>
>> >> which can be called by pmdomain providers to add/remove child domains
>> >> if they support the new property power-domains-child-ids.
>> >>
>> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
>> >
>> > Thanks for working on this! It certainly is a missing feature!
>>
>> You're welcome, thanks for the detailed review.
>>
>> >> ---
>> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> include/linux/pm_domain.h | 16 ++++++++++++++++
>> >> 2 files changed, 185 insertions(+)
>> >>
>> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
>> >> index 61c2277c9ce3..acb45dd540b7 100644
>> >> --- a/drivers/pmdomain/core.c
>> >> +++ b/drivers/pmdomain/core.c
>> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
>> >> return genpd;
>> >> }
>> >>
>> >> +/**
>> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
>> >> + * @np: Device node pointer associated with the PM domain provider.
>> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
>> >> + *
>> >> + * Parse the power-domains and power-domains-child-ids properties to establish
>> >> + * parent-child relationships for PM domains. The power-domains property lists
>> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
>> >> + * should be associated with each parent.
>> >> + *
>> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
>> >
>> > I think we should avoid returning specific error codes for specific
>> > errors, simply because it usually becomes messy.
>> >
>> > If I understand correctly the intent here is to allow the caller to
>> > check for -ENOENT and potentially avoid bailing out as it may not
>> > really be an error, right?
>>
>> Right, -ENOENT is not an error of parsing, it's to indicate that there
>> are no child-ids to be parsed.
>>
>> > Perhaps a better option is to return the number of children for whom
>> > we successfully assigned parents. Hence 0 or a positive value allows
>> > the caller to understand what happened. More importantly, a negative
>> > error code then really becomes an error for the caller to consider.
>>
>> I explored this a bit, but it gets messy quick. It means we have to
>> track cases where only some of the children were added as well as when
>> all children were added. Personally, I think this should be an "all or
>> nothing" thing. If all the children cannot be parsed/added, then none
>> of them should be added.
>>
>> This also allows the remove to not have to care about how many were
>> added, and just remove them all, with the additional benefit of not
>> having to track the state of how many children were successfully added.
>>
>
> I fully agree, it should be all or nothing. Failing with one
> child/parent should end up with an error code being returned.
>
> That said, it still seems to make perfect sense to return the number
> of children for whom we assigned parents for, no?
No, because what will the caller use that number for? If we are
assuming "all or nothing", what would we use it for (other than a debug print?)
It also makes it a bit confusing what a zero return value means. Does
that mean success? Or that zero children were added (which would be
fail.)
I prefer to keep it as is.
Kevin
^ permalink raw reply
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Nicolin Chen @ 2026-04-10 22:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410002734.GC3357077@nvidia.com>
On Thu, Apr 09, 2026 at 09:27:34PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > index 846a278fa5469..0e48264ccd01b 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> > */
> > arm_smmu_domain_inv(smmu_domain);
> >
> > - /*
> > - * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> > - * still be called/running at this point. We allow the ASID to be
> > - * reused, and if there is a race then it just suffers harmless
> > - * unnecessary invalidation.
> > - */
> > - xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> > -
>
> I don't think this artifact has disappeared so the comment should
> probably remain too. It has become slightly different because it is
> now running under RCU protections so it will clear alot faster.
By taking a closer look, I think either the arm_smmu_domain_inv call
above or any concurrent arm_smmu_mm_arch_invalidate_secondary_tlbs
call is a NOP now?
We reworked the ASID lifecycle, which now ends when the last device
detaches. So, ASID was free-ed in arm_smmu_iotlb_tag_free() that did
a per-ASID flush also.
So, when freeing the SVA domain here, the domain should have an empty
invalidation array and the HW cache is flushed as well, right?
Nicolin
^ permalink raw reply
* [PATCH net-next] net: airoha: Wait for TX to complete in airoha_dev_stop()
From: Lorenzo Bianconi @ 2026-04-10 22:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Wait for TX to complete in airoha_dev_stop routine before stopping the
TX DMA and run airoha_qdma_cleanup_tx_queue routine. Moreover,
start/stop TX/RX NAPIs in ndo_open()/ndo_stop() callbacks in order to be
sure the TX NAPIs have completed before stopping the TX DMA engine in
airoha_dev_stop routine.
Please note this patch on the commit 'b1c803d5c816 ("net: airoha: Rework
the code flow in airoha_remove() and in airoha_probe() error path")'
that is available only in net-next tree at the moment.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 44 +++++++++++++++++---------------
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 8e4b043af4bc..9e40c8f375c1 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1662,10 +1662,12 @@ static int airoha_dev_open(struct net_device *dev)
FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
FIELD_PREP(GDM_LONG_LEN_MASK, len));
- airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
- GLOBAL_CFG_TX_DMA_EN_MASK |
- GLOBAL_CFG_RX_DMA_EN_MASK);
- atomic_inc(&qdma->users);
+ if (!atomic_fetch_inc(&qdma->users)) {
+ airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
+ GLOBAL_CFG_TX_DMA_EN_MASK |
+ GLOBAL_CFG_RX_DMA_EN_MASK);
+ airoha_qdma_start_napi(qdma);
+ }
if (port->id == AIROHA_GDM2_IDX &&
airoha_ppe_is_enabled(qdma->eth, 1)) {
@@ -1684,18 +1686,26 @@ static int airoha_dev_stop(struct net_device *dev)
struct airoha_qdma *qdma = port->qdma;
int i, err;
- netif_tx_disable(dev);
err = airoha_set_vip_for_gdm_port(port, false);
if (err)
return err;
- for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
- netdev_tx_reset_subqueue(dev, i);
-
airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
+ netif_tx_disable(dev);
if (atomic_dec_and_test(&qdma->users)) {
+ u32 val;
+
+ /* Wait for TX to complete */
+ err = read_poll_timeout(airoha_qdma_rr, val,
+ !(val & GLOBAL_CFG_TX_DMA_BUSY_MASK),
+ USEC_PER_MSEC, 100 * USEC_PER_MSEC,
+ false, qdma, REG_QDMA_GLOBAL_CFG);
+ if (err)
+ return err;
+
+ airoha_qdma_stop_napi(qdma);
airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
@@ -1708,6 +1718,9 @@ static int airoha_dev_stop(struct net_device *dev)
}
}
+ for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
+ netdev_tx_reset_subqueue(dev, i);
+
return 0;
}
@@ -3048,9 +3061,6 @@ static int airoha_probe(struct platform_device *pdev)
if (err)
goto error_netdev_free;
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_start_napi(ð->qdma[i]);
-
for_each_child_of_node(pdev->dev.of_node, np) {
if (!of_device_is_compatible(np, "airoha,eth-mac"))
continue;
@@ -3061,20 +3071,17 @@ static int airoha_probe(struct platform_device *pdev)
err = airoha_alloc_gdm_port(eth, np);
if (err) {
of_node_put(np);
- goto error_napi_stop;
+ goto error_netdev_unregister;
}
}
err = airoha_register_gdm_devices(eth);
if (err)
- goto error_napi_stop;
+ goto error_netdev_unregister;
return 0;
-error_napi_stop:
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_stop_napi(ð->qdma[i]);
-
+error_netdev_unregister:
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
@@ -3098,9 +3105,6 @@ static void airoha_remove(struct platform_device *pdev)
struct airoha_eth *eth = platform_get_drvdata(pdev);
int i;
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_stop_napi(ð->qdma[i]);
-
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
---
base-commit: 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7
change-id: 20260410-airoha-fix-ndo_stop-ebbf3c724ae0
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 0/6] perf arm_spe: Dump IMPDEF events
From: Arnaldo Carvalho de Melo @ 2026-04-10 22:05 UTC (permalink / raw)
To: Namhyung Kim
Cc: James Clark, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, linux-arm-kernel,
linux-perf-users, linux-kernel, Leo Yan
In-Reply-To: <adkqSLNceF2OQuBo@google.com>
On Fri, Apr 10, 2026 at 09:50:16AM -0700, Namhyung Kim wrote:
> Hi James,
>
> On Tue, Apr 07, 2026 at 03:05:14PM +0100, James Clark wrote:
> > In the Arm SPE raw data dump, IMPDEF events aren't printed. Add the
> > ability to add names for some known events or print the raw event number
> > for unknown events.
> >
> > For example:
> >
> > $ perf report -D
> >
> > ... ARM SPE data: size 0xd000 bytes
> > 00000000: b0 18 c6 32 80 00 80 ff a0 PC 0xff80008032c618 el1 ns=1
> > 00000009: 64 e7 42 00 00 CONTEXT 0x42e7 el1
> > 0000000e: 00 00 00 00 00 PAD
> > 00000013: 49 00 LD GP-REG
> > 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS
> >
> > On N1 the event line becomes:
> >
> > 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS LATE-PREFETCH
> >
> > Or on other cores it becomes:
> >
> > 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS IMPDEF:12
> >
> > Signed-off-by: James Clark <james.clark@linaro.org>
> > ---
> > Changes in v2:
> > - Put MIDR in arm_spe_pkt (Leo)
> > - Use for_each_set_bit() (Leo)
> > - Use BIT_ULL() to fix 32bit builds (Ian)
> > - Don't call strtol() with NULL (Ian)
> > - Link to v1: https://lore.kernel.org/r/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org
>
> I'm getting this on 32-bit build.
>
> In file included from /linux/tools/include/linux/bitmap.h:8,
> from util/arm-spe-decoder/arm-spe-pkt-decoder.c:11:
> util/arm-spe-decoder/arm-spe-pkt-decoder.c: In function 'arm_spe_pkt_desc_event':
> util/arm-spe-decoder/arm-spe-pkt-decoder.c:377:37: error: passing argument 1 of 'find_first_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 377 | for_each_set_bit(i, &payload, 64) {
> /linux/tools/include/linux/bitops.h:55:38: note: in definition of macro 'for_each_set_bit'
> 55 | for ((bit) = find_first_bit((addr), (size)); \
> | ^~~~
> In file included from /linux/tools/include/linux/bitmap.h:9:
> /linux/tools/include/linux/find.h:118:51: note: expected 'const long unsigned int *' but argument is of type 'u64 *' {aka 'long long unsigned int *'}
> 118 | unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
> | ~~~~~~~~~~~~~~~~~~~~~^~~~
I saw this as well.
- Arnaldo
^ permalink raw reply
* [PATCH net] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-10 21:49 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in
airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to
TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 31 ++++++++++++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 9285a68f435f..963ab7b8d166 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1044,13 +1044,17 @@ static int airoha_qdma_init_tx(struct airoha_qdma *qdma)
static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
- int i;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int i, qid = q - &qdma->q_tx[0];
+ struct airoha_queue_entry *e;
+ u16 index;
spin_lock_bh(&q->lock);
for (i = 0; i < q->ndesc; i++) {
- struct airoha_queue_entry *e = &q->entry[i];
+ struct airoha_qdma_desc *desc = &q->desc[i];
+ e = &q->entry[i];
if (!e->dma_addr)
continue;
@@ -1060,8 +1064,29 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
e->dma_addr = 0;
e->skb = NULL;
list_add_tail(&e->list, &q->tx_list);
+
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+
q->queued--;
}
+
+ e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
+ list);
+ index = e - q->entry;
+ /* Set TX_DMA_IDX to TX_CPU_IDX to notify the hw the QDMA TX ring is
+ * empty.
+ */
+ airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
+ FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
+ airoha_qdma_rmw(qdma, REG_TX_DMA_IDX(qid), TX_RING_DMA_IDX_MASK,
+ FIELD_PREP(TX_RING_DMA_IDX_MASK, index));
+
spin_unlock_bh(&q->lock);
}
---
base-commit: 12ff2a4aee6c86746623d5aed24389dbf6dffded
change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ 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