* [PATCH V14 10/12] arm64: dts: imx8mq: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 10 +++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 ++++++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index d48f901487d4..e7d87ea81b69 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -369,6 +369,7 @@ mipi_dsi_out: endpoint {
&pcie0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie0>;
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio5 28 GPIO_ACTIVE_LOW>;
clocks = <&clk IMX8MQ_CLK_PCIE1_ROOT>,
<&pcie0_refclk>,
@@ -389,9 +390,14 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&gpio5 28 GPIO_ACTIVE_LOW>;
+};
+
&pcie1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie1>;
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio5 12 GPIO_ACTIVE_LOW>;
clocks = <&clk IMX8MQ_CLK_PCIE2_ROOT>,
<&pcie0_refclk>,
@@ -414,6 +420,10 @@ &pcie1_ep {
status = "disabled";
};
+&pcie1_port0 {
+ reset-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
+};
+
&pgc_gpu {
power-supply = <&sw1a_reg>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6a25e219832c..e60872aeeb49 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1768,6 +1768,17 @@ pcie0: pcie@33800000 {
assigned-clock-rates = <250000000>, <100000000>,
<10000000>;
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@33800000 {
@@ -1846,6 +1857,17 @@ pcie1: pcie@33c00000 {
assigned-clock-rates = <250000000>, <100000000>,
<10000000>;
status = "disabled";
+
+ pcie1_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie1_ep: pcie-ep@33c00000 {
--
2.37.1
^ permalink raw reply related
* [PATCH V14 09/12] arm64: dts: imx8mp: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 5 +++++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 +++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index 2feb5b18645c..a7f3acdc36d1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -770,6 +770,7 @@ &pcie_phy {
&pcie0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie0>;
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio2 7 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcie0>;
vpcie3v3aux-supply = <®_pcie0>;
@@ -783,6 +784,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
+};
+
&pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 90d7bb8f5619..5ce2825182fd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -2265,6 +2265,17 @@ pcie0: pcie: pcie@33800000 {
phys = <&pcie_phy>;
phy-names = "pcie-phy";
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie_ep: pcie-ep@33800000 {
--
2.37.1
^ permalink raw reply related
* [PATCH V14 08/12] arm64: dts: imx8mm: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 5 +++++
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 11 +++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index 8be44eaf4e1e..e03aba825c18 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -533,6 +533,7 @@ &pcie_phy {
&pcie0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie0>;
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&pcie0_refclk>,
<&clk IMX8MM_CLK_PCIE1_AUX>;
@@ -559,6 +560,10 @@ &pcie0_ep {
status = "disabled";
};
+&pcie0_port0 {
+ reset-gpios = <&gpio4 21 GPIO_ACTIVE_LOW>;
+};
+
&sai2 {
#sound-dai-cells = <0>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 4cc5ad01d0e2..5cf2998d396d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -1370,6 +1370,17 @@ pcie0: pcie@33800000 {
phys = <&pcie_phy>;
phy-names = "pcie-phy";
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@33800000 {
--
2.37.1
^ permalink raw reply related
* [PATCH V14 07/12] arm: dts: imx7d: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts | 5 +++++
arch/arm/boot/dts/nxp/imx/imx7d.dtsi | 11 +++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts b/arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts
index a370e868cafe..0046b276b8b9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts
@@ -456,10 +456,15 @@ display_out: endpoint {
};
&pcie {
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&extended_io 1 GPIO_ACTIVE_LOW>;
status = "okay";
};
+&pcie_port0 {
+ reset-gpios = <&extended_io 1 GPIO_ACTIVE_LOW>;
+};
+
®_1p0d {
vin-supply = <&sw2_reg>;
};
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d.dtsi
index d961c61a93af..3c5c1f2c1460 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7d.dtsi
@@ -155,6 +155,17 @@ pcie: pcie@33800000 {
reset-names = "pciephy", "apps", "turnoff";
fsl,imx7d-pcie-phy = <&pcie_phy>;
status = "disabled";
+
+ pcie_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
};
};
--
2.37.1
^ permalink raw reply related
* [PATCH V14 06/12] arm: dts: imx6sx: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 5 +++++
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 11 +++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
index 3e238d8118fa..338de4d144b2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
@@ -282,11 +282,16 @@ codec: wm8962@1a {
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie>;
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio2 0 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcie_gpio>;
status = "okay";
};
+&pcie_port0 {
+ reset-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+};
+
&lcdif1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
index aefae5a3a6be..5484c398aa37 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
@@ -1470,6 +1470,17 @@ pcie: pcie@8ffc000 {
power-domains = <&pd_disp>, <&pd_pci>;
power-domain-names = "pcie", "pcie_phy";
status = "disabled";
+
+ pcie_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
};
};
--
2.37.1
^ permalink raw reply related
* [PATCH V14 05/12] arm: dts: imx6qdl: Add Root Port node and PERST property
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 17 ++++-------------
arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 5 +++++
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 11 +++++++++++
arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts | 5 +++++
4 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
index c78f101c3cc1..2ddd71f09da3 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
@@ -323,19 +323,10 @@ &ipu1_di0_disp0 {
remote-endpoint = <¶llel_display_in>;
};
-&pcie {
- pcie@0,0 {
- reg = <0x000000 0 0 0 0>;
- device_type = "pci";
- #address-cells = <3>;
- #size-cells = <2>;
- bus-range = <0x00 0xff>;
- ranges;
-
- /* non-removable i211 ethernet card */
- eth1: ethernet@0,0 {
- reg = <0x010000 0 0 0 0>;
- };
+&pcie_port0 {
+ /* non-removable i211 ethernet card */
+ eth1: ethernet@0,0 {
+ reg = <0x010000 0 0 0 0>;
};
};
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
index ba29720e3f72..fe9046c03ddd 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
@@ -754,11 +754,16 @@ lvds0_out: endpoint {
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie>;
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_pcie>;
status = "okay";
};
+&pcie_port0 {
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+};
+
&pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi
index 4dc2c410cf61..9438862b9927 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi
@@ -302,6 +302,17 @@ pcie: pcie@1ffc000 {
<&clks IMX6QDL_CLK_PCIE_REF_125M>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
status = "disabled";
+
+ pcie_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
aips1: bus@2000000 { /* AIPS1 */
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts b/arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts
index c5b220aeaefd..6b12cab7175f 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts
@@ -45,10 +45,15 @@ MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
};
&pcie {
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&max7310_c 5 GPIO_ACTIVE_LOW>;
status = "okay";
};
+&pcie_port0 {
+ reset-gpios = <&max7310_c 5 GPIO_ACTIVE_LOW>;
+};
+
&sata {
status = "okay";
};
--
2.37.1
^ permalink raw reply related
* [PATCH V14 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
The current DT binding for pci-imx6 specifies the 'reset-gpios' property
in the host bridge node. However, the PERST# signal logically belongs to
individual Root Ports rather than the host bridge itself. This becomes
important when supporting PCIe KeyE connector and PCI power control
framework for pci-imx6 driver, which requires properties to be specified
in Root Port nodes.
Add support for parsing 'reset-gpios' from Root Port nodes and the PCIe
bridge nodes under the Root Port using the common helper
pci_host_common_parse_ports(), and update the reset GPIO handling to use
the parsed port list from bridge->ports. To maintain DT backwards
compatibility, fallback to the legacy method of parsing the host bridge
node if the reset property is not present in the Root Port nodes.
Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be in
input mode, using gpiod_direction_output() instead of
gpiod_set_value_cansleep() to ensure the reset GPIO is properly
configured as output before setting its value.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 83 ++++++++++++++++++++++-----
1 file changed, 70 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 735127ed1455..a2742620279a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -34,6 +34,7 @@
#include <linux/pm_runtime.h>
#include "../../pci.h"
+#include "../pci-host-common.h"
#include "pcie-designware.h"
#define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
@@ -152,7 +153,6 @@ struct imx_lut_data {
struct imx_pcie {
struct dw_pcie *pci;
- struct gpio_desc *reset_gpiod;
struct clk_bulk_data *clks;
int num_clks;
bool supports_clkreq;
@@ -1224,6 +1224,41 @@ static void imx_pcie_disable_device(struct pci_host_bridge *bridge,
imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev));
}
+static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie)
+{
+ struct device *dev = pcie->pci->dev;
+ struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
+ struct pci_host_port *port;
+ struct pci_host_perst *perst;
+ struct gpio_desc *reset;
+
+ reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
+ if (IS_ERR(reset))
+ return PTR_ERR(reset);
+
+ if (!reset)
+ return 0;
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ perst = devm_kzalloc(dev, sizeof(*perst), GFP_KERNEL);
+ if (!perst)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&port->perst);
+ perst->desc = reset;
+ INIT_LIST_HEAD(&perst->list);
+ list_add_tail(&perst->list, &port->perst);
+
+ INIT_LIST_HEAD(&port->list);
+ list_add_tail(&port->list, &bridge->ports);
+
+ return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
+ &bridge->ports);
+}
+
static void imx_pcie_vpcie_aux_disable(void *data)
{
struct regulator *vpcie_aux = data;
@@ -1233,14 +1268,26 @@ static void imx_pcie_vpcie_aux_disable(void *data)
static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool assert)
{
+ struct dw_pcie *pci = imx_pcie->pci;
+ struct pci_host_bridge *bridge = pci->pp.bridge;
+ struct pci_host_perst *perst;
+ struct pci_host_port *port;
+
+ if (!bridge || list_empty(&bridge->ports))
+ return;
+
if (assert) {
- gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
+ list_for_each_entry(port, &bridge->ports, list) {
+ list_for_each_entry(perst, &port->perst, list)
+ gpiod_direction_output(perst->desc, 1);
+ }
} else {
- if (imx_pcie->reset_gpiod) {
- msleep(PCIE_T_PVPERL_MS);
- gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
- msleep(PCIE_RESET_CONFIG_WAIT_MS);
+ mdelay(PCIE_T_PVPERL_MS);
+ list_for_each_entry(port, &bridge->ports, list) {
+ list_for_each_entry(perst, &port->perst, list)
+ gpiod_direction_output(perst->desc, 0);
}
+ mdelay(PCIE_RESET_CONFIG_WAIT_MS);
}
}
@@ -1249,8 +1296,25 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct device *dev = pci->dev;
struct imx_pcie *imx_pcie = to_imx_pcie(pci);
+ struct pci_host_bridge *bridge = pp->bridge;
int ret;
+ if (bridge && list_empty(&bridge->ports)) {
+ /* Parse Root Port nodes if present */
+ ret = pci_host_common_parse_ports(dev, bridge);
+ if (ret) {
+ if (ret != -ENODEV) {
+ dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
+ return ret;
+ }
+
+ /* Fallback to legacy binding for DT backwards compatibility */
+ ret = imx_pcie_parse_legacy_binding(imx_pcie);
+ if (ret)
+ return ret;
+ }
+ }
+
imx_pcie_assert_perst(imx_pcie, true);
/* Keep 3.3Vaux supply enabled for the entire PCIe controller lifecycle */
@@ -1704,13 +1768,6 @@ static int imx_pcie_probe(struct platform_device *pdev)
return PTR_ERR(imx_pcie->phy_base);
}
- /* Fetch GPIOs */
- imx_pcie->reset_gpiod = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(imx_pcie->reset_gpiod))
- return dev_err_probe(dev, PTR_ERR(imx_pcie->reset_gpiod),
- "unable to get reset gpio\n");
- gpiod_set_consumer_name(imx_pcie->reset_gpiod, "PCIe reset");
-
/* Fetch clocks */
imx_pcie->num_clks = devm_clk_bulk_get_all(dev, &imx_pcie->clks);
if (imx_pcie->num_clks < 0)
--
2.37.1
^ permalink raw reply related
* [PATCH V14 03/12] PCI: imx6: Assert PERST# before enabling regulators
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
The PCIe endpoint may start responding or driving signals as soon as
its supply is enabled, even before the reference clock is stable.
Asserting PERST# before enabling the regulator ensures that the
endpoint remains in reset throughout the entire power-up sequence,
until both power and refclk are known to be stable and link
initialization can safely begin.
Currently, the driver enables the vpcie3v3aux regulator in
imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(),
which may cause PCIe endpoint undefined behavior during early
power-up. However, there is no issue so far because PERST# is
requested as GPIOD_OUT_HIGH in imx_pcie_probe(), which guarantees
that PERST# is asserted before enabling the vpcie3v3aux regulator.
This is prepare for the upcoming changes that will parse the reset
property using the new Root Port binding, which will use GPIOD_ASIS
when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not
guaranteed, so explicit sequencing is required.
Fix the power sequencing by:
1. Moving vpcie3v3aux regulator enable from probe to
imx_pcie_host_init(), where it can be properly sequenced with PERST#.
2. Moving imx_pcie_assert_perst() before regulator and clock enable to
ensure correct ordering.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 49 +++++++++++++++++++++------
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index e35044cc5218..735127ed1455 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -168,6 +168,8 @@ struct imx_pcie {
u32 tx_swing_full;
u32 tx_swing_low;
struct regulator *vpcie;
+ struct regulator *vpcie_aux;
+ bool vpcie_aux_enabled;
struct regulator *vph;
void __iomem *phy_base;
@@ -1222,6 +1224,13 @@ static void imx_pcie_disable_device(struct pci_host_bridge *bridge,
imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev));
}
+static void imx_pcie_vpcie_aux_disable(void *data)
+{
+ struct regulator *vpcie_aux = data;
+
+ regulator_disable(vpcie_aux);
+}
+
static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool assert)
{
if (assert) {
@@ -1242,6 +1251,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
struct imx_pcie *imx_pcie = to_imx_pcie(pci);
int ret;
+ imx_pcie_assert_perst(imx_pcie, true);
+
+ /* Keep 3.3Vaux supply enabled for the entire PCIe controller lifecycle */
+ if (imx_pcie->vpcie_aux && !imx_pcie->vpcie_aux_enabled) {
+ ret = regulator_enable(imx_pcie->vpcie_aux);
+ if (ret) {
+ dev_err(dev, "failed to enable vpcie_aux regulator: %d\n",
+ ret);
+ return ret;
+ }
+ imx_pcie->vpcie_aux_enabled = true;
+
+ ret = devm_add_action_or_reset(dev, imx_pcie_vpcie_aux_disable,
+ imx_pcie->vpcie_aux);
+ if (ret)
+ return ret;
+ }
+
if (imx_pcie->vpcie) {
ret = regulator_enable(imx_pcie->vpcie);
if (ret) {
@@ -1251,25 +1278,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
}
}
+ ret = imx_pcie_clk_enable(imx_pcie);
+ if (ret) {
+ dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
+ goto err_reg_disable;
+ }
+
if (pp->bridge && imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT)) {
pp->bridge->enable_device = imx_pcie_enable_device;
pp->bridge->disable_device = imx_pcie_disable_device;
}
imx_pcie_assert_core_reset(imx_pcie);
- imx_pcie_assert_perst(imx_pcie, true);
if (imx_pcie->drvdata->init_phy)
imx_pcie->drvdata->init_phy(imx_pcie);
imx_pcie_configure_type(imx_pcie);
- ret = imx_pcie_clk_enable(imx_pcie);
- if (ret) {
- dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
- goto err_reg_disable;
- }
-
if (imx_pcie->phy) {
ret = phy_init(imx_pcie->phy);
if (ret) {
@@ -1782,9 +1808,12 @@ static int imx_pcie_probe(struct platform_device *pdev)
of_property_read_u32(node, "fsl,max-link-speed", &pci->max_link_speed);
imx_pcie->supports_clkreq = of_property_read_bool(node, "supports-clkreq");
- ret = devm_regulator_get_enable_optional(&pdev->dev, "vpcie3v3aux");
- if (ret < 0 && ret != -ENODEV)
- return dev_err_probe(dev, ret, "failed to enable Vaux supply\n");
+ imx_pcie->vpcie_aux = devm_regulator_get_optional(&pdev->dev, "vpcie3v3aux");
+ if (IS_ERR(imx_pcie->vpcie_aux)) {
+ if (PTR_ERR(imx_pcie->vpcie_aux) != -ENODEV)
+ return PTR_ERR(imx_pcie->vpcie_aux);
+ imx_pcie->vpcie_aux = NULL;
+ }
imx_pcie->vpcie = devm_regulator_get_optional(&pdev->dev, "vpcie");
if (IS_ERR(imx_pcie->vpcie)) {
--
2.37.1
^ permalink raw reply related
* [PATCH V14 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Introduce generic helper functions to parse Root Port device tree nodes
and extract common properties like reset GPIOs. This allows multiple
PCI host controller drivers to share the same parsing logic.
Define struct pci_host_port to hold common Root Port properties
(currently only list of PERST# GPIO descriptors) and add
pci_host_common_parse_ports() to parse Root Port nodes from device tree.
Also add the 'ports' list to struct pci_host_bridge for better maintain
parsed Root Port information.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/pci-host-common.c | 164 +++++++++++++++++++++++
drivers/pci/controller/pci-host-common.h | 28 ++++
drivers/pci/probe.c | 1 +
include/linux/pci.h | 1 +
4 files changed, 194 insertions(+)
diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
index d6258c1cffe5..77905c728d0d 100644
--- a/drivers/pci/controller/pci-host-common.c
+++ b/drivers/pci/controller/pci-host-common.c
@@ -9,6 +9,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/gpio/consumer.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
@@ -17,6 +18,169 @@
#include "pci-host-common.h"
+/**
+ * pci_host_common_delete_ports - Cleanup function for port list
+ * @data: Pointer to the port list head
+ */
+void pci_host_common_delete_ports(void *data)
+{
+ struct list_head *ports = data;
+ struct pci_host_perst *perst, *tmp_perst;
+ struct pci_host_port *port, *tmp_port;
+
+ list_for_each_entry_safe(port, tmp_port, ports, list) {
+ list_for_each_entry_safe(perst, tmp_perst, &port->perst, list)
+ list_del(&perst->list);
+ list_del(&port->list);
+ }
+}
+EXPORT_SYMBOL_GPL(pci_host_common_delete_ports);
+
+/**
+ * pci_host_common_parse_perst - Parse PERST# from all nodes in depth first manner
+ * @dev: Device pointer
+ * @port: PCI host port
+ * @np: Device tree node to start parsing from
+ *
+ * This function recursively parses PERST# GPIO from all PCIe bridge nodes
+ * starting from @np in a depth-first manner.
+ *
+ * Returns: 0 on success, negative error code on failure.
+ */
+static int pci_host_common_parse_perst(struct device *dev,
+ struct pci_host_port *port,
+ struct device_node *np)
+{
+ struct pci_host_perst *perst;
+ struct gpio_desc *reset;
+ int ret;
+
+ if (!of_property_present(np, "reset-gpios"))
+ goto parse_child_node;
+
+ reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(np), "reset",
+ GPIOD_ASIS, "PERST#");
+ if (IS_ERR(reset)) {
+ /*
+ * FIXME: GPIOLIB currently supports exclusive GPIO access only.
+ * Non exclusive access is broken. But shared PERST# requires
+ * non-exclusive access. So once GPIOLIB properly supports it,
+ * implement it here.
+ */
+ if (PTR_ERR(reset) == -EBUSY)
+ dev_err(dev, "Shared PERST# is not supported\n");
+
+ return PTR_ERR(reset);
+ }
+
+ perst = devm_kzalloc(dev, sizeof(*perst), GFP_KERNEL);
+ if (!perst)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&perst->list);
+ perst->desc = reset;
+ list_add_tail(&perst->list, &port->perst);
+
+parse_child_node:
+ for_each_available_child_of_node_scoped(np, child) {
+ ret = pci_host_common_parse_perst(dev, port, child);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * pci_host_common_parse_port - Parse a single Root Port node
+ * @dev: Device pointer
+ * @bridge: PCI host bridge
+ * @node: Device tree node of the Root Port
+ *
+ * This function parses Root Port properties from the device tree.
+ * Currently it only handles the PERST# GPIO (including PERST# GPIOs from
+ * all PCIe bridge nodes under this Root Port) which is optional.
+ *
+ * NOTE: This helper fetches resources (like PERST# GPIO) optionally.
+ * If a controller driver has a hard dependency on certain resources(PHY,
+ * clocks, regulators, etc.), those resources MUST be modeled correctly
+ * in the DT binding and validated in DTS. This helper cannot enforce such
+ * dependencies and the driver may fail to operate if required resources
+ * are missing.
+ *
+ * Returns: 0 on success, -ENODEV if PERST# found in RC node (legacy binding
+ * should be used), Other negative error codes on failure.
+ */
+static int pci_host_common_parse_port(struct device *dev,
+ struct pci_host_bridge *bridge,
+ struct device_node *node)
+{
+ struct pci_host_port *port;
+ int ret;
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&port->perst);
+
+ ret = pci_host_common_parse_perst(dev, port, node);
+ if (ret)
+ return ret;
+
+ /*
+ * 1. PERST# found in RP or its child nodes - list is not empty, continue
+ * 2. PERST# not found in RP/children, but found in RC node - return -ENODEV
+ * to fallback legacy binding
+ * 3. PERST# not found anywhere - list is empty, continue (optional PERST#)
+ */
+ if (list_empty(&port->perst)) {
+ if (of_property_present(dev->of_node, "reset-gpios") ||
+ of_property_present(dev->of_node, "reset-gpio"))
+ return -ENODEV;
+ }
+
+ INIT_LIST_HEAD(&port->list);
+ list_add_tail(&port->list, &bridge->ports);
+
+ return 0;
+}
+
+/**
+ * pci_host_common_parse_ports - Parse Root Port nodes from device tree
+ * @dev: Device pointer
+ * @bridge: PCI host bridge
+ *
+ * This function iterates through child nodes of the host bridge and parses
+ * Root Port properties (currently only reset GPIOs).
+ *
+ * Returns: 0 on success, -ENODEV if no ports found or PERST# found in RC node
+ * (legacy binding should be used), Other negative error codes on failure.
+ */
+int pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge *bridge)
+{
+ int ret = -ENODEV;
+
+ for_each_available_child_of_node_scoped(dev->of_node, of_port) {
+ if (!of_node_is_type(of_port, "pci"))
+ continue;
+ ret = pci_host_common_parse_port(dev, bridge, of_port);
+ if (ret)
+ goto err_cleanup;
+ }
+
+ if (ret)
+ return ret;
+
+ return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
+ &bridge->ports);
+
+err_cleanup:
+ pci_host_common_delete_ports(&bridge->ports);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_host_common_parse_ports);
+
static void gen_pci_unmap_cfg(void *ptr)
{
pci_ecam_free((struct pci_config_window *)ptr);
diff --git a/drivers/pci/controller/pci-host-common.h b/drivers/pci/controller/pci-host-common.h
index b5075d4bd7eb..6b4e43e6ff22 100644
--- a/drivers/pci/controller/pci-host-common.h
+++ b/drivers/pci/controller/pci-host-common.h
@@ -12,6 +12,34 @@
struct pci_ecam_ops;
+/**
+ * struct pci_host_perst - PERST# GPIO descriptor
+ * @list: List node for linking multiple PERST# GPIOs
+ * @desc: GPIO descriptor for PERST# signal
+ *
+ * This structure holds a single PERST# GPIO descriptor.
+ */
+struct pci_host_perst {
+ struct list_head list;
+ struct gpio_desc *desc;
+};
+
+/**
+ * struct pci_host_port - Generic Root Port properties
+ * @list: List node for linking multiple ports
+ * @perst: List of PERST# GPIO descriptors for this port and its children
+ *
+ * This structure contains common properties that can be parsed from
+ * Root Port device tree nodes.
+ */
+struct pci_host_port {
+ struct list_head list;
+ struct list_head perst;
+};
+
+void pci_host_common_delete_ports(void *data);
+int pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge *bridge);
+
int pci_host_common_probe(struct platform_device *pdev);
int pci_host_common_init(struct platform_device *pdev,
struct pci_host_bridge *bridge,
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b63cd0c310bc..6094b6c1fc90 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -660,6 +660,7 @@ static void pci_init_host_bridge(struct pci_host_bridge *bridge)
{
INIT_LIST_HEAD(&bridge->windows);
INIT_LIST_HEAD(&bridge->dma_ranges);
+ INIT_LIST_HEAD(&bridge->ports);
/*
* We assume we can manage these PCIe features. Some systems may
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..cb5f3e7e8e48 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -636,6 +636,7 @@ struct pci_host_bridge {
int domain_nr;
struct list_head windows; /* resource_entry */
struct list_head dma_ranges; /* dma ranges resource list */
+ struct list_head ports; /* Root Port list (pci_host_port) */
#ifdef CONFIG_PCI_IDE
u16 nr_ide_streams; /* Max streams possibly active in @ide_stream_ida */
struct ida ide_stream_ida;
--
2.37.1
^ permalink raw reply related
* [PATCH V14 01/12] dt-bindings: PCI: fsl,imx6q-pcie: Add reset GPIO in Root Port node
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Update fsl,imx6q-pcie.yaml to include the standard reset-gpios property
for the Root Port node.
The reset-gpios property is already defined in pci-bus-common.yaml for
PERST#, so use it instead of the local reset-gpio property. Keep the
existing reset-gpio property in the bridge node for backward
compatibility, but mark it as deprecated.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/pci/fsl,imx6q-pcie.yaml | 32 +++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 9d1349855b42..e8b8131f5f23 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -66,16 +66,34 @@ properties:
- const: dma
reset-gpio:
+ deprecated: true
description: Should specify the GPIO for controlling the PCI bus device
reset signal. It's not polarity aware and defaults to active-low reset
sequence (L=reset state, H=operation state) (optional required).
+ This property is deprecated, instead of referencing this property from the
+ host bridge node, use the reset-gpios property from the root port node.
reset-gpio-active-high:
+ deprecated: true
description: If present then the reset sequence using the GPIO
specified in the "reset-gpio" property is reversed (H=reset state,
L=operation state) (optional required).
+ This property is deprecated along with the reset-gpio property above, use
+ the reset-gpios property from the root port node.
type: boolean
+ pcie@0:
+ description:
+ Describe the i.MX6 PCIe Root Port.
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -236,6 +254,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pcie: pcie@1ffc000 {
@@ -262,5 +281,18 @@ examples:
<&clks IMX6QDL_CLK_LVDS1_GATE>,
<&clks IMX6QDL_CLK_PCIE_REF_125M>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
+
+ pcie_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ };
};
...
--
2.37.1
^ permalink raw reply related
* [PATCH V14 00/12] pci-imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
This patch set adds support for parsing the reset property in new Root Port
binding in pci-imx6 driver, similar to the implementation in the qcom pcie
driver[1].
Also introduce generic helper functions to parse Root Port device tree
nodes and extract common properties like reset GPIOs. This allows multiple
PCI host controller drivers to share the same parsing logic.
Define struct pci_host_port to hold common Root Port properties
(currently only reset GPIO descriptor) and add
pci_host_common_parse_ports() to parse Root Port nodes from device tree.
Also add the 'ports' list to struct pci_host_bridge for better maintain
parsed Root Port information.
The plan is to add the wake-gpio property to the root port in subsequent
patches. Also, the vpcie-supply property will be moved to the root port
node later based on the refactoring patch set for the PCI pwrctrl
framework[2].
The initial idea is to adopt the Manivannan’s recent PCIe M.2 KeyE
connector support patch set[3] and PCI power control framework patches[2],
and extend them to the pcie-imx6 driver. Since the new M.2/pwrctrl model is
implemented based on Root Ports and requires the pwrctrl driver to bind to
a Root Port device, we need to introduce a Root Port child node on i.MX
boards that provide an M.2 connector.
To follow a more standardized DT structure, it also makes sense to move
the reset-gpios and wake-gpios properties into the Root Port node. These
signals logically belong to the Root Port rather than the host bridge,
and placing them there aligns with the new M.2/pwrctrl model.
Regarding backward compatibility, as Frank suggested, I will not remove
the old reset-gpio property from existing DTS files to avoid function
break.
For new i.MX platforms — such as the upcoming i.MX952-evk will add
vpcie-supply, reset-gpios, and wake-gpios directly under the Root Port
node.
Therefore, driver updates are needed to support both the legacy
properties and the new standardized Root Port based layout.
[1] https://lore.kernel.org/linux-pci/20250702-perst-v5-0-920b3d1f6ee1@qti.qualcomm.com/
[2] https://lore.kernel.org/linux-pci/20260115-pci-pwrctrl-rework-v5-0-9d26da3ce903@oss.qualcomm.com/
[3] https://lore.kernel.org/linux-pci/20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com/
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
Changes in V14:
1. Add pci_host_common_parse_perst() helper to parse PERST# from all PCIe bridge
nodes starting from the Root Port node.
2. Corresponding changes in patch#2 and patch#4 for the parsing PERST# logic.
Changes in V13:
1. Use of_property_present() instead of of_property_read_bool() in patch#2 as
reviewed by sashiko.
2. Add reset Null check in imx_pcie_parse_legacy_binding() to avoid
unconditional deassert delays on boards without reset GPIO as reviewed by
sashiko.
3. Delete the pcie@0,0 port defined in imx6q-utilite-pro.dts and use the new
pcie_port0 label in imx6qdl.dtsi to avoid to defining the conflicting node as
reviewed by sashiko.
Changes in V12:
1. Improve the pci_host_common_parse_port() to correctly handle three scenarios:
PERST# found in Root Port node & PERST# not in Root Port but found in RC node
& PERST# not found in either node.
2. Add documentation noting for pci_host_common_parse_port().
3. Add err_cleanup handle path for pci_host_common_parse_ports() to clean up any
partially parsed Root Port resources.
4. Optimize imx_pcie_assert_perst() to avoid the linearly increasing deassertion
delay if controller has multiple Root Ports.
5. Use mdelay instead of msleep in imx_pcie_assert_perst() for noirq context
safety.
6. Remove early return in imx_pcie_parse_legacy_binding() when reset is NULL to
align with pci_host_common_parse_port(), allowing port creation even without
PERST# GPIO.
Changes in V11:
1. Call pci_host_common_parse_ports() API from pci-imx6 driver instead of dwc
common layer as Mani suggested.
2. Improve the commit message of patch#3 to avoid confusion as Mani suggested.
Changes in V10:
1. Use gpiod_direction_output() instead of gpiod_set_value_cansleep() to
ensure the reset GPIO is properly configured as output before setting
its value in patch#5 as now the reset GPIO is obtained with
GPIOD_ASIS flag.
Changes in V9:
1. Improve the error handling in pci_host_common_parse_ports() as Mani suggested.
2. Move the list_empty check and the comment to imx_pcie_host_init() to make it
clear that imx_pcie_parse_legacy_binding() is a fallback as Mani suggested.
3. Export pci_host_common_delete_ports() so that it can be called by
imx_pcie_parse_legacy_binding().
Changes in V8:
1. Add back the cleanup function pci_host_common_delete_ports() to properly
handles the ports list instead of simply using pci_free_resource_list().
2. Improve the patch#4 commit message.
3. Remove the irrelevant code change in patch#4.
Changes in V7:
1. Change to use GPIOD_ASIS when requesting perst gpio as Mani suggested.
using bridge->dev.
2. Add a seperate patch to move vpcie3v3aux regulator enable from probe to
imx_pcie_host_init() and move imx_pcie_assert_perst() before regulator and
clock enable for pci-imx6.
3. Add device pointer parameter for pci_host_common_parse_port() instead of
Changes in V6:
1. Drop the pre-allocate pci_host_bridge struct changes in dw_pcie_host_init()
and imx_pcie_probe().
2. Parse Root Port nodes in dw_pcie_host_init() as Frank and Mani suggested.
3. Move the imx_pcie_parse_legacy_binding() from imx_pcie_probe() to
imx_pcie_host_init(), so that dw_pcie_host_init() parse Root Port first, if
no Root Port nodes were parsed(indicated by empty ports list), then parse
legacy binding.
4. Add device pointer parameter for pci_host_common_parse_ports().
5. Add NULL pointer check for reset gpio in imx_pcie_parse_legacy_binding().
Changes in V5:
1. Add the Root Port list(pci_host_port) to struct pci_host_bridge for better
maintain parsed Root Port information.
2. Delete the pci_host_common_delete_ports() as now the Root Port list in
pci_host_bridge can be cleared by pci_release_host_bridge_dev().
3. Change the common API pci_host_common_parse_ports() pass down struct
pci_host_bridge *.
4. Modify dw_pcie_host_init() to allow drivers to pre-allocate pci_host_bridge
struct when needed.
5. Allocate bridge early in imx_pcie_probe() to parse Root Ports.
Changes in V4:
1. Add common helpers for parsing Root Port properties in pci-host-common.c in
patch#2.
2. Call common pci_host_common_parse_ports() and pci_host_common_delete_ports()
in pci-imx6 driver.
3. Use PCIE_T_PVPERL_MS and PCIE_RESET_CONFIG_WAIT_MS instead of magic number
100 in patch#3 as Manivannan suggested.
4. Use "PERST#" instead of "PCIe reset" for the reset gpio lable in patch#3.
Changes in V3:
1. Improve the patch#2 commit message as Frank suggested.
2. Add Reviewed-by tag for patch#1.
Changes in V2:
1. Improve the patch#1 commit message as Frank suggested.
2. Also mark the reset-gpio-active-high property as deprecated in
imx6q-pcie DT binding as Rob suggested.
3. The imx_pcie_delete_ports() has been moved up so that the
imx_pcie_parse_ports() can call this helper function in error handling.
4. Keep the old reset-gpio property in the host bridge node for the
existing dts files and add comments to avoid confusion.
---
Sherry Sun (12):
dt-bindings: PCI: fsl,imx6q-pcie: Add reset GPIO in Root Port node
PCI: host-generic: Add common helpers for parsing Root Port properties
PCI: imx6: Assert PERST# before enabling regulators
PCI: imx6: Add support for parsing the reset property in new Root Port
binding
arm: dts: imx6qdl: Add Root Port node and PERST property
arm: dts: imx6sx: Add Root Port node and PERST property
arm: dts: imx7d: Add Root Port node and PERST property
arm64: dts: imx8mm: Add Root Port node and PERST property
arm64: dts: imx8mp: Add Root Port node and PERST property
arm64: dts: imx8mq: Add Root Port node and PERST property
arm64: dts: imx8dxl/qm/qxp: Add Root Port node and PERST property
arm64: dts: imx95: Add Root Port node and PERST property
.../bindings/pci/fsl,imx6q-pcie.yaml | 32 ++++
.../boot/dts/nxp/imx/imx6q-utilite-pro.dts | 17 +-
.../arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 11 ++
.../arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 11 ++
arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx7d.dtsi | 11 ++
.../boot/dts/freescale/imx8-ss-hsio.dtsi | 11 ++
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 5 +
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 5 +
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 11 ++
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 5 +
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 ++
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 10 ++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 +++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 10 ++
.../boot/dts/freescale/imx8qm-ss-hsio.dtsi | 22 +++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 5 +
.../boot/dts/freescale/imx95-15x15-evk.dts | 5 +
.../boot/dts/freescale/imx95-19x19-evk.dts | 10 ++
arch/arm64/boot/dts/freescale/imx95.dtsi | 22 +++
drivers/pci/controller/dwc/pci-imx6.c | 132 +++++++++++---
drivers/pci/controller/pci-host-common.c | 164 ++++++++++++++++++
drivers/pci/controller/pci-host-common.h | 28 +++
drivers/pci/probe.c | 1 +
include/linux/pci.h | 1 +
28 files changed, 546 insertions(+), 36 deletions(-)
--
2.37.1
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu-v3: Limit queue allocation retry boundary to PAGE_SIZE
From: Leo Jiang @ 2026-04-22 9:28 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, Joerg Roedel, iommu, linux-arm-kernel, Leo Jiang
In-Reply-To: <tencent_DA99B62735469A0CD219E9FC73E234A47309@qq.com>
In arm_smmu_init_one_queue(), the driver attempts to allocate the largest
supported queue and retries by halving the size on failure. Currently,
the retry logic allows the allocation to fall below PAGE_SIZE if the
PAGE_SIZE attempt fails.
While dmam_alloc_coherent() can theoretically return allocations smaller
than a page in certain configurations, it is preferable to limit the
retry boundary to PAGE_SIZE for SMMUv3 queues to align with the
original design intent.
This patch ensures the retry loop terminates when qsz reaches PAGE_SIZE,
per the feedback from the maintainer.
Signed-off-by: Leo Jiang <leo.jiang1224@foxmail.com>
---
v2:
- Use real name "Leo Jiang".
- Remove code comments as suggested by Will.
- Limit the queue allocation retry boundary to PAGE_SIZE
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e8d7dbe495f0..4a0b15b1d4d2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4418,7 +4418,7 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
GFP_KERNEL);
- if (q->base || qsz < PAGE_SIZE)
+ if (q->base || qsz <= PAGE_SIZE)
break;
q->llq.max_n_shift--;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: arm-smmu: qcom:: Fix Hawi compatible placement
From: Krzysztof Kozlowski @ 2026-04-22 9:04 UTC (permalink / raw)
To: Mukesh Ojha, Will Deacon, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robin Murphy
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260422083329.885979-1-mukesh.ojha@oss.qualcomm.com>
On 22/04/2026 10:33, Mukesh Ojha wrote:
> qcom,hawi-smmu-500 was placed in the wrong enum block of GPU. Move it to
> the correct location alongside other Qualcomm SMMU-500 compatibles for
> CPU.
How could it pass dtbs_check?
>
> Fixes: 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC")
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 06fb5c8e7547..ba9ad1f5a8ff 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -37,6 +37,7 @@ properties:
> - enum:
> - qcom,eliza-smmu-500
> - qcom,glymur-smmu-500
> + - qcom,hawi-smmu-500
> - qcom,kaanapali-smmu-500
> - qcom,milos-smmu-500
> - qcom,qcm2290-smmu-500
> @@ -93,7 +94,6 @@ properties:
> items:
> - enum:
> - qcom,glymur-smmu-500
> - - qcom,hawi-smmu-500
No, why? That's for GPU. Why are you moving GPU compatible to non-GPU place?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Leo Jiang @ 2026-04-22 9:13 UTC (permalink / raw)
To: Will Deacon, Robin Murphy; +Cc: joro, iommu, linux-arm-kernel
In-Reply-To: <aeeoEHHNKPo32H9R@willie-the-truck>
On Tue, Apr 21, 2026 at 05:38:40PM +0100, Will Deacon wrote:
> On Tue, Apr 21, 2026 at 04:56:47PM +0100, Robin Murphy wrote:
> > On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> > > From: LoserJL <leo.jiang1224@foxmail.com>
> > >
> > > In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> > > dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> > > allocates at least PAGE_SIZE, retrying with a smaller size after
> > > a PAGE_SIZE failure is logically redundant.
> >
> > Says who? It's certainly not a guarantee offered by the DMA API itself, and
> > indeed some allocation paths can definitely still allocate less than a page
> > - e.g. anything which hits a per-device or global coherent pool.
> >
> > > Moreover, if a sub-page retry were to succeed due to concurrent memory
> > > release, the hardware would be configured with a smaller queue depth
> > > despite a full page being allocated. This leads to inefficient memory
> > > usage and unnecessary hardware performance limitation.
> > >
> > > Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> > > consistency and optimal hardware configuration.
> >
> > That's really not an argument - even if an allocator does happen to
> > over-allocate for the requested size, that is hardly the caller's concern;
> > and as far as "optimal" queue sizes go in this case, those very much depend
> > on the number of CPUs issuing commands and volume of expected stall/PRI
> > events - in many cases PAGE_SIZE would already be far too small to really
> > work well.
> >
> > Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
> > queue, there would be very little chance of the subsequent allocation(s) for
> > the stream table succeeding, so realistically the driver is probably going
> > to end up failing to probe in such circumstances anyway.
>
> That's all true, but tbf I think I just fscked up the comparison in
> d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") so
> I'm not against fixing that up even though the "rationale" given by
> Loser doesn't make a whole lot of sense.
Hi Will, Robin,
Thank you both for the detailed feedback.
Robin, you are absolutely correct. After a deeper look into the source code,
I see that allocations smaller than a page are indeed possible in certain
cases. My previous assumption about the DMA API's granularity was wrong,
and I appreciate the correction.
However, as Will noted that the current logic deviates from the original
intent, I have prepared a v2 to limit the queue allocation retry boundary
to PAGE_SIZE.
In v2, I have:
- Updated my identity to Leo Jiang.
- Removed the code comments as suggested.
I will send the v2 as a follow-up shortly.
Best regards,
Leo Jiang
^ permalink raw reply
* Re: New warning in linus/master
From: Christophe Leroy (CS GROUP) @ 2026-04-22 9:09 UTC (permalink / raw)
To: Thomas Weißschuh, Ricardo Ribalda
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422103218-1efdbb73-51fa-48c9-ae92-75306147d61f@linutronix.de>
Le 22/04/2026 à 10:45, Thomas Weißschuh a écrit :
> On Wed, Apr 22, 2026 at 04:06:45PM +0800, Ricardo Ribalda wrote:
>> On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
>> <thomas.weissschuh@linutronix.de> wrote:
>>>
>>> On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
>>>> On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
>>>> <thomas.weissschuh@linutronix.de> wrote:
>>>>> On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
>>>>>> Media-CI has found a couple of new warnings in the latest kernel
>>>>>> version for aarch64 and powerpc. They get fixed with this patch and
>>>>>> before moving I wanted to know if this was under your radar.
>>>>>
>>>>> Thanks for the report. I was not aware of these so far.
>>>>>
>>>>>> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
>>>>>> index 7dec05dd33b7..65914842fae0 100644
>>>>>> --- a/arch/arm64/kernel/vdso/Makefile
>>>>>> +++ b/arch/arm64/kernel/vdso/Makefile
>>>>>> @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
>>>>>> CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
>>>>>>
>>>>>> ifneq ($(c-gettimeofday-y),)
>>>>>> - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>>>>>> + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>>>>>> -Wno-maybe-uninitialized
>>>>>> endif
>>>>>
>>>>> (...)
>>>>>
>>>>> I'd like to know exactly what is going on before suppressing the warning.
>>>>> It is a non-standard warning, only enabled by *some* of the vDSO builds
>>>>> for some reason.
>>>>>
>>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fusers%2Fribalda%2F-%2Fpipelines%2F1649144%2Ftest_report%3Fjob_name%3Dcross-gcc&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7cbf9009269d4ddc16d208dea04b86f1%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124443421115079%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O4r8HjaUn7KEgW8tDE9GEC9e8CWyJBpCfhVTJZZ%2BFHs%3D&reserved=0
>>>>>
>>>>> While I was able to download a configuration from this job and also use the
>>>>> same container image, I can not reproduce the issue. Is the configuration the
>>>>> full one or only the template?
>>>>>
>>>>> Could you provide full reproduction steps?
>>>>
>>>> You can try repro with:
>>>>
>>>> work/linux $ podman run -v .:/workdir/ --rm -it
>>>> registry.freedesktop.org/linux-media/media-ci/build:latest
>>>> $ cd /workdir
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>>>> arch/arm64/kernel/vdso/vgettimeofday.o
>>>>
>>>> The gcc version discrepancy is because I the error was due to old gcc
>>>> version and I was playing around with that... but it fails in both
>>>> gcc14 and gcc15
>>>
>>> Ack.
>>>
>>>> You can try with debian testing with
>>>> work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
>>>> $ apt-get update
>>>> $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
>>>> $ cd /workdir
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>>>> arch/arm64/kernel/vdso/vgettimeofday.o
>>>
>>> Both reproducers do *not* reproduce the issue for me.
>>> (It is more or less exactly what I tried before)
>>
>>
>> Ok, I think I found what is going on. media-ci was forcing
>> KCFLAGS=-Wmaybe-uninitialized
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fmedia-ci%2F-%2Fblob%2Fmain%2Ftest-build.sh%3Fref_type%3Dheads%23L29&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7cbf9009269d4ddc16d208dea04b86f1%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124443421146576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FpTHYfCn5ob42%2Fm6FVOZ32PVzuXBNBT3rlMVWslCfhw%3D&reserved=0
>>
>> And something has changed in the kernel in the last version that
>> triggers a (hopefully) false positive.
>>
>> can you try with:
>>
>> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>> KCFLAGS=-Wmaybe-uninitialized allyesconfig
>> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>> KCFLAGS=-Wmaybe-uninitialized prepare
>
> That works!
>
> The warning was introduced in ed78b7b2c5ae ("vdso/gettimeofday: Add a helper to
> read the sequence lock of a time namespace aware clock").
>
> It is *not* a false-positive, specifically:
>
> do {
> if (vdso_read_begin_timens(vc, &seq)) {
> vd = __arch_get_vdso_u_timens_data(vd);
> vc = &vd->aux_clock_data[idx];
> /* Re-read from the real time data page */
> continue;
>
> This 'continue' jumps to the end of the loop body and if the real vDSO datapage
> by chance has a sequence counter of '1' will exit the loop, leaving 'sec' and
> 'nsec' uninitialized. My believe was that the 'continue' would jump to the
> *beginning* of the loop body, which is cleary wrong. Previously there was an
> inner while loop() which would make the 'continue' effectively start at the
> beginning of the outer do-while loop.
Well spotted. I missed it too while reviewing.
A 'retry:' label at the begining of the loop with a 'goto retry' instead
of the 'continue' should make it.
Christophe
>
> }
>
> /* Auxclock disabled? */
> if (vc->clock_mode == VDSO_CLOCKMODE_NONE)
> return false;
>
> if (!vdso_get_timestamp(vd, vc, VDSO_BASE_AUX, &sec, &ns))
> return false;
>
> } while (vdso_read_retry(vc, seq));
>
> vdso_set_timespec(ts, sec, ns);
>
>
> I'm working on a fix.
>
>
> Thomas
>
^ permalink raw reply
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Sami Mujawar @ 2026-04-22 8:57 UTC (permalink / raw)
To: Jason Gunthorpe, Suzuki Poulose
Cc: Dan Williams, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Catalin Marinas, will@kernel.org,
thuth@redhat.com, Steven Price, gshan@redhat.com, Yeoreum Yun,
cedric.xing@intel.com, Dan Williams, Dionna Glaze,
Aneesh Kumar K . V, Alexey Kardashevskiy,
linux-coco@lists.linux.dev
In-Reply-To: <20260414133525.GA2577880@ziepe.ca>
Hi Jason,
> On Tue, Apr 14, 2026 at 02:26:58PM +0100, Suzuki K Poulose wrote:
> > On 14/04/2026 13:29, Jason Gunthorpe wrote:
> > > On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
> > >
> > > > > Isn't this also sort of incomplete? Doesn't anything serious need
> > > > > signed measurements? Isnt't there alot more data that comes out of RMM
> > > > > than just a few measurement registers?
> > > > As mentioned above, this series adds the support for Runtime Extendible
> > > > Measurements (REM in CCA, RTMR on TDX). The RIM+Platform Attestation is
> > > > already provided via the TSM_REPORT
> > >
> > > Okay, but what actual use is this?
> > >
> >
> > Good point. This REMs are planned to be used for EFI_CC_MEASUREMENT_PROTOCOL
> > as described below:
> >
> > https://github.com/tianocore/edk2/issues/11383
>
> So this is tying it to the same FW event log that TPM uses.
>
> I think that strengthens my point this should all be uninform. TPM
> drivers are directly exposing the event log today, but I guess that
> needs generalization if non-TPM drivers are going to present it as
> well.
>
> How do you imagine getting and manipulating the EFI event log to use
> with this?
The event logs from UEFI will be handed off to the OS using CCEL ACPI table. The CCEL table spec update can be seen at https://github.com/tianocore/edk2/issues/11384
Regards,
Sami Mujawar
> Jason
>
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 8:45 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCtfiPDiqzhjZGoCJbLC0fRoH1HLKrvYUt7jLDYEBQHqgg@mail.gmail.com>
On Wed, Apr 22, 2026 at 04:06:45PM +0800, Ricardo Ribalda wrote:
> On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> >
> > On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> > > On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> > > <thomas.weissschuh@linutronix.de> wrote:
> > > > On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > > > > Media-CI has found a couple of new warnings in the latest kernel
> > > > > version for aarch64 and powerpc. They get fixed with this patch and
> > > > > before moving I wanted to know if this was under your radar.
> > > >
> > > > Thanks for the report. I was not aware of these so far.
> > > >
> > > > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > > > index 7dec05dd33b7..65914842fae0 100644
> > > > > --- a/arch/arm64/kernel/vdso/Makefile
> > > > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > > > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > > > > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> > > > >
> > > > > ifneq ($(c-gettimeofday-y),)
> > > > > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > > -Wno-maybe-uninitialized
> > > > > endif
> > > >
> > > > (...)
> > > >
> > > > I'd like to know exactly what is going on before suppressing the warning.
> > > > It is a non-standard warning, only enabled by *some* of the vDSO builds
> > > > for some reason.
> > > >
> > > > > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
> > > >
> > > > While I was able to download a configuration from this job and also use the
> > > > same container image, I can not reproduce the issue. Is the configuration the
> > > > full one or only the template?
> > > >
> > > > Could you provide full reproduction steps?
> > >
> > > You can try repro with:
> > >
> > > work/linux $ podman run -v .:/workdir/ --rm -it
> > > registry.freedesktop.org/linux-media/media-ci/build:latest
> > > $ cd /workdir
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > > arch/arm64/kernel/vdso/vgettimeofday.o
> > >
> > > The gcc version discrepancy is because I the error was due to old gcc
> > > version and I was playing around with that... but it fails in both
> > > gcc14 and gcc15
> >
> > Ack.
> >
> > > You can try with debian testing with
> > > work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
> > > $ apt-get update
> > > $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
> > > $ cd /workdir
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > > arch/arm64/kernel/vdso/vgettimeofday.o
> >
> > Both reproducers do *not* reproduce the issue for me.
> > (It is more or less exactly what I tried before)
>
>
> Ok, I think I found what is going on. media-ci was forcing
> KCFLAGS=-Wmaybe-uninitialized
>
> https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-build.sh?ref_type=heads#L29
>
> And something has changed in the kernel in the last version that
> triggers a (hopefully) false positive.
>
> can you try with:
>
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> KCFLAGS=-Wmaybe-uninitialized allyesconfig
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> KCFLAGS=-Wmaybe-uninitialized prepare
That works!
The warning was introduced in ed78b7b2c5ae ("vdso/gettimeofday: Add a helper to
read the sequence lock of a time namespace aware clock").
It is *not* a false-positive, specifically:
do {
if (vdso_read_begin_timens(vc, &seq)) {
vd = __arch_get_vdso_u_timens_data(vd);
vc = &vd->aux_clock_data[idx];
/* Re-read from the real time data page */
continue;
This 'continue' jumps to the end of the loop body and if the real vDSO datapage
by chance has a sequence counter of '1' will exit the loop, leaving 'sec' and
'nsec' uninitialized. My believe was that the 'continue' would jump to the
*beginning* of the loop body, which is cleary wrong. Previously there was an
inner while loop() which would make the 'continue' effectively start at the
beginning of the outer do-while loop.
}
/* Auxclock disabled? */
if (vc->clock_mode == VDSO_CLOCKMODE_NONE)
return false;
if (!vdso_get_timestamp(vd, vc, VDSO_BASE_AUX, &sec, &ns))
return false;
} while (vdso_read_retry(vc, seq));
vdso_set_timespec(ts, sec, ns);
I'm working on a fix.
Thomas
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Jakub Raczynski @ 2026-04-22 8:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <7eb9e4d4-909c-4203-833d-bd8b664fdfbc@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
On Tue, Apr 21, 2026 at 02:39:15PM +0200, Andrew Lunn wrote:
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -78,7 +78,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
> > STMMAC_STAT(rx_vlan),
> > STMMAC_STAT(rx_split_hdr_pkt_n),
> > /* Tx/Rx IRQ error info */
> > - STMMAC_STAT(tx_undeflow_irq),
> > + STMMAC_STAT(tx_underflow_irq),
>
> Please take another look at this one and think about it.
>
> Andrew
>
> ---
> pw-bot: cr
>
I don't see anything wrong with it?
- naming is correct, same as stmmac_extra_stats from common.h, as it
wouldn't compile otherwise
- string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
not close
- ethtool just polls data from driver and in my tests it is ok
- all instances of 'undeflow' are changed
- 'underflow' semantic is ok, 'undeflow' is just not correct
Please correct me if I am wrong, but imo no issues with this patch.
Regards
Jakub Raczynski
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: i.MX8M Plus PCIe link regression
From: Thorsten Leemhuis @ 2026-04-22 8:39 UTC (permalink / raw)
To: Alexander Stein, Hongxing Zhu, Manivannan Sadhasivam
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, Linux kernel regressions list
In-Reply-To: <6102060.LvFx2qVVIh@steina-w>
Lo! What happened to this regression? It looks like it was never
resolved. Is that something everybody can live with in some way? Or
something we have to live with, as reverting the culprit at this point
would create a regression and thus creates even more trouble then it solves?
Ciao, Thorsten
On 3/4/26 09:47, Alexander Stein wrote:
>
> Am Mittwoch, 4. März 2026, 07:32:48 CET schrieb Manivannan Sadhasivam:
>> On Wed, Mar 04, 2026 at 02:55:51AM +0000, Hongxing Zhu wrote:
>>>> -----Original Message-----
>>>> From: Manivannan Sadhasivam <mani@kernel.org>
>>>> Sent: 2026年3月4日 0:42
>>>> To: Hongxing Zhu <hongxing.zhu@nxp.com>; Alexander Stein
>>>> <alexander.stein@ew.tq-group.com>
>>>> Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> imx@lists.linux.dev
>>>> Subject: Re: i.MX8M Plus PCIe link regression
>>>>
>>>> On Tue, Mar 03, 2026 at 01:38:13PM +0100, Alexander Stein wrote:
>>>>> Hi,
>>>>>
>>>>> these days I noticed that there is a PCIe link regression on my
>>>>> i.MX8MP platform (TQMa8MPxL) running next-20260227.
>>>>> I could bisect it back to commit 9c03e30e3ade3 ("PCI: imx6: Skip link
>>>>> up workaround for newer platforms"). I always get the following errors:
>>>>>
>>>>> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM:
>>>>> CFG_LINKWD_START imx6q-pcie 33800000.pcie: probe with driver
>>>>> imx6q-pcie failed with error -110
>>>>>
>>>>> Connected is a Gen1 PCIe -> Ethernet adapter. Interestingly a Gen2
>>>>> device is detected without issues.
>>>>>
>>>>> Reverting 3c96a61dd2e098dda8dcac3dce3d38a3c87afbfc and
>>>>> b9a8d28ebbf118bb3eac953f4a37abbd341257ab "fixes" my platform, both
>>>> Gen
>>>>> 1 and Gen 2 devices are detect. Commit
>>>>> 3c96a61dd2e098dda8dcac3dce3d38a3c87afbfc is only required for conflict
>>>> free revert.
>>>>>
>>>>> Here is a summary with outputs:
>>>>> Gen 1 device
>>>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>>>> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>>>>> RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev
>>>>>> 01)
>>>>>
>>>>> Gen 2 device
>>>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>>>> 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9128 PCIe
>>>>>> SATA 6 Gb/s RAID controller (rev 20)
>>>>>
>>>>> output of "dmesg | grep imx6q-pcie". Common part for all tests:
>>>>>> imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
>>>>>> imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff ->
>>>>>> 0x0000000000
>>>>>> imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff ->
>>>>>> 0x0018000000
>>>>>> imx6q-pcie 33800000.pcie: config reg[1] 0x1ff00000 == cpu 0x1ff00000
>>>>>> imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K,
>>>>>> limit 16G
>>>>>
>>>>> next-20260227
>>>>> Gen 1
>>>>>> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM:
>>>>>> CFG_LINKWD_START imx6q-pcie 33800000.pcie: probe with driver
>>>>>> imx6q-pcie failed with error -110
>>>>>
>>>>> Gen 2
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCI host bridge to bus 0000:00
>>>>>
>>>>> next-20260227 + reverts
>>>>> Gen 1
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie 33800000.pcie: PCI
>>>>>> host bridge to bus 0000:00
>>>>>
>>>>> Gen 2
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCIe Gen.2 x1 link up imx6q-pcie 33800000.pcie: PCI
>>>>>> host bridge to bus 0000:00
>>>>>
>>>>> What can we do here? I'm wondering why Gen 2 trains correctly, while
>>>>> Gen 1 doesn't.
>>>>>
>>>>
>>>> Thanks for the report and sorry for the breakage. Commit 9c03e30e3ade3,
>>>> mentions that the workaround is only needed for the i.MX6 platforms. So
>>>> I'm not sure why the patch breaks i.MX8M and that too only for Gen 1
>>>> speed.
>>>>
>>>> Also, before 9c03e30e3ade3, LTSSM was always started in Gen 1, but as per
>>>> your finding, only Gen 1 devices fail to work. So the code till
>>>> imx_pcie_wait_for_speed_change() shouldn't have an impact. Maybe the
>>>> issue is due to skipping imx_pcie_wait_for_speed_change()?
>>>>
>>>> Richard, thoughts?
>>> Hi Maini:
>>> Prior to calling imx_pcie_wait_for_speed_change(), the PCIe link must
>>> already be established. Before commit 9c03e30e3ade3, the speed change
>>> procedure was only initiated after the initial Gen1 link was successfully
>>> brought up.
>>>
>>> Hi Alexander:
>>> Sorry for the breakage.
>>> Before commit 9c03e30e3ade3, i.MX8MP PCIe forced Gen1 link training
>>> initially, then switched to Gen3 after link-up by triggering a speed
>>> change. After commit 9c03e30e3ade3, link training starts directly at
>>> the Gen3 capability level.
>>>
>>> The two link training methods differ only in the i.MX8MP Root Complex (RC)
>>> link capability configuration prior to link training: one method forces
>>> Gen1 speed, while the other retains the default Gen3 setting in your tests.
>>>
>>
>> I still don't understand why the link fails to train at Gen 1.
>
> Independently from the configured maximum link speed, shouldn't the initial
> link be Gen1 anyway and upgraded to Gen 2 later on?
>
> I added some debug output to dw_pcie_link_up()
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 3
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f704
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f722
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM: CFG_LINKWD_START
> imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
>
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 2
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM: CFG_LINKWD_START
> imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
>
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 1
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08000010
> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up
> imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
>
> So for any maximum speed above Gen1 it seems that LTSSM is stuck at link
> training.
> Unfortunately only link training and link up bits are defined and RM doesn't
> show anything, so I don't know what the other bits are indicating.
>
> For a Gen2 device the link training succeeds right away.
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 2
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08000010
> imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up
> imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
>
> Best regards,
> Alexander
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: qcom:: Fix Hawi compatible placement
From: Mukesh Ojha @ 2026-04-22 8:33 UTC (permalink / raw)
To: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, Mukesh Ojha
Cc: Robin Murphy, Krzysztof Kozlowski, linux-arm-kernel, iommu,
devicetree, linux-kernel
qcom,hawi-smmu-500 was placed in the wrong enum block of GPU. Move it to
the correct location alongside other Qualcomm SMMU-500 compatibles for
CPU.
Fixes: 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC")
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ba9ad1f5a8ff 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -37,6 +37,7 @@ properties:
- enum:
- qcom,eliza-smmu-500
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
@@ -93,7 +94,6 @@ properties:
items:
- enum:
- qcom,glymur-smmu-500
- - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-22 8:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeeMp1XBDxSZ1qrl@monoceros>
Hi Uwe,
On 16:50 Tue 21 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> On Mon, Apr 20, 2026 at 06:27:45PM +0200, Andrea della Porta wrote:
> > On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> > > What happens if sync is asserted while a disabled channel didn't
> > > complete the last period yet?
> >
> > The output stops immediately without waiting for the current period to finish.
>
> This is a good info for the Limitations block.
Yup, already added, plus a couple other edge cases.
>
> > > Maybe it's worth to test the following procedure for updating duty and
> > > period:
> > >
> > > disable channel
> > > configure duty
> > > configure period
> > > enable
> > > set update flag
> > >
> > > Assumint disable is delayed until the end of the currently running
> > > period, the effect of this procedure might be that no glitch happens if
> > > the update flag is asserted before the currently running period ends and
> > > the anormality is reduced to a longer inactive state if the updates are
> > > not that lucky (in contrast to more severe glitches).
> >
> > The disable isn't delayed as explained above. Setting just the new period/duty
> > (which do not depend on the sync bit) correctly waits for the end of the current
> > period without noticeable glitches (tested with a scope).
>
> So if you happen to change both and one is done before the end of the
> current period and the other shortly afterwards (which might happen as
> those are configured in two different registers and the update trigger
> isn't used), you get a mixed output for one cycle, right? If yes, please
> also mention that in the Limitations paragraph.
Confirmed, tested with the scope and a very long period time.
>
> > > > Let's say that teh user want 10 tick period, we have to use
> > > > 9 instead to account for the extra tick at the end, so that the complete period
> > > > contains that extra tick?
> > >
> > > I would describe that a bit differently, but in general: yes.
> > >
> > > The more straight forward description is that setting
> > >
> > > RP1_PWM_RANGE(pwm->hwpwm) := x
> > >
> > > results in a period of x + 1 ticks.
> >
> > Exactly. So whatever the user request I have to subtract one from the value
> > to be written to the RANGE register.
>
> Unless the calculation is already rounded to 0, in that case don't
> subtract 1 and let the tohw callback return 1.
Sure.
>
> > > > This also means that if we ask for 100% duty cycle, the output waveform will
> > > > have the high part of the signal lasting one tick less than expected.a I guess
> > > > this is the accepted compromise.
> > >
> > > I assume you considered something like:
> > >
> > > RP1_PWM_RANGE(pwm->hwpwm) := 17
> > > RP1_PWM_DUTY(pwm->hwpwm) := 18
> > >
> > > to get a 100% relative duty?
> >
> > Ah right! It's working fine and I've got 100% duty. So at hw register level
> > the duty can be greater that the period.
>
> In that case please make sure to not use the maximal value for
> RP1_PWM_RANGE(pwm->hwpwm) to ensure that for each (possible) period
> length a 100% relative duty cycle can be configured.
Ack.
>
> > > My (not so well articulated) point is: Please be stringent about clock
> > > handling to not bank up technical dept more than necessary and such that
> > > the driver can be made unbindable if and when syscons grow
> > > that feature. Optionally wail at the syscon guys :-)
> >
> > Hmmm not sure I've understood your point: is it a requirement that the driver
> > must be unbindable? In this case I should avoid registering the syscon. Or
> > should I just provide a .remove callback in case there will be a way to
> > unregister the syscon (even if this callback will not be called as of now)?
>
> It's a requirement to properly manage the resources you allocate. If a
> driver isn't unbindable due to restrictions of other subsystems that's
> unfortunate and I don't like it, but I wouldn't block a patch because of
> that.
I totally agree, of course. From a practical perspective I take it as "even
if it's not ideal, you don't need to do further coding action on that side".
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Alexey Charkov @ 2026-04-22 8:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Brian Masney, Sebastian Reichel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Pavel Zhovner, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-clk, Cristian Ciocaltea
In-Reply-To: <20260421-quirky-tough-robin-817a1c@houat>
Hi Sebastian, Brian, Maxime,
Thanks a lot for your inputs!
On Tue, Apr 21, 2026 at 8:10 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi Brian, Alexey,
>
> On Mon, Apr 20, 2026 at 12:02:58PM -0400, Brian Masney wrote:
> > On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > > > Dear all,
> > > >
> > > > Need the help of the collective wisdom of the community.
> > > >
> > > > The problem I'm trying to solve is reliably obtaining the exact pixel
> > > > clock for arbitrary display modes supported by the RK3576 SoC.
> > > >
> > > > Rockchip RK3576 has three display output processors VP0~VP2, each
> > > > supporting different ranges of display modes, roughly as follows:
> > > > - VP0: 4K 120Hz
> > > > - VP1: 2.5k 60Hz
> > > > - VP2: 1080p 60Hz
>
> Do any of those have an additional multiplier or divider after the PLL?
>
> I'm asking because 4k@120Hz is 1188MHz, and 1080p@60Hz is 148.5 (so 1188
> / 8). 2.5k @ 60 might be a bit more problematic, but my point is that
> for HDMI/DP, most resolutions all have a pixel clock that are multiples
> of 148.5MHz.
>
> If you manage to get the PLL to the highest you need (1188MHz), and then
> apply dividers, you don't need to change the PLL frequency anymore.
Yes, each of them has an (integer-only) divider between the PLL and
the respective mux. The problem though is that displays' EDIDs want
modes that are all over the place and don't seem to converge to any
common numbers generally (it looks like display manufacturers haven't
heard of VESA modes these days).
Following Heiko's nudge from the other sub-thread (thanks for the
pointers Heiko!), I derived the fractional PLL parameters for the
modes which couldn't be obtained cleanly from existing PLL values. It
ended up being 35(!) different rates for just the 7 displays my
colleagues and I could get our hands on, majority of which only
representable with the fractional delta-sigma component. That's after
consolidating the clocks which can be driven from the same
higher-frequency PLL configuration with small integer dividers. Seeing
all of that I couldn't help but think, "Surely those should be
possible to consolidate further by allowing for some error margin!" -
but had to guess again. Even a deviation as small as 0.2% of the
effective clock from the requested rate causes blank screens in my
sample - sometimes less than that.
This further leads me to believe that Brian's rate negotiation series
won't save me here, as the chances of two different displays at two
different weird modes magically agreeing on a PLL rate that is a
common multiple of their respective pixel clocks seem infinitesimal.
And their modes will most likely differ, as VP outputs are asymmetric.
Unless of course everything is 1920x1080@60 with a standard 148.5 MHz
pixel clock or its integer multiple - then the problem doesn't exist,
as this particular mode works even in the current configuration on all
VPs.
> > > > Each one obviously needs a pixel clock. The required frequencies for the
> > > > pixel clocks vary greatly depending on the display mode, and need to be
> > > > matched within a tight tolerance, or else many displays will refuse to
> > > > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > > > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > > > be obtained using integer dividers from its default clock source (GPLL
> > > > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > > > outside the tolerance of e.g. DP specification, resulting in a blank
> > > > screen on most displays by default.
> > > >
> > > > The clock sources are of course configurable, in particular there are muxes
> > > > connected to each VP for selecting the source of the pixel clock:
> > > > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > > > its dedicated dclk_vpX_src mux
> > > > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > > > (GPLL, CPLL, VPLL, BPLL, LPLL)
> > > >
> > > > While the system PLLs can be configured to output a wide range of
> > > > frequencies, they are shared between many system components. E.g. on the
> > > > current mainline kernel on one of my RK3576 boards I've got the following:
> > > > GPLL: 1188 MHz, enable count 20
> > > > CPLL: 1000 MHz, enable count 17
> > > > VPLL: 594 MHz, enable count 0 (yaay!)
> > > > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > > > predividers, so are less flexible)
> > > >
> > > > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > > > used to generate arbitrary pixel clocks, but we have up to three consumers
> > > > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > > > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > > > frequency on the fly to satisfy the requirements of the selected display
> > > > mode.
> > > >
> > > > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > > > three consumers while changing the PLL frequency on the fly sounds like
> > > > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > > > HDMI output out of the equation, because it can be driven from the HDMI
> > > > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > > > makes the decision of which dclk source to use for a VP block dependent on
> > > > which downstream consumer is connected to it (HDMI vs. something else).
> > >
> > > It becomes more messy: The HDMI PHY cannot be used as clock source
> > > for modes exceeding 4K@60Hz.
Thanks for the pointer! I've checked, and indeed it automatically
switches to the PHY clock for anything below 600 MHz.
This is in fact a notable improvement, because then only a handful of
higher-rate modes out of my modest sample need a dedicated PLL for the
VP0+HDMI setup: specifically, 3840x2160@160 (1478740 kHz),
3840x2160@144 (1275830 kHz), 3840x2160@119.88 (1186813 kHz - this one
might work with 1188000 if CCF allows returning higher-than-requested
effective rates) and 2560x1440@165.08 (645000 kHz).
3840x2160@120 can be driven from the current GPLL, as it's exactly 1188 MHz.
The configuration / policy to enable that transparently for the user
seems non-trivial though:
- If the output is HDMI and the display clock is <=600 MHz, always
source it from HDMI PHY (easy)
- Otherwise, if the display clock is 1188 MHz or its integer quotient,
always source it from GPLL, and disallow parent rate changes
- Otherwise, reparent to any active PLL whose current rate is an
integer multiple of the required display clock, and disallow parent
rate changes
- Otherwise, see if VPLL is free. If it is, reparent to it and request
its rate change to the required display clock (or its integer
multiple)
- Otherwise, tell the user the mode set failed (and let them retry
with a different mode, or own the pieces)
I'd love to learn if the above (or anything close) is representable in
the kernel, although I suspect it's not:
- Allowing or disallowing parent rate changes depends on the selected
parent here, while in the current clock implementation it's an
attribute of the child
- All PLLs are equal, but one (VPLL) is more equal than the others by
the virtue of being free more often, and also having the required
delta-sigma component
- Reparenting to an already running PLL if its rate permits should be
preferred to monopolizing the VPLL
> > > > Even then we somehow need two devices to cooperate in picking a PLL
> > > > frequency that satisfies the requirements of both of them, and change to it
> > > > without display corruption. I'm not even sure if the CCF has mechanisms
> > > > for that?..
>
> It's not *just* the CCF though. You will disrupt the other, already
> active display, which might affect the user because the screen will
> blank, throw off the vblank timings and thus userspace, etc.
Indeed. Changing the rate of a PLL while it's in use sounds scary,
even if a solution for the rate exists and can be found in reasonable
time.
> Brian's solution is great progress on that front already, but if you can
> just save yourself the trouble, I'd advise you to do that instead :)
I'd love to, but it seems that displays won't let me :-D
It might be helpful to pre-filter the allowed display modes to only
offer those which can be derived from the currently available PLL
frequencies. The problem is that it makes an extremely limited subset
on real-world displays.
Best regards,
Alexey
^ permalink raw reply
* Re: New warning in linus/master
From: Ricardo Ribalda @ 2026-04-22 8:06 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422092713-4021a1a5-3a54-4260-878a-aec1bef3f8c7@linutronix.de>
Hi Thomas
On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> > On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> > <thomas.weissschuh@linutronix.de> wrote:
> > > On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > > > Media-CI has found a couple of new warnings in the latest kernel
> > > > version for aarch64 and powerpc. They get fixed with this patch and
> > > > before moving I wanted to know if this was under your radar.
> > >
> > > Thanks for the report. I was not aware of these so far.
> > >
> > > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > > index 7dec05dd33b7..65914842fae0 100644
> > > > --- a/arch/arm64/kernel/vdso/Makefile
> > > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > > > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> > > >
> > > > ifneq ($(c-gettimeofday-y),)
> > > > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > -Wno-maybe-uninitialized
> > > > endif
> > >
> > > (...)
> > >
> > > I'd like to know exactly what is going on before suppressing the warning.
> > > It is a non-standard warning, only enabled by *some* of the vDSO builds
> > > for some reason.
> > >
> > > > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
> > >
> > > While I was able to download a configuration from this job and also use the
> > > same container image, I can not reproduce the issue. Is the configuration the
> > > full one or only the template?
> > >
> > > Could you provide full reproduction steps?
> >
> > You can try repro with:
> >
> > work/linux $ podman run -v .:/workdir/ --rm -it
> > registry.freedesktop.org/linux-media/media-ci/build:latest
> > $ cd /workdir
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > arch/arm64/kernel/vdso/vgettimeofday.o
> >
> > The gcc version discrepancy is because I the error was due to old gcc
> > version and I was playing around with that... but it fails in both
> > gcc14 and gcc15
>
> Ack.
>
> > You can try with debian testing with
> > work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
> > $ apt-get update
> > $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
> > $ cd /workdir
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > arch/arm64/kernel/vdso/vgettimeofday.o
>
> Both reproducers do *not* reproduce the issue for me.
> (It is more or less exactly what I tried before)
Ok, I think I found what is going on. media-ci was forcing
KCFLAGS=-Wmaybe-uninitialized
https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-build.sh?ref_type=heads#L29
And something has changed in the kernel in the last version that
triggers a (hopefully) false positive.
can you try with:
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized allyesconfig
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized prepare
?
>
> Please note that this line does not work in general:
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make arch/arm64/kernel/vdso/vgettimeofday.o
>
> The vDSO object files can not be built in this way like regular kernel object
> files and will produce a compiler error, but not the one under discussion.
> Instead the vDSO on arm64 is built during the 'make prepare' phase.
> (Other architectures work differently, of course...)
>
> (...)
>
>
> Thomas
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: David Hildenbrand (Arm) @ 2026-04-22 7:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts, Mark Brown,
Dev Jain, linux-kernel, linux-mm, stable
In-Reply-To: <20260421-zerotags-v2-1-05cb1035482e@kernel.org>
> }
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 6c75df30a281..d79049291b1a 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -273,11 +273,11 @@ enum {
> *
> * %__GFP_ZERO returns a zeroed page on success.
> *
> - * %__GFP_ZEROTAGS zeroes memory tags at allocation time if the memory itself
> - * is being zeroed (either via __GFP_ZERO or via init_on_alloc, provided that
> - * __GFP_SKIP_ZERO is not set). This flag is intended for optimization: setting
> - * memory tags at the same time as zeroing memory has minimal additional
> - * performance impact.
> + * %__GFP_ZEROTAGS zeroes memory tags at allocation time. Setting memory tags at
> + * the same time as zeroing memory (e.g., with __GPF_ZERO) has minimal
As pointed out by AI review s/__GPF_ZERO/__GFP_ZERO/.
I assume this can be fixed up when applying.
--
Cheers,
David
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 7:32 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCviww1L1p2+MvF59Biqb6hc7WdL1J37kBjFd1NXz-Yt8A@mail.gmail.com>
On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> > On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > > Media-CI has found a couple of new warnings in the latest kernel
> > > version for aarch64 and powerpc. They get fixed with this patch and
> > > before moving I wanted to know if this was under your radar.
> >
> > Thanks for the report. I was not aware of these so far.
> >
> > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > index 7dec05dd33b7..65914842fae0 100644
> > > --- a/arch/arm64/kernel/vdso/Makefile
> > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> > >
> > > ifneq ($(c-gettimeofday-y),)
> > > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > -Wno-maybe-uninitialized
> > > endif
> >
> > (...)
> >
> > I'd like to know exactly what is going on before suppressing the warning.
> > It is a non-standard warning, only enabled by *some* of the vDSO builds
> > for some reason.
> >
> > > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
> >
> > While I was able to download a configuration from this job and also use the
> > same container image, I can not reproduce the issue. Is the configuration the
> > full one or only the template?
> >
> > Could you provide full reproduction steps?
>
> You can try repro with:
>
> work/linux $ podman run -v .:/workdir/ --rm -it
> registry.freedesktop.org/linux-media/media-ci/build:latest
> $ cd /workdir
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> arch/arm64/kernel/vdso/vgettimeofday.o
>
> The gcc version discrepancy is because I the error was due to old gcc
> version and I was playing around with that... but it fails in both
> gcc14 and gcc15
Ack.
> You can try with debian testing with
> work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
> $ apt-get update
> $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
> $ cd /workdir
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> arch/arm64/kernel/vdso/vgettimeofday.o
Both reproducers do *not* reproduce the issue for me.
(It is more or less exactly what I tried before)
Please note that this line does not work in general:
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make arch/arm64/kernel/vdso/vgettimeofday.o
The vDSO object files can not be built in this way like regular kernel object
files and will produce a compiler error, but not the one under discussion.
Instead the vDSO on arm64 is built during the 'make prepare' phase.
(Other architectures work differently, of course...)
(...)
Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox