* [PATCH 4/5] arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS208xA SoC. The nodes are left disabled at the SoC level; board
DTs will enabled them once there are consumers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 +++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 6073e426774a..7d4260661766 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -280,6 +280,104 @@ sfp: efuse@1e80000 {
clock-names = "sfp";
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls2088a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls2088a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
isc: syscon@1f70000 {
compatible = "fsl,ls2080a-isc", "syscon";
reg = <0x0 0x1f70000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS1088A SoC. The nodes are left disabled at the SoC level; board
DTs will enable them once there are consumers.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 99016768b73f..dcf13ac1fce5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -239,6 +239,64 @@ reset: syscon@1e60000 {
reg = <0x0 0x1e60000 0x0 0x10000>;
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls1088a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls1088a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
isc: syscon@1f70000 {
compatible = "fsl,ls1088a-isc", "syscon";
reg = <0x0 0x1f70000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: ls1028a: describe the Lynx 10G SerDes
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the Lynx 10G SerDes block and its 4 SerDes lanes found on the
LS1028A SoC. The node is left disabled at the SoC level; board DTs will
be expected to enable it once the consumer Ethernet nodes use it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index f4ba3d16ab86..b4abdb5f906a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -250,6 +250,35 @@ ls1028a_uid: unique-id@1c {
};
};
+ serdes: phy@1ea0000 {
+ compatible = "fsl,ls1028a-serdes";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
scfg: syscon@1fc0000 {
compatible = "fsl,ls1028a-scfg", "syscon";
reg = <0x0 0x1fc0000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS1046A SoC. The nodes are left disabled at the SoC level; board
DTs will be expected to enable them once the consumer Ethernet nodes
appear.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 +++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 6fefe837f434..db935805c379 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -424,6 +424,66 @@ sfp: efuse@1e80000 {
clock-names = "sfp";
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls1046a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ big-endian;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls1046a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0xffff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ big-endian;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1046a-dcfg", "syscon";
reg = <0x0 0x1ee0000 0x0 0x1000>;
--
2.25.1
^ permalink raw reply related
* [PATCH 1/5] arm64: dts: lx2160a: transition to device-specific SerDes compatible strings
From: Ioana Ciornei @ 2026-06-30 11:04 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Align to the modern fsl,lynx-28g.yaml binding, where the SoC and SerDes
instance is present in the compatible string, to allow reliable per-lane
capability detection and per-lane customization of electrical properties.
These new bindings have #phy-cells = <0> in per-lane PHY providers, so
we need to update consumer phandles as well.
The modern bindings are backward-incompatible with old kernels, due
to the consumer phandles being either in one form or in another, as
explained here:
https://lore.kernel.org/lkml/20250930140735.mvo3jii7wgmzh2bs@skbuf/
One of the major differences between the LX2160A and LX2162A is the
SerDes. So far, LX2162A has used fsl-lx2160a-rev2.dtsi, but we need to
split that up even further, and derive a fsl-lx2162a.dtsi which
overrides the SerDes properties.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
.../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
.../dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
.../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
.../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
6 files changed, 182 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 4bc151d721dd..1f946d3a4ec0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -135,6 +135,10 @@ &sata3 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 935f421475ac..a40a968b9533 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -329,6 +329,10 @@ &uart0 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart1 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 1d73abffa6b7..a687eb3e3190 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -621,17 +621,163 @@ soc: soc {
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
+ /* Note on the interpretation of SerDes lane numbering from
+ * LX2160ARM lane mappings for RCW[SRDS_PRTCL_S1]:
+ * The letters (A-H) correspond to logical lane numbers in the
+ * SerDes register map (lane A's registers start with LNAGCR0),
+ * while the numbers (0-7) correspond to physical lanes as
+ * routed to pins. SerDes block #1 is flipped in the LX2160A
+ * floorplan (logical lane A goes to physical lane 7's pins),
+ * while SerDes blocks #2 and #3 are not. The lanes below are
+ * listed right to left when looking at that table.
+ * Both the numbers and the letters are according to the logical
+ * numbering scheme, and do not account for the flipping.
+ */
serdes_1: phy@1ea0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
reg = <0x0 0x1ea0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
+ status = "disabled";
+
+ serdes_1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
serdes_2: phy@1eb0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2160a-serdes2", "fsl,lynx-28g";
reg = <0x0 0x1eb0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
status = "disabled";
+
+ serdes_2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes_3: phy@1ec0000 {
+ compatible = "fsl,lx2160a-serdes3";
+ reg = <0x0 0x1ec0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ #phy-cells = <1>;
+
+ serdes_3_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
crypto: crypto@8000000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 99ee2b1c0f13..61e70e9c6e80 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -8,7 +8,7 @@
#include <dt-bindings/leds/common.h>
-#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2162a.dtsi"
#include "fsl-lx2162a-sr-som.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
index 7a595fddc027..0ba56b9819ac 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2162a.dtsi"
/ {
model = "NXP Layerscape LX2162AQDS";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
new file mode 100644
index 000000000000..b9629e074d94
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree Include file for Layerscape-LX2162A family SoC.
+//
+// Copyright 2025 NXP
+
+#include "fsl-lx2160a-rev2.dtsi"
+
+&serdes_1 {
+ compatible = "fsl,lx2162a-serdes1", "fsl,lynx-28g";
+
+ /delete-node/ phy@0;
+ /delete-node/ phy@1;
+ /delete-node/ phy@2;
+ /delete-node/ phy@3;
+};
+
+&serdes_2 {
+ compatible = "fsl,lx2162a-serdes2", "fsl,lynx-28g";
+};
+
+&soc {
+ /delete-node/ serdes@1ec0000;
+};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 01/10] kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n
From: Pratyush Yadav @ 2026-06-30 11:05 UTC (permalink / raw)
To: Wandun Chen
Cc: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
alex, akpm, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy
In-Reply-To: <20260630074715.4126796-2-chenwandun1@gmail.com>
On Tue, Jun 30 2026, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Prepare for an upcoming change that excludes non-dumpable reserved
> regions from the kdump vmcore and will call crash_exclude_mem_range()
> from generic, non-arch code.
>
> No functional change.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
From: Peter Griffin @ 2026-06-30 11:02 UTC (permalink / raw)
To: Alim Akhtar
Cc: Denzeel Oliva, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Conor Dooley, linux-samsung-soc, linux-clk,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <0f1e01dd0844$01190c40$034b24c0$@samsung.com>
Hi Alim,
On Tue, 30 Jun 2026 at 04:53, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Peter Griffin <peter.griffin@linaro.org>
> > Sent: Monday, June 29, 2026 6:02 PM
> > To: Denzeel Oliva <wachiturroxd150@gmail.com>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>; Sylwester Nawrocki
> > <s.nawrocki@samsung.com>; Chanwoo Choi <cw00.choi@samsung.com>;
> > Alim Akhtar <alim.akhtar@samsung.com>; Michael Turquette
> > <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Brian
> > Masney <bmasney@redhat.com>; Rob Herring <robh@kernel.org>; Conor
> > Dooley <conor+dt@kernel.org>; linux-samsung-soc@vger.kernel.org; linux-
> > clk@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock
> > parents
> >
> > Hi Krysztof & Denzeel,
> >
> > On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <wachiturroxd150@gmail.com>
> > wrote:
> > >
> > > Correct eight PERIS gate clock parents to match the hardware clock
> > > tree and reorder the GIC mux parents so mout_peris_bus_user is the
> > > default source.
> > >
> > > Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
> > > ---
> >
> > Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> >
> > @Krysztof: I was thinking, maybe we should establish a new rule/best
> > practice for Samsung clock upstream submissions whereby patch
> > contributors should link to the downstream cal-if code for the SoC after the --
> > - line. That would make reviewing the patches' correctness a bit easier, as the
> > downstream cal-if code would be readily available to the reviewer.
> >
> We can leave this choice to the reviewer if they want to refer to downstream cal-if code.
Generally I would like to, but I also don't have time to hunt around
the internet for a downstream kernel tree. My rationale was that the
submitter is most likely to know where the downstream code is, and is
likely using it for the upstream clock implementation. So, linking to
it as part of the submission should hopefully be fairly easy.
If it is a Samsung SoC for which no public code is available that's
fine. I didn't intend this to be a hard requirement: "you can't
upstream x,y,z unless you link to the cal-if code". I meant it more as
"best practice/guidance"; if the cal-if code is publicly available,
linking to it would be a useful reference for reviewers.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH v5 2/4] firmware: arm_sdei: add SDEI_EVENT_SIGNAL support
From: Kiryl Shutsemau @ 2026-06-30 10:58 UTC (permalink / raw)
To: Usama Arif
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Doug Anderson, Petr Mladek, Thomas Gleixner,
Andrew Morton, Baoquan He, Puranjay Mohan, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630105125.4006859-1-usama.arif@linux.dev>
On Tue, Jun 30, 2026 at 03:51:24AM -0700, Usama Arif wrote:
> On Mon, 29 Jun 2026 16:07:16 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> >
> > Add sdei_event_signal(), a thin wrapper over the SDEI_EVENT_SIGNAL call
> > (DEN0054) that makes the software-signalled event (event 0) pending on a
> > target PE -- delivered NMI-like even when that PE has interrupts masked.
> > It takes no locks, so it is safe to call from NMI / crash context.
> >
> > Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > ---
> > drivers/firmware/arm_sdei.c | 12 ++++++++++++
> > include/linux/arm_sdei.h | 6 ++++++
> > include/uapi/linux/arm_sdei.h | 1 +
> > 3 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> > index c161cf263547..e8dd2f0f3919 100644
> > --- a/drivers/firmware/arm_sdei.c
> > +++ b/drivers/firmware/arm_sdei.c
> > @@ -339,6 +339,18 @@ static void _ipi_unmask_cpu(void *ignored)
> > sdei_unmask_local_cpu();
> > }
> >
> > +/*
> > + * Signal the software-signalled event (event 0) to @mpidr. Does nothing
> > + * but the SMC -- no locks, no event lookup -- so it is safe from NMI /
> > + * crash context (e.g. the cross-CPU NMI service).
> > + */
> > +int sdei_event_signal(u32 event_num, u64 mpidr)
> > +{
> > + return invoke_sdei_fn(SDEI_1_0_FN_SDEI_EVENT_SIGNAL, event_num,
> > + mpidr, 0, 0, 0, NULL);
> > +}
> > +NOKPROBE_SYMBOL(sdei_event_signal);
> > +
>
> Same as patch 1, can this be merged in patch 3? Its good to keep functions
> where they are used.
Patch 3 is big as it is. I don't think folding code that can be a
standalone patch helps the situation.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v5 1/4] firmware: arm_sdei: add sdei_is_present()
From: Kiryl Shutsemau @ 2026-06-30 10:57 UTC (permalink / raw)
To: Usama Arif
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Doug Anderson, Petr Mladek, Thomas Gleixner,
Andrew Morton, Baoquan He, Puranjay Mohan, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630104713.3847805-1-usama.arif@linux.dev>
On Tue, Jun 30, 2026 at 03:47:11AM -0700, Usama Arif wrote:
> On Mon, 29 Jun 2026 16:07:15 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> >
> > invoke_sdei_fn() returns -EIO when no SDEI conduit was probed, and the
> > core warns ("Failed to create event ...") on any registration that hits
> > that. An optional consumer that registers an event from an unconditional
> > initcall would therefore make every boot on a non-SDEI system emit that
> > warning for what is simply absent firmware.
> >
> > Expose whether SDEI firmware is present so such a consumer can skip
> > registration -- and the warning -- when there is nothing to talk to.
> >
> > Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > ---
>
> Can this be merged in patch 3 where this function is actually used?
I can do it either way. Standalone commit looks good to me.
But if maintainer wants, I can fold it.
> > drivers/firmware/arm_sdei.c | 10 ++++++++++
> > include/linux/arm_sdei.h | 3 +++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> > index f39ed7ba3a38..c161cf263547 100644
> > --- a/drivers/firmware/arm_sdei.c
> > +++ b/drivers/firmware/arm_sdei.c
> > @@ -339,6 +339,16 @@ static void _ipi_unmask_cpu(void *ignored)
> > sdei_unmask_local_cpu();
> > }
> >
> > +/*
> > + * Was SDEI firmware probed and is it usable? Lets optional consumers skip
> > + * registering an event -- and the warning a failed registration emits -- on
> > + * systems with no SDEI.
> > + */
> > +bool sdei_is_present(void)
> > +{
> > + return sdei_firmware_call;
>
> sdei_firmware_call is a function pointer. The above is correct, but
> can we make it sdei_firmware_call != NULL? I think that looks a lot better.
Again, I don't care much, but checkpatch doesn't like comparison to NULL.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v4] net: stmmac: fix fatal bus error on resume by reinitializing RX buffers
From: Paolo Abeni @ 2026-06-30 10:55 UTC (permalink / raw)
To: Ding Hui, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Maxime Chevallier, Ding Hui,
open list:STMMAC ETHERNET DRIVER,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
Cc: xiasanbo, yangchen11, liuxuanjun
In-Reply-To: <20260627122533.1165324-1-dinghui1111@163.com>
On 6/27/26 2:25 PM, Ding Hui wrote:
> From: Ding Hui <dinghui@lixiang.com>
>
> On suspend, stmmac_suspend() calls stmmac_disable_all_queues() which
> stops the RX NAPI, but the RX DMA engine may still be running for a
> short window before stmmac_stop_all_dma() takes effect. During that
> window the hardware can write incoming frames into the buffers pointed
> to by the RX descriptors and write back the descriptors (clearing the
> OWN bit and overwriting RDES0/1/2 with status/timestamp data). Because
> NAPI is already disabled, the driver never refills these descriptors,
> so the RX ring is left in a "consumed but not refilled" state with
> stale content in the descriptor buffer-address fields.
>
> On resume, stmmac_clear_descriptors() only re-arms the OWN bit and
> does not repopulate the RX buffer address fields. When the DMA is
> restarted it dereferences these stale addresses and triggers a fatal
> bus error (not kernel panic, just a Fatal Bus Error interrupt and
> RX DMA engine halts).
>
> Fix this by introducing stmmac_reinit_rx_descriptors(), called from
> stmmac_resume() immediately after stmmac_clear_descriptors(). The
> helper iterates every RX descriptor slot and re-programs its buffer
> address fields:
>
> - For normal (page_pool) queues: restore RDES0/1 from buf->addr and
> RDES2 from buf->sec_addr. The DMA mapping has remained valid across
> suspend/resume because no pages were freed. Slots left NULL by a
> prior GFP_ATOMIC failure in stmmac_rx_refill() before suspend
> are re-allocated here with GFP_KERNEL;
> -ENOMEM is returned and resume is aborted if allocation fails.
> The slots with null buffer are unacceptable, because they will
> cause a DMA suspend dead lock problem by the condition of
> Current Descriptor Pointer == Descriptor Tail Pointer.
>
> - For AF_XDP zero-copy queues: restore the DMA address from
> xsk_buff_xdp_get_dma(buf->xdp). Slots with no xdp buffer
> (e.g. TX-only socket, empty fill ring) attempt xsk_buff_alloc()
> first; on failure the descriptor is zeroed so the DMA engine skips
> the slot safely via an RBU event.
>
> - For chain mode: call stmmac_mode_init() to rebuild the des3 next-
> descriptor pointer chain, which hardware may have overwritten with
> a PTP timestamp value (as noted in chain_mode.c:refill_desc3()).
>
> After reprogramming all address fields, a final pass restores OWN=1
> on every valid slot. This is necessary because set_sec_addr and
> chain-mode init unconditionally overwrite des3 (clearing the OWN bit
> set by stmmac_clear_descriptors()), and must run after all address
> writes are complete.
>
> Also fix stmmac_init_rx_buffers() to actually use its gfp_t flags
> parameter instead of the hardcoded GFP_ATOMIC | __GFP_NOWARN.
>
> Signed-off-by: Ding Hui <dinghui@lixiang.com>
This looks like 'net' material, it should specify 'net' into the subj
prefix and include a suitable Fixes tag.
> ---
> Changes in v4:
> - Just add description for return value of 'stmmac_reinit_rx_descriptors'.
> - Link to v3:
> https://lore.kernel.org/netdev/20260604144557.3175399-1-dinghui1111@163.com/
>
> Changes in v3:
> - Re-allocate page_pool NULL slots (from prior GFP_ATOMIC failures)
> with GFP_KERNEL in stmmac_reinit_rx_descriptors(); return -ENOMEM and
> abort resume.
> - For XSK NULL slots, attempt xsk_buff_alloc() first; fall back to
> stmmac_clear_desc() only when allocation fails.
> - Add a re-arm loop at the end of stmmac_reinit_rx_descriptors() to
> restore OWN=1 on all valid slots, since set_sec_addr and
> chain-mode init both write des3 unconditionally.
> - stmmac_reinit_rx_descriptors() now returns int; stmmac_resume()
> checks the return value and propagates -ENOMEM with mutex/rtnl cleanup.
> - Fix stmmac_init_rx_buffers() to use its flags parameter instead of
> hardcoded GFP_ATOMIC | __GFP_NOWARN.
> (884d2b845477 ("net: stmmac: Add GFP_DMA32 for rx buffers if no 64
> capability"))
> - Run stmmac_reinit_rx_descriptors() after stmmac_clear_descriptors()
> so that stmmac_clear_desc() on XSK NULL slots overrides the OWN
> bit set by stmmac_clear_descriptors().
> - Update commit message.
> - Link to v2:
> https://lore.kernel.org/netdev/20260526022620.501229-1-dinghui1111@163.com/
>
> Changes in v2:
> - Introducing stmmac_reinit_rx_descriptors() to reinitializing rx
> buffers without any allocation.
> - Modify commit log.
> - Link to v1:
> https://lore.kernel.org/netdev/20260515053856.2310369-1-dinghui1111@163.com/
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 164 +++++++++++++++++-
> 1 file changed, 163 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3591755ea30b..c82f3d5dbd43 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1660,7 +1660,7 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
> {
> struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
> struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
> - gfp_t gfp = (GFP_ATOMIC | __GFP_NOWARN);
> + gfp_t gfp = flags;
The above should go via a separate (net) patch.
>
> if (priv->dma_cap.host_dma_width <= 32)
> gfp |= GFP_DMA32;
> @@ -1693,6 +1693,148 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
> return 0;
> }
>
> +/**
> + * stmmac_reinit_rx_descriptors - re-program RX descriptor buffer addresses
> + * after stmmac_clear_descriptors()
> + * @priv: driver private structure
> + * @dma_conf: structure holding the dma data
> + * @queue: RX queue index
> + *
> + * Description: Called in the resume path after stmmac_clear_descriptors()
> + * has re-armed the OWN bit on every descriptor. Walk buf_pool[] and
> + * re-program the buffer-address fields of every RX descriptor from the
> + * buffers that are already attached to the queue. Slots whose page was
> + * never allocated (GFP_ATOMIC failure before suspend) are re-allocated
> + * here with GFP_KERNEL; the resume path is in process context.
> + *
> + * Between suspend and resume the hardware may have written back status/
> + * length information into the descriptor address fields (RDESx are reused
> + * for status on completion for GMAC4/XGMAC), so the address fields must be
> + * repopulated before the DMA is restarted.
> + *
> + * For XSK slots that have no xdp buffer at suspend time (TX-only socket,
> + * empty fill ring for Rx), xsk_buff_alloc() is attempted but does not
> + * return an error on failure because we can't identify a real TX-only
> + * socket from an alloc error (same as stmmac_alloc_rx_buffers_zc() in
> + * __init_dma_rx_desc_rings); on failure the descriptor is zeroed so the DMA
> + * engine skips the slot safely.
> + *
> + * To avoid the DMA stall after resume in non-XSK mode, this function
> + * re-allocates pages for NULL slots using GFP_KERNEL (the resume path runs
> + * in process context). If allocation fails, -%ENOMEM is returned immediately
> + * and the resume is aborted; the caller should report the error.
> + *
> + * This helper must be called after stmmac_clear_descriptors() and before
> + * stmmac_hw_setup() in stmmac_resume() because we need to wipe the OWN bit
> + * set in stmmac_clear_descriptors() for NULL slots in XSK mode.
Please try to condense the above text in one or 2 paragraph.
> + *
> + * Returns: 0 on success, or a negative errno on allocation failure in
> + * non-XSK mode (e.g. -%ENOMEM).
> + */
> +static int stmmac_reinit_rx_descriptors(struct stmmac_priv *priv,
> + struct stmmac_dma_conf *dma_conf,
> + u32 queue)
> +{
> + struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
> + struct stmmac_rx_buffer *buf;
> + struct dma_desc *p;
> + int i;
> +
> + if (rx_q->xsk_pool) {
> + for (i = 0; i < dma_conf->dma_rx_size; i++) {
> + buf = &rx_q->buf_pool[i];
> + p = stmmac_get_rx_desc(priv, rx_q, i);
> +
> + /* The XSK pool may not be fully populated (e.g.
> + * xdpsock TX-only, empty fill ring). Try to refill
> + * from the pool; on failure zero the descriptor so the
> + * DMA engine skips this slot safely.
> + */
> + if (!buf->xdp) {
> + buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
> + if (!buf->xdp) {
> + stmmac_clear_desc(priv, p);
> + continue;
> + }
> + }
> +
> + stmmac_set_desc_addr(priv, p,
> + xsk_buff_xdp_get_dma(buf->xdp));
> + stmmac_set_desc_sec_addr(priv, p, 0, false);
> + }
> + } else {
> + for (i = 0; i < dma_conf->dma_rx_size; i++) {
> + buf = &rx_q->buf_pool[i];
> + p = stmmac_get_rx_desc(priv, rx_q, i);
> +
> + /* buf->page can be NULL when stmmac_rx_refill() hit a
> + * GFP_ATOMIC failure before suspend and left the slot
> + * without a buffer. The resume path runs in process
> + * context, so re-allocate with GFP_KERNEL. Allocation
> + * failure aborts the resume.
> + */
> + if (!buf->page) {
> + int err;
> +
> + err = stmmac_init_rx_buffers(priv, dma_conf, p,
> + i, GFP_KERNEL,
> + queue);
> + if (err)
> + return err;
> + /* stmmac_init_rx_buffers() already programmed
> + * the descriptor; skip the reprogramming below.
> + */
> + continue;
> + }
> +
> + stmmac_set_desc_addr(priv, p, buf->addr);
> + stmmac_set_desc_sec_addr(priv, p, buf->sec_addr,
> + priv->sph_active &&
> + buf->sec_page);
AFAICS stmmac_rx_refill() can error out after successfully allocating
buf->page, but leaving a NULL sec_page, I think you should try to
realloc even the latter.
Finally this chunk shares quite a bit of code with stmmac_rx_refill()
and stmmac_rx_refill_zc() it would be better try to factor out common
helpers.
/P
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Rafael J. Wysocki (Intel) @ 2026-06-30 10:55 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <akOfu2EIQq3CJgqw@lpieralisi>
On Tue, Jun 30, 2026 at 12:51 PM Lorenzo Pieralisi
<lpieralisi@kernel.org> wrote:
>
> On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
>
> [...]
>
> > > +#ifdef CONFIG_ACPI
> > > + if (has_acpi_companion(&pdev->dev))
> > > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > > +#endif
> >
> > I would rather add a wrapper for this, along with an empty stub for
> > the !CONFIG_ACPI case.
>
> #ifdef CONFIG_ACPI
> static inline void acpi_device_clear_dep(struct device *dev)
> {
> if (has_acpi_companion(dev))
> acpi_dev_clear_dependencies(ACPI_COMPANION(dev));
>
> }
> #else
> static inline void acpi_device_clear_dep(struct device *dev) {}
> #endif
>
> Something like that ?
Yup.
^ permalink raw reply
* Re: [PATCH v3 12/17] arm64: dts: nvidia: Add EL2 virtual timer interrupt
From: Marc Zyngier @ 2026-06-30 10:54 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
linux-tegra@vger.kernel.org, Lorenzo Pieralisi, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
Mark Rutland, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Ge Gordon, BST Linux Kernel Upstream Group,
Jesper Nilsson, Lars Persson, Alim Akhtar, Ivaylo Ivanov,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dinh Nguyen, Matthias Brugger, AngeloGioacchino Del Regno,
Thierry Reding, Bjorn Andersson, Konrad Dybcio,
Andreas Färber,
"Yu-Chun Lin [林祐君]", Heiko Stuebner,
Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <3c714ae3-8f62-4785-9f61-ba9899fd70d8@nvidia.com>
Hi Jon,
On Tue, 30 Jun 2026 10:42:34 +0100,
Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Marc,
>
> On 23/05/2026 15:02, Marc Zyngier wrote:
> > The ARMv8.2 based CPUs used in a number of nvidia SoCs are missing
> > the EL2 virtual timer interrupt. Add it.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 ++
> > arch/arm64/boot/dts/nvidia/tegra234.dtsi | 3 ++-
> > 2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index 849694f751d90..45cc180ac9973 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -3163,6 +3163,8 @@ timer {
> > <GIC_PPI 11
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 12
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > interrupt-parent = <&gic>;
> > always-on;
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> > index 04a95b6658caa..ab9813f9ba30c 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> > @@ -5872,7 +5872,8 @@ timer {
> > interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > - <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 12 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > interrupt-parent = <&gic>;
> > always-on;
> > };
>
> Sorry for the delay. I gave this a test because I observed the warning
> that was added on the Tegra194 and Tegra234 platforms. This change
> fixes the warning for Tegra234, but on Tegra194 the platforms I tested
> hang on boot. It appears to be similar to the issue that Marek saw on
> his platforms and so I am wondering if Tegra194 also doesn't have this
> wired up?
I think you are in a better position than me to find out. It also
could be a firmware issue not making the PPI a Group-1 interrupt, and
therefore not allow Linux to configure the interrupt.
>
> Was there any resolution to the issue reported by Marek?
>
> FYI, the Tegra194 SoC has the 'NVIDIA Carmel ARM v8.2' CPUs [0].
There is no resolution so far. Florian was going to check what the
deal is with the Broadcom-related systems, but hasn't come back with
an answer yet.
The possibilities are as follows:
- remove the interrupt for the EL2 virtual timer and live with the
warning
- add a patch such as [1], which should document the reason why this
is now working (and fallback to the EL2 physical timer)
I'm happy either way, as long as we know exactly what we are dealing
with on each affected platform.
Thanks,
M.
[1] https://lore.kernel.org/all/878q898ulx.wl-maz@kernel.org/
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Lorenzo Pieralisi @ 2026-06-30 10:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Sunil V L, Marc Zyngier, Thomas Gleixner, Huacai Chen,
Anup Patel, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-riscv, linux-kernel, linux-acpi,
linux-arm-kernel, loongarch
In-Reply-To: <CAJZ5v0ibZKfzJwGyUb92-K1N9C_ab0QujpAKCrvMdyygquS1Vw@mail.gmail.com>
On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
[...]
> > +#ifdef CONFIG_ACPI
> > + if (has_acpi_companion(&pdev->dev))
> > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > +#endif
>
> I would rather add a wrapper for this, along with an empty stub for
> the !CONFIG_ACPI case.
#ifdef CONFIG_ACPI
static inline void acpi_device_clear_dep(struct device *dev)
{
if (has_acpi_companion(dev))
acpi_dev_clear_dependencies(ACPI_COMPANION(dev));
}
#else
static inline void acpi_device_clear_dep(struct device *dev) {}
#endif
Something like that ?
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v5 2/4] firmware: arm_sdei: add SDEI_EVENT_SIGNAL support
From: Usama Arif @ 2026-06-30 10:51 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Usama Arif, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Marc Zyngier, Doug Anderson, Petr Mladek,
Thomas Gleixner, Andrew Morton, Baoquan He, Puranjay Mohan,
Breno Leitao, Julien Thierry, Lecopzer Chen, Sumit Garg,
kernel-team, kexec, linux-arm-kernel, linux-kernel,
Kiryl Shutsemau (Meta)
In-Reply-To: <def2f1a87ea36a5c3817ca5fbed8a01b7422e4c7.1782744912.git.kas@kernel.org>
On Mon, 29 Jun 2026 16:07:16 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Add sdei_event_signal(), a thin wrapper over the SDEI_EVENT_SIGNAL call
> (DEN0054) that makes the software-signalled event (event 0) pending on a
> target PE -- delivered NMI-like even when that PE has interrupts masked.
> It takes no locks, so it is safe to call from NMI / crash context.
>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> ---
> drivers/firmware/arm_sdei.c | 12 ++++++++++++
> include/linux/arm_sdei.h | 6 ++++++
> include/uapi/linux/arm_sdei.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index c161cf263547..e8dd2f0f3919 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -339,6 +339,18 @@ static void _ipi_unmask_cpu(void *ignored)
> sdei_unmask_local_cpu();
> }
>
> +/*
> + * Signal the software-signalled event (event 0) to @mpidr. Does nothing
> + * but the SMC -- no locks, no event lookup -- so it is safe from NMI /
> + * crash context (e.g. the cross-CPU NMI service).
> + */
> +int sdei_event_signal(u32 event_num, u64 mpidr)
> +{
> + return invoke_sdei_fn(SDEI_1_0_FN_SDEI_EVENT_SIGNAL, event_num,
> + mpidr, 0, 0, 0, NULL);
> +}
> +NOKPROBE_SYMBOL(sdei_event_signal);
> +
Same as patch 1, can this be merged in patch 3? Its good to keep functions
where they are used.
> /*
> * Was SDEI firmware probed and is it usable? Lets optional consumers skip
> * registering an event -- and the warning a failed registration emits -- on
> diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
> index b07113eeeff7..b9dc21c241be 100644
> --- a/include/linux/arm_sdei.h
> +++ b/include/linux/arm_sdei.h
> @@ -37,6 +37,12 @@ int sdei_event_unregister(u32 event_num);
> int sdei_event_enable(u32 event_num);
> int sdei_event_disable(u32 event_num);
>
> +/*
> + * Signal the software-signalled event (event 0) to another PE, NMI-like.
> + * @mpidr is the target's MPIDR affinity.
> + */
> +int sdei_event_signal(u32 event_num, u64 mpidr);
> +
> /* Was SDEI firmware probed and usable? */
> bool sdei_is_present(void);
>
> diff --git a/include/uapi/linux/arm_sdei.h b/include/uapi/linux/arm_sdei.h
> index af0630ba5437..22eb61612673 100644
> --- a/include/uapi/linux/arm_sdei.h
> +++ b/include/uapi/linux/arm_sdei.h
> @@ -22,6 +22,7 @@
> #define SDEI_1_0_FN_SDEI_PE_UNMASK SDEI_1_0_FN(0x0C)
> #define SDEI_1_0_FN_SDEI_INTERRUPT_BIND SDEI_1_0_FN(0x0D)
> #define SDEI_1_0_FN_SDEI_INTERRUPT_RELEASE SDEI_1_0_FN(0x0E)
> +#define SDEI_1_0_FN_SDEI_EVENT_SIGNAL SDEI_1_0_FN(0x0F)
> #define SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI_1_0_FN(0x11)
> #define SDEI_1_0_FN_SDEI_SHARED_RESET SDEI_1_0_FN(0x12)
>
> --
> 2.54.0
>
>
^ permalink raw reply
* [PATCH v5 2/2] i2c: imx-lpi2c: reset controller in probe stage
From: carlos.song @ 2026-06-30 10:52 UTC (permalink / raw)
To: Frank.Li, aisheng.dong, andi.shyti, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260630105223.3687516-1-carlos.song@oss.nxp.com>
From: Carlos Song <carlos.song@nxp.com>
Reset I2C controller in probe stage to avoid unexpected LPI2C controller
state left from previous stages and hang system boot.
Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)"
and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states:
"The reset takes effect immediately and remains asserted until negated
by software. There is no minimum delay required before clearing the
software reset."
Therefore, it is safe to write 0 to MCR and SCR immediately after
asserting the RST bit without any additional delay.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 2dc4331ed796..9fbdce85d7ca 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1510,11 +1510,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
if (ret)
lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
- ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
- pdev->name, lpi2c_imx);
- if (ret)
- return dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
-
i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
platform_set_drvdata(pdev, lpi2c_imx);
@@ -1551,6 +1546,22 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
+ /*
+ * Reset all internal controller registers of both Master and Target
+ * to avoid effects of previous status.
+ */
+ writel(MCR_RST, lpi2c_imx->base + LPI2C_MCR);
+ writel(SCR_RST, lpi2c_imx->base + LPI2C_SCR);
+ writel(0, lpi2c_imx->base + LPI2C_MCR);
+ writel(0, lpi2c_imx->base + LPI2C_SCR);
+
+ ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
+ pdev->name, lpi2c_imx);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
+ goto rpm_disable;
+ }
+
temp = readl(lpi2c_imx->base + LPI2C_PARAM);
lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
--
2.43.0
^ permalink raw reply related
* [PATCH v5 1/2] i2c: imx-lpi2c: properly unwind resources on probe failure
From: carlos.song @ 2026-06-30 10:52 UTC (permalink / raw)
To: Frank.Li, aisheng.dong, andi.shyti, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260630105223.3687516-1-carlos.song@oss.nxp.com>
From: Carlos Song <carlos.song@nxp.com>
When probe fails at devm_clk_rate_exclusive_get() or clk_get_rate(),
which occur before runtime PM is initialized, the clocks enabled by
clk_bulk_prepare_enable() are never disabled.
When probe fails after runtime PM is initialized, the previous error
path called pm_runtime_put_sync(), which triggers the runtime suspend
callback. However, due to different clock management strategies on
different SoCs[1] (to avoid deadlocks between the global prepare_lock
and runtime PM), the callback may only disable clocks without
unpreparing them, causing an incomplete unwind.
Introduce a new error label 'clk_disable' to explicitly invoke
clk_bulk_disable_unprepare(). Replace pm_runtime_put_sync() with the
sequence of pm_runtime_disable(), pm_runtime_set_suspended() and
pm_runtime_put_noidle() to bypass the runtime suspend callback during
error recovery. During the LPI2C driver probe phase, clock APIs are
used exclusively to manage clocks. Once probing succeeds, clock
management is handed over to the runtime PM core.
[1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index e6c24a9d934d..2dc4331ed796 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1527,14 +1527,19 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
* each transfer
*/
ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
- if (ret)
- return dev_err_probe(&pdev->dev, ret,
- "can't lock I2C peripheral clock rate\n");
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret,
+ "can't lock I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
- if (!lpi2c_imx->rate_per)
- return dev_err_probe(&pdev->dev, -EINVAL,
- "can't get I2C peripheral clock rate\n");
+ if (!lpi2c_imx->rate_per) {
+ ret = -EINVAL;
+ dev_err_probe(&pdev->dev, ret,
+ "can't get I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
@@ -1576,8 +1581,11 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
rpm_disable:
pm_runtime_dont_use_autosuspend(&pdev->dev);
- pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+clk_disable:
+ clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v5 0/2] i2c: imx-lpi2c: fix probe error handling and reset controller
From: carlos.song @ 2026-06-30 10:52 UTC (permalink / raw)
To: Frank.Li, aisheng.dong, andi.shyti, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
From: Carlos Song <carlos.song@nxp.com>
During probe, two issues exist in the LPI2C driver:
1. The error paths do not properly unwind all acquired resources on
failure. Clocks enabled before runtime PM initialization are never
disabled on certain error paths, when probe fails after runtime PM
is initialized, the previous error path called pm_runtime_put_sync(),
however, due to different clock management strategies on different
SoCs[1] (to avoid deadlocks between the global prepare_lock and runtime
PM), the callback may only disable clocks without unpreparing them,
causing an incomplete unwind.
2. The LPI2C controller may retain unexpected state from previous
boot stages, causing the system to hang during probe.
This series addresses both issues. Patch 1 restructures the probe
error paths to ensure correct resource cleanup on failure. Patch 2
resets the Master and Target controller logic before IRQ registration
to clear any leftover state.
[1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/
Changes for v5:
- Remove devm_free_irq() and free_irq err label.
- Change commit log to explain why not using runtime PM to manage clocks
during the probe phase.
Changes for v4:
- Split v3 into two patches per reviewer feedback:
* Patch 1 contains only the error path restructuring.
* Patch 2 contains only the controller reset and the IRQ
relocation that is required by the reset ordering.
Changes for v3:
- Reset the Target logic via LPI2C_SCR in addition to MCR.
- Replace pm_runtime_put_sync() with pm_runtime_disable() +
pm_runtime_set_suspended() + pm_runtime_put_noidle() to avoid
triggering the suspend callback during error recovery.
- Add clk_disable and free_irq labels for complete error unwinding.
- Update commit log to cover the SCR reset rationale.
Changes for v2:
- Jump to rpm_disable instead of returning directly if the IRQ
request fails.
Carlos Song (2):
i2c: imx-lpi2c: properly unwind resources on probe failure
i2c: imx-lpi2c: reset controller in probe stage
drivers/i2c/busses/i2c-imx-lpi2c.c | 43 +++++++++++++++++++++---------
1 file changed, 31 insertions(+), 12 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v5 1/4] firmware: arm_sdei: add sdei_is_present()
From: Usama Arif @ 2026-06-30 10:47 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Usama Arif, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Marc Zyngier, Doug Anderson, Petr Mladek,
Thomas Gleixner, Andrew Morton, Baoquan He, Puranjay Mohan,
Breno Leitao, Julien Thierry, Lecopzer Chen, Sumit Garg,
kernel-team, kexec, linux-arm-kernel, linux-kernel,
Kiryl Shutsemau (Meta)
In-Reply-To: <dcf564152da8fc599cbfbe8b8d254fe837262ed3.1782744912.git.kas@kernel.org>
On Mon, 29 Jun 2026 16:07:15 +0100 Kiryl Shutsemau <kirill@shutemov.name> wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> invoke_sdei_fn() returns -EIO when no SDEI conduit was probed, and the
> core warns ("Failed to create event ...") on any registration that hits
> that. An optional consumer that registers an event from an unconditional
> initcall would therefore make every boot on a non-SDEI system emit that
> warning for what is simply absent firmware.
>
> Expose whether SDEI firmware is present so such a consumer can skip
> registration -- and the warning -- when there is nothing to talk to.
>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> ---
Can this be merged in patch 3 where this function is actually used?
> drivers/firmware/arm_sdei.c | 10 ++++++++++
> include/linux/arm_sdei.h | 3 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index f39ed7ba3a38..c161cf263547 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -339,6 +339,16 @@ static void _ipi_unmask_cpu(void *ignored)
> sdei_unmask_local_cpu();
> }
>
> +/*
> + * Was SDEI firmware probed and is it usable? Lets optional consumers skip
> + * registering an event -- and the warning a failed registration emits -- on
> + * systems with no SDEI.
> + */
> +bool sdei_is_present(void)
> +{
> + return sdei_firmware_call;
sdei_firmware_call is a function pointer. The above is correct, but
can we make it sdei_firmware_call != NULL? I think that looks a lot better.
> +}
> +
> static void _ipi_private_reset(void *ignored)
> {
> int err;
> diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
> index f652a5028b59..b07113eeeff7 100644
> --- a/include/linux/arm_sdei.h
> +++ b/include/linux/arm_sdei.h
> @@ -37,6 +37,9 @@ int sdei_event_unregister(u32 event_num);
> int sdei_event_enable(u32 event_num);
> int sdei_event_disable(u32 event_num);
>
> +/* Was SDEI firmware probed and usable? */
> +bool sdei_is_present(void);
> +
> /* GHES register/unregister helpers */
> int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *normal_cb,
> sdei_event_callback *critical_cb);
> --
> 2.54.0
>
>
^ permalink raw reply
* Re: [PATCH] soc: ti: knav_dma: remove debugfs file on teardown
From: Hari Prasath @ 2026-06-30 10:45 UTC (permalink / raw)
To: Pengpeng Hou, Nishanth Menon, Santosh Shilimkar, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260615091200.2373-1-pengpeng@iscas.ac.cn>
Hello,
On 15/06/26 2:42 pm, Pengpeng Hou wrote:
> knav_dma_probe() creates the global knav_dma debugfs file whose show
> callback walks the global kdev list. knav_dma_remove() tears down the DMA
> instances and runtime PM but leaves that debugfs file and global ready
> state behind.
>
> Save the debugfs dentry, remove it before destroying the DMA state, and
> clear the global ready pointer state during remove.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/soc/ti/knav_dma.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
> index e5f5e3142fc4..9277c525ac21 100644
> --- a/drivers/soc/ti/knav_dma.c
> +++ b/drivers/soc/ti/knav_dma.c
> @@ -125,6 +125,7 @@ struct knav_dma_chan {
> ch->channel : ch->flow)
>
> static struct knav_dma_pool_device *kdev;
> +static struct dentry *knav_dma_debugfs;
>
> static bool device_ready;
> bool knav_dma_device_ready(void)
> @@ -740,8 +741,9 @@ static int knav_dma_probe(struct platform_device *pdev)
> goto err_put_sync;
> }
>
> - debugfs_create_file("knav_dma", S_IFREG | S_IRUGO, NULL, NULL,
> - &knav_dma_debug_fops);
> + knav_dma_debugfs = debugfs_create_file("knav_dma", 0444,
> + NULL, NULL,
> + &knav_dma_debug_fops);
>
> device_ready = true;
> return ret;
> @@ -758,6 +760,10 @@ static void knav_dma_remove(struct platform_device *pdev)
> {
> struct knav_dma_device *dma;
>
> + device_ready = false;
> + debugfs_remove(knav_dma_debugfs);
Does this handle the case where a process already has the debugfs file
open? A concurrent read() from the userspace could still potentially
reach knav_dma_debug_show() and access kdev while it's being torn down
below. Pls check and add necessary protection around kdev access.
Regards,
Hari
> + knav_dma_debugfs = NULL;
> +
> list_for_each_entry(dma, &kdev->list, list) {
> if (atomic_dec_return(&dma->ref_count) == 0)
> knav_dma_hw_destroy(dma);
> @@ -765,6 +771,7 @@ static void knav_dma_remove(struct platform_device *pdev)
>
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> + kdev = NULL;
> }
>
> static struct of_device_id of_match[] = {
^ permalink raw reply
* [PATCH v3 5/5] arm64: dts: qcom: glymur: use Aggregator TNOC compatible
From: Jie Gan @ 2026-06-30 10:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com>
The traceNoC node used the "qcom,coresight-itnoc" compatible, which
describes an Interconnect TNOC. That device has no aggregation and no
ATID functionality, so the driver marks its trace ID as unsupported.
This node is actually an Aggregator TNOC, as shown by its tn_ag_*
endpoints, and should expose a system trace ID.
Switch the node to the standalone "qcom,coresight-agtnoc" compatible so
it probes as an Aggregator TNOC and allocates a system trace ID. Rename
the node to "tn" and use the "apb_pclk" clock name as required by the
Aggregator TNOC binding.
Fixes: 1f7d0c42a08d ("arm64: dts: qcom: glymur: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..d612e8ed54c8 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -6038,12 +6038,12 @@ qm_tpdm_out: endpoint {
};
};
- itnoc@11200000 {
- compatible = "qcom,coresight-itnoc";
+ tn@11200000 {
+ compatible = "qcom,coresight-agtnoc";
reg = <0x0 0x11200000 0x0 0x3c00>;
clocks = <&aoss_qmp>;
- clock-names = "apb";
+ clock-names = "apb_pclk";
in-ports {
#address-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/5] arm64: dts: qcom: sm8750: fix traceNoC probe issue
From: Jie Gan @ 2026-06-30 10:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com>
The traceNoC node used the "qcom,coresight-tnoc", "arm,primecell"
compatible, which places the device on the AMBA bus. The AMBA peripheral
ID probing fails on this platform, so the device never probes.
Switch the node to the standalone "qcom,coresight-agtnoc" compatible.
Dropping "arm,primecell" makes the device probe through the platform
driver instead of the AMBA bus, which resolves the probe failure while
keeping it an Aggregator TNOC that retains ATID functionality.
Fixes: ebd1eb365cae ("arm64: qcom: dts: sm8750: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index fafed417c66f..d58483f9f93a 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -4687,7 +4687,7 @@ tpdm_rdpm_cmb2_out: endpoint {
};
tn@109ab000 {
- compatible = "qcom,coresight-tnoc", "arm,primecell";
+ compatible = "qcom,coresight-agtnoc";
reg = <0x0 0x109ab000 0x0 0x4200>;
clocks = <&aoss_qmp>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/5] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-30 10:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com>
The traceNoC node used the "qcom,coresight-tnoc", "arm,primecell"
compatible, which places the device on the AMBA bus. The AMBA peripheral
ID probing fails on this platform, so the device never probes.
Switch the node to the standalone "qcom,coresight-agtnoc" compatible.
Dropping "arm,primecell" makes the device probe through the platform
driver instead of the AMBA bus, which resolves the probe failure while
keeping it an Aggregator TNOC that retains ATID functionality.
Fixes: f73959d86c15 ("arm64: dts: qcom: kaanapali: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..e98f4aa4b141 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5004,7 +5004,7 @@ tpdm_pcie_rscc_out: endpoint {
};
tn@111b8000 {
- compatible = "qcom,coresight-tnoc", "arm,primecell";
+ compatible = "qcom,coresight-agtnoc";
reg = <0x0 0x111b8000 0x0 0x4200>;
clocks = <&aoss_qmp>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/5] coresight: tnoc: Add AG tnoc standalone compatible to the platform driver
From: Jie Gan @ 2026-06-30 10:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com>
The Aggregator TNOC can be described either as an AMBA device using the
"qcom,coresight-tnoc", "arm,primecell" compatible or as a standalone
platform device using the new "qcom,coresight-agtnoc" compatible. The
latter avoids the AMBA bus and the associated peripheral-ID probing.
Add "qcom,coresight-agtnoc" to the platform driver's match table so the
Aggregator TNOC can probe through the platform driver, and rename the
platform driver and its callbacks from the "itnoc"-specific names to
generic "tnoc" names, since the driver now serves both the Interconnect
and Aggregator TNOC. The platform driver name is updated to
"coresight-tnoc" accordingly.
Restrict the ATID-unsupported handling to the Interconnect TNOC. The
previous check disabled ATID for every non-AMBA device, which would
wrongly cover the standalone Aggregator TNOC. Only "qcom,coresight-itnoc"
lacks aggregation and ATID functionality, so key the check on that
compatible and let every other form allocate a trace ID.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tnoc.c | 35 ++++++++++++++--------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
index 9e8de4323d28..8237467faba7 100644
--- a/drivers/hwtracing/coresight/coresight-tnoc.c
+++ b/drivers/hwtracing/coresight/coresight-tnoc.c
@@ -130,7 +130,7 @@ static int trace_noc_init_default_data(struct trace_noc_drvdata *drvdata)
{
int atid;
- if (!dev_is_amba(drvdata->dev)) {
+ if (of_device_is_compatible(drvdata->dev->of_node, "qcom,coresight-itnoc")) {
drvdata->atid = -EOPNOTSUPP;
return 0;
}
@@ -278,7 +278,7 @@ static struct amba_driver trace_noc_driver = {
.id_table = trace_noc_ids,
};
-static int itnoc_probe(struct platform_device *pdev)
+static int tnoc_platform_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int ret;
@@ -295,7 +295,7 @@ static int itnoc_probe(struct platform_device *pdev)
return ret;
}
-static void itnoc_remove(struct platform_device *pdev)
+static void tnoc_platform_remove(struct platform_device *pdev)
{
struct trace_noc_drvdata *drvdata = platform_get_drvdata(pdev);
@@ -304,7 +304,7 @@ static void itnoc_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM
-static int itnoc_runtime_suspend(struct device *dev)
+static int tnoc_runtime_suspend(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
@@ -313,7 +313,7 @@ static int itnoc_runtime_suspend(struct device *dev)
return 0;
}
-static int itnoc_runtime_resume(struct device *dev)
+static int tnoc_runtime_resume(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
@@ -321,35 +321,36 @@ static int itnoc_runtime_resume(struct device *dev)
}
#endif
-static const struct dev_pm_ops itnoc_dev_pm_ops = {
- SET_RUNTIME_PM_OPS(itnoc_runtime_suspend, itnoc_runtime_resume, NULL)
+static const struct dev_pm_ops tnoc_dev_pm_ops = {
+ SET_RUNTIME_PM_OPS(tnoc_runtime_suspend, tnoc_runtime_resume, NULL)
};
-static const struct of_device_id itnoc_of_match[] = {
+static const struct of_device_id tnoc_of_match[] = {
{ .compatible = "qcom,coresight-itnoc" },
+ { .compatible = "qcom,coresight-agtnoc" },
{}
};
-MODULE_DEVICE_TABLE(of, itnoc_of_match);
+MODULE_DEVICE_TABLE(of, tnoc_of_match);
-static struct platform_driver itnoc_driver = {
- .probe = itnoc_probe,
- .remove = itnoc_remove,
+static struct platform_driver tnoc_platform_driver = {
+ .probe = tnoc_platform_probe,
+ .remove = tnoc_platform_remove,
.driver = {
- .name = "coresight-itnoc",
- .of_match_table = itnoc_of_match,
+ .name = "coresight-tnoc",
+ .of_match_table = tnoc_of_match,
.suppress_bind_attrs = true,
- .pm = &itnoc_dev_pm_ops,
+ .pm = &tnoc_dev_pm_ops,
},
};
static int __init tnoc_init(void)
{
- return coresight_init_driver("tnoc", &trace_noc_driver, &itnoc_driver);
+ return coresight_init_driver("tnoc", &trace_noc_driver, &tnoc_platform_driver);
}
static void __exit tnoc_exit(void)
{
- coresight_remove_driver(&trace_noc_driver, &itnoc_driver);
+ coresight_remove_driver(&trace_noc_driver, &tnoc_platform_driver);
}
module_init(tnoc_init);
module_exit(tnoc_exit);
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Jie Gan @ 2026-06-30 10:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com>
The TNOC compatible previously only allowed the two-string AMBA form
"qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
AMBA bus.
Convert the compatible to a oneOf and add a standalone
"qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
standalone string carries no "arm,primecell" entry, so the device is
created on the platform bus instead of the AMBA bus.
Add "qcom,coresight-agtnoc" to the select block so the schema matches
nodes that use only the standalone compatible, and add an example node
demonstrating the standalone form.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
.../bindings/arm/qcom,coresight-tnoc.yaml | 39 ++++++++++++++++++++--
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
index ef648a15b806..7e6e4b17a6c1 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
@@ -29,6 +29,7 @@ select:
contains:
enum:
- qcom,coresight-tnoc
+ - qcom,coresight-agtnoc
required:
- compatible
@@ -37,9 +38,11 @@ properties:
pattern: "^tn(@[0-9a-f]+)$"
compatible:
- items:
- - const: qcom,coresight-tnoc
- - const: arm,primecell
+ oneOf:
+ - items:
+ - const: qcom,coresight-tnoc
+ - const: arm,primecell
+ - const: qcom,coresight-agtnoc
reg:
maxItems: 1
@@ -110,4 +113,34 @@ examples:
};
};
};
+
+ - |
+ tn@10980000 {
+ compatible = "qcom,coresight-agtnoc";
+ reg = <0x10980000 0x4200>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tn_ag_in_tpdm_mss: endpoint {
+ remote-endpoint = <&tpdm_mss_out_tn_ag>;
+ };
+ };
+ };
+
+ out-ports {
+ port {
+ tn_ag_out_funnel_in2: endpoint {
+ remote-endpoint = <&funnel_in2_in_tn_ag>;
+ };
+ };
+ };
+ };
...
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/5] Fix traceNoC probe issue on multiple QCOM platforms
From: Jie Gan @ 2026-06-30 10:36 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
The CoreSight TNOC (Trace Network-On-Chip) binding so far only allowed the
two-string AMBA form "qcom,coresight-tnoc", "arm,primecell". That form
forces the device onto the AMBA bus, where the driver must read the
peripheral ID from the device registers during probe. On several QCOM
platforms this AMBA peripheral-ID probing fails, so the traceNoC device
never probes and its trace path is unavailable.
This series introduces a standalone "qcom,coresight-agtnoc" compatible
that describes the Aggregator TNOC as a plain platform device. Without
"arm,primecell" the device is created on the platform bus and probes
through the platform driver, bypassing the AMBA peripheral-ID read while
remaining a fully functional Aggregator TNOC that allocates a system
trace ID (ATID).
The series is organized as: binding first, then the driver support for the
new compatible, followed by the per-platform DT fixes that switch the
affected nodes over to it.
- Patch 1 (dt-bindings) converts the compatible to a oneOf and adds the
standalone qcom,coresight-agtnoc form alongside the existing AMBA form,
updates the select block, and adds an example node.
- Patch 2 (driver) adds qcom,coresight-agtnoc to the platform driver's
match table and renames the itnoc-specific names to generic tnoc names,
since the platform driver now serves both the Interconnect and Aggregator
TNOC. It also restricts the ATID-unsupported handling to
qcom,coresight-itnoc only, so the standalone Aggregator TNOC is no longer
wrongly covered and correctly allocates a trace ID.
- Patches 3-4 (kaanapali, sm8750) switch the traceNoC nodes from the AMBA
form to the standalone qcom,coresight-agtnoc compatible, fixing the probe
failure on those platforms.
- Patch 5 (glymur) switches the node from qcom,coresight-itnoc to
qcom,coresight-agtnoc. This node is actually an Aggregator TNOC (its
tn_ag_* endpoints show aggregation), so it should expose a system trace
ID rather than being treated as an Interconnect TNOC.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v3:
- add standalone compatible for AG traceNoC device, allow it to be
probed with platform driver.
- add fix patches for sm8750 and Glymur platforms
- Link to v2: https://lore.kernel.org/r/20260624-fix-tracenoc-probe-issue-v2-0-786520f62f21@oss.qualcomm.com
Changes in v2:
- address the ATID issue reported by Sashiko.
- update binding to accept arm,primecell-periphid property.
- Link to v1: https://lore.kernel.org/r/20260624-fix-tracenoc-probe-issue-v1-1-bcc785198fc5@oss.qualcomm.com
---
Jie Gan (5):
dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
coresight: tnoc: Add AG tnoc standalone compatible to the platform driver
arm64: dts: qcom: kaanapali: fix traceNoC probe issue
arm64: dts: qcom: sm8750: fix traceNoC probe issue
arm64: dts: qcom: glymur: use Aggregator TNOC compatible
.../bindings/arm/qcom,coresight-tnoc.yaml | 39 ++++++++++++++++++++--
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 ++--
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
drivers/hwtracing/coresight/coresight-tnoc.c | 35 +++++++++----------
5 files changed, 59 insertions(+), 25 deletions(-)
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-fix-tracenoc-probe-issue-c6429da28df4
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ 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