* [PATCH v2 3/4] arm64: dts: ti: k3-am67a-beagley-ai: Add overlay for IMX219 on CSI0
From: Jai Luthra @ 2026-05-15 1:16 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Robert Nelson, Andrew Davis, Devarsh Thakkar, Tomi Valkeinen,
linux-arm-kernel, devicetree, linux-kernel, Jai Luthra
In-Reply-To: <20260515-beagley-cameras-v2-0-f6acb66c9995@ideasonboard.com>
RPi v2 Camera (IMX219) is an 8MP camera that can be used with BeagleY AI
through the 22-pin CSI-RX connectors. Add a DT overlay to enable use of
this camera sensor through the CSI0 connector.
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso | 121 +++++++++++++++++++++
2 files changed, 125 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5269c9619b65..68a82e161c20 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -152,6 +152,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai-csi0-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
@@ -245,6 +246,8 @@ k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
+k3-am67a-beagley-ai-csi0-imx219-dtbs := k3-am67a-beagley-ai.dtb \
+ k3-am67a-beagley-ai-csi0-imx219.dtbo
k3-am68-sk-base-board-csi2-dual-imx219-dtbs := k3-am68-sk-base-board.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-am68-sk-base-board-pcie1-ep-dtbs := k3-am68-sk-base-board.dtb \
@@ -318,6 +321,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am642-phyboard-electra-x27-gpio1-spi1-uart3.dtb \
k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
+ k3-am67a-beagley-ai-csi0-imx219.dtb \
k3-am68-phyboard-izar-lvds-ph128800t006.dtb \
k3-am68-phyboard-izar-peb-av-15.dtb \
k3-am68-sk-base-board-csi2-dual-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso
new file mode 100644
index 000000000000..998e178d8d1a
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * RPi Camera V2.1 on BeagleY AI CSI0 port
+ *
+ * Copyright (C) 2026 Ideas On Board Oy
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ clk_imx219_csi0: imx219-csi0-xclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
+ reg_2p8v_csi0: regulator-2p8v-csi0 {
+ compatible = "regulator-fixed";
+ regulator-name = "2P8V_CSI0";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ reg_1p8v_csi0: regulator-1p8v-csi0 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V_CSI0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+
+ reg_1p2v_csi0: regulator-1p2v-csi0 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P2V_CSI0";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-always-on;
+ };
+};
+
+&mcu_pmx0 {
+ cam0_reset_pins_default: cam0-default-reset-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x003c, PIN_OUTPUT, 7) /* (C1) MCU_MCAN1_TX.MCU_GPIO0_15 */
+ >;
+ };
+};
+
+&mcu_gpio0 {
+ status = "okay";
+};
+
+&main_i2c2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c2_pins_default>;
+ clock-frequency = <400000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx219_0: sensor@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+
+ clocks = <&clk_imx219_csi0>;
+
+ VANA-supply = <®_2p8v_csi0>;
+ VDIG-supply = <®_1p8v_csi0>;
+ VDDL-supply = <®_1p2v_csi0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam0_reset_pins_default>;
+
+ reset-gpios = <&mcu_gpio0 15 GPIO_ACTIVE_HIGH>;
+
+ port {
+ csi2_cam0: endpoint {
+ remote-endpoint = <&csi2rx0_in_sensor>;
+ link-frequencies = /bits/ 64 <456000000>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2rx0_in_sensor: endpoint {
+ remote-endpoint = <&csi2_cam0>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: ti: k3-am67a-beagley-ai: Add DSI0/CSI1 mux
From: Jai Luthra @ 2026-05-15 1:16 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Robert Nelson, Andrew Davis, Devarsh Thakkar, Tomi Valkeinen,
linux-arm-kernel, devicetree, linux-kernel, Jai Luthra
In-Reply-To: <20260515-beagley-cameras-v2-0-f6acb66c9995@ideasonboard.com>
The DSI0 connector is shared withe CSI1 and selectable via the TMUX646
switch present on the board. Model it using a gpio-mux so that camera
sensor or DSI panel overlays can override it.
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
index 06aac02a7668..041aee2cd5b1 100644
--- a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
@@ -146,6 +146,19 @@ led-1 {
default-state = "on";
};
};
+
+ dsi_csi_mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dsi_csi_mux_pins_default>;
+
+ mux-gpios = <&main_gpio0 2 GPIO_ACTIVE_HIGH>,
+ <&main_gpio0 1 GPIO_ACTIVE_HIGH>;
+
+ /* state = SEL + 2*OE : 0 = DSI0, 1 = CSI1, 2,3 = off */
+ idle-state = <2>;
+ };
};
&main_pmx0 {
@@ -199,6 +212,13 @@ J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
>;
};
+ dsi_csi_mux_pins_default: dsi-csi-mux-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0004, PIN_OUTPUT, 7) /* (L23) OSPI0_LBCLKO.GPIO0_1 */
+ J722S_IOPAD(0x0008, PIN_OUTPUT, 7) /* (L22) OSPI0_DQS.GPIO0_2 */
+ >;
+ };
+
rgmii1_pins_default: rgmii1-default-pins {
pinctrl-single,pins = <
J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/4] arm64: dts: ti: k3-am67a-beagley-ai: Add I2C2 pinctrl
From: Jai Luthra @ 2026-05-15 1:16 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Robert Nelson, Andrew Davis, Devarsh Thakkar, Tomi Valkeinen,
linux-arm-kernel, devicetree, linux-kernel, Jai Luthra
In-Reply-To: <20260515-beagley-cameras-v2-0-f6acb66c9995@ideasonboard.com>
I2C2 is used by camera sensor devices connected on the 22-pin CSI0
connector. Add the pin definition here so I2C2 may be enabled by the
camera sensor overlays.
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
index 5255e04b9ac7..06aac02a7668 100644
--- a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
@@ -157,6 +157,13 @@ J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
bootph-all;
};
+ main_i2c2_pins_default: main-i2c2-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x00b0, PIN_INPUT_PULLUP, 1) /* (P22) GPMC0_CSn2.I2C2_SCL */
+ J722S_IOPAD(0x00b4, PIN_INPUT_PULLUP, 1) /* (P23) GPMC0_CSn3.I2C2_SDA */
+ >;
+ };
+
main_uart0_pins_default: main-uart0-default-pins {
pinctrl-single,pins = <
J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (A22) UART0_RXD */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/4] arm64: dts: ti: BeagleY-AI camera overlays
From: Jai Luthra @ 2026-05-15 1:16 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Robert Nelson, Andrew Davis, Devarsh Thakkar, Tomi Valkeinen,
linux-arm-kernel, devicetree, linux-kernel, Jai Luthra
This series adds support for using RPi V2 camera module through the
22-pin CSI connectors present on BeagleY-AI.
The first two patches add support for I2C-2 (used by CSI0) and setup the
DSI0/CSI1 mux (used by CSI1) in the board devicetree.
Next two patches add two DT overlays, for CSI0 and CSI1 respectively.
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
Changes in v2:
- Use PIN_OUTPUT for the camera reset GPIO pins (I forgot to change the
sysconfig generated line).
- Link to v1: https://lore.kernel.org/r/20260514-beagley-cameras-v1-0-5c3500b5a436@ideasonboard.com
---
Jai Luthra (4):
arm64: dts: ti: k3-am67a-beagley-ai: Add I2C2 pinctrl
arm64: dts: ti: k3-am67a-beagley-ai: Add DSI0/CSI1 mux
arm64: dts: ti: k3-am67a-beagley-ai: Add overlay for IMX219 on CSI0
arm64: dts: ti: k3-am67a-beagley-ai: Add overlay for IMX219 on CSI1
arch/arm64/boot/dts/ti/Makefile | 8 ++
.../dts/ti/k3-am67a-beagley-ai-csi0-imx219.dtso | 121 +++++++++++++++++++++
.../dts/ti/k3-am67a-beagley-ai-csi1-imx219.dtso | 121 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 27 +++++
4 files changed, 277 insertions(+)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260514-beagley-cameras-21ce6a98a7f1
Best regards,
--
Jai Luthra <jai.luthra@ideasonboard.com>
^ permalink raw reply
* Re: [PATCH v5 0/7] perf libunwind multiple remote support
From: Arnaldo Carvalho de Melo @ 2026-05-15 0:28 UTC (permalink / raw)
To: Ian Rogers
Cc: adrian.hunter, dapeng1.mi, james.clark, namhyung,
Florian Fainelli, Li Guan, 9erthalion6, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, howardchu95, john.g.garry, jolsa,
leo.yan, libunwind-devel, linux-arm-kernel, linux-kernel,
linux-perf-users, linux-riscv, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will
In-Reply-To: <agZiS2-fY49MjsY6@x1>
On Thu, May 14, 2026 at 09:01:18PM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, May 14, 2026 at 09:51:09AM -0700, Ian Rogers wrote:
> > On Wed, May 13, 2026 at 4:32 PM Ian Rogers <irogers@google.com> wrote:
> > > Fix the libunwind build for when libdw and libunwind are feature
> > > detected, currently failing with a duplicate symbol.
> > >
> > > Refactor the libunwind support so that whenever a remote target is
> > > available, perf functions using the ELF machine can use that remote
> > > target regardless of what the host/local machine is. Migrate existing
> > > libunwind supported architectures like powerpc, arm64 and loongarch so
> > > that they can work in a cross-architecture way. Add support for
> > > RISC-V. Make the code more regular in function names, etc. and avoid
> > > including a C-file. This increases the lines of code. It is similar in
> > > style to the unwind-libdw implementation. It is hoped that the more
> > > uniform nature of the code will help with refactoring the perf
> > > registers for SIMD/APX support.
> > >
> > > Aside from local host testing these patches are under tested, in part
> > > as I'm failing to see how to build libunwind with support for multiple
> > > remote targets. Please could I get help in testing.
> >
> > So the patches failed to apply in Sashiko:
> > https://sashiko.dev/#/patchset/20260513233151.572332-1-irogers%40google.com
> > The baseline logs show perf-tools-next was at commit 8c8f20936143
> > ("perf build: Remove NO_GTK2 build test") which is 6 patches
> > out-of-date compared to the current tip these patches are against. I
> > ran Sashiko locally, so I don't expect a huge amount from the reviews.
> > Currently Sashiko is catching up with a backlog because its tokens
> > have a lower priority and there was high load earlier in the week.
> > Anyway, I could repost the patches for Sashiko review but given the
> > backlog I think that would just create noise at the moment. Hopefully
> > I can get human review so we can move forward with merging these
> > improvements.
>
> Trying to apply it now, will also run sashiko locally.
Its in perf-tools-next tmp.perf-tools-next,
Running build tests now and will let sashiko running locally, probably
will push out tomorrow morning if nothing major is reported.
To make progress I think we can go on addressing some Sashiko reviews
with followup series otherwise it drags for a long time.
- Arnaldo
^ permalink raw reply
* Re: [PATCH net-next] Documentation: networking: devlink: stmmac: fix typo in phc_coarse_adj
From: patchwork-bot+netdevbpf @ 2026-05-15 0:20 UTC (permalink / raw)
To: Avinash Duduskar
Cc: netdev, davem, kuba, pabeni, edumazet, horms, corbet, jiri,
mcoquelin.stm32, alexandre.torgue, linux-doc, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260512133214.1773502-1-avinash.duduskar@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 12 May 2026 19:02:14 +0530 you wrote:
> "Functionnal" should be "Functional".
>
> Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com>
> ---
> Documentation/networking/devlink/stmmac.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with links:
- [net-next] Documentation: networking: devlink: stmmac: fix typo in phc_coarse_adj
https://git.kernel.org/netdev/net-next/c/e54fe8200a1c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 14/21] objtool: Prevent kCFI hashes from being decoded as instructions
From: sashiko-bot @ 2026-05-15 0:16 UTC (permalink / raw)
To: x86
Cc: Will Deacon, Mark Rutland, Catalin Marinas, linux-arm-kernel,
live-patching, Petr Mladek, linux-kernel, Peter Zijlstra,
Miroslav Benes, Song Liu, Joe Lawrence
In-Reply-To: <b1d50c9fc9e6b9bca43833cc4ccbd88a31fed84b.1778642120.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Build failure due to undeclared mapping symbol functions.
- [Low] Unused header inclusion.
--
commit 4ad78a24a64cd6a2d10b9a2f9c0d306fba3e6d19
Author: Josh Poimboeuf <jpoimboe@kernel.org>
objtool: Prevent kCFI hashes from being decoded as instructions
On arm64 with CONFIG_CFI=y, Clang places a 4-byte kCFI type hash immediately
before each address-taken function entry. This commit uses mapping symbols
to mark such data as NOP in text sections to prevent objtool from decoding
them.
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index e05dc7a93dc1e..2b03a2d6fc952 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -25,6 +25,7 @@
> #include <linux/kernel.h>
> #include <linux/static_call_types.h>
> #include <linux/string.h>
> +#include <linux/kconfig.h>
This isn't a bug, but is this include needed? It doesn't appear that any
Kconfig configuration macros are being used in the modified code.
[ ... ]
> @@ -478,6 +483,16 @@ static int decode_instructions(struct objtool_file *file)
>
> prev_len = insn->len;
>
> + /* Use mapping symbols to skip data in text sections */
> + sec_for_each_sym_from(sec, map_sym) {
> + if (map_sym->offset > offset)
> + break;
> + if (is_mapping_sym(map_sym))
> + is_data = is_data_mapping_sym(map_sym);
Could this cause a build failure across architectures here? It appears
is_mapping_sym() and is_data_mapping_sym() are neither declared nor defined
anywhere in the codebase at this point in the patch series.
If these functions are only introduced in a subsequent commit, applying
this patch independently might result in an implicit declaration of function
error, breaking git bisectability.
> + }
> + if (is_data)
> + insn->type = INSN_NOP;
> +
> /*
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=14
^ permalink raw reply
* Re: [PATCH v5 1/7] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
From: Arnaldo Carvalho de Melo @ 2026-05-15 0:12 UTC (permalink / raw)
To: Ian Rogers
Cc: adrian.hunter, dapeng1.mi, james.clark, namhyung,
Florian Fainelli, Li Guan, 9erthalion6, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, howardchu95, john.g.garry, jolsa,
leo.yan, libunwind-devel, linux-arm-kernel, linux-kernel,
linux-perf-users, linux-riscv, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will
In-Reply-To: <20260513233151.572332-2-irogers@google.com>
On Wed, May 13, 2026 at 04:31:45PM -0700, Ian Rogers wrote:
> Currently, both libdw and libunwind define 'unwind__get_entries'. This
> causes a duplicate symbol build failure when both are compiled into
> perf.
>
> This commit refactors the DWARF unwind post-processing to be
> configurable at runtime via the .perfconfig file option
> 'unwind.style', or using the argument '--unwind-style' in the commands
> 'perf report', 'perf script' and 'perf inject', in a similar manner to
> the addr2line or the disassembler style.
>
> The file 'tools/perf/util/unwind.c' adds the top-level dispatch
> function 'unwind__get_entries'. The backend implementations are
> renamed to 'libdw__get_entries' and 'libunwind__get_entries'. Both are
> attempted as fallbacks if not configured, or if the primary backend
> fails.
>
> Fixes: 2e9191573a69 ("perf build: Remove NO_LIBDW_DWARF_UNWIND option")
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/builtin-inject.c | 4 +
> tools/perf/builtin-report.c | 4 +
> tools/perf/builtin-script.c | 4 +
> tools/perf/util/Build | 1 +
> tools/perf/util/config.c | 4 +
> tools/perf/util/symbol_conf.h | 10 +++
> tools/perf/util/unwind-libdw.c | 18 +++-
> tools/perf/util/unwind-libunwind-local.c | 27 ++++--
> tools/perf/util/unwind-libunwind.c | 2 +-
> tools/perf/util/unwind.c | 104 +++++++++++++++++++++++
> tools/perf/util/unwind.h | 61 ++++++++-----
> 11 files changed, 207 insertions(+), 32 deletions(-)
> create mode 100644 tools/perf/util/unwind.c
>
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 6ab20df358c4..a2493f1097df 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -26,6 +26,7 @@
> #include "util/synthetic-events.h"
> #include "util/thread.h"
> #include "util/namespaces.h"
> +#include "util/unwind.h"
> #include "util/util.h"
> #include "util/tsc.h"
>
> @@ -2563,6 +2564,9 @@ int cmd_inject(int argc, const char **argv)
> OPT_STRING(0, "guestmount", &symbol_conf.guestmount, "directory",
> "guest mount directory under which every guest os"
> " instance has a subdir"),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_BOOLEAN(0, "convert-callchain", &inject.convert_callchain,
> "Generate callchains using DWARF and drop register/stack data"),
> OPT_END()
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 95c0bdba6b11..0b0966d94128 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -48,6 +48,7 @@
> #include "util/time-utils.h"
> #include "util/auxtrace.h"
> #include "util/units.h"
> +#include "util/unwind.h"
> #include "util/util.h" // perf_tip()
> #include "ui/ui.h"
> #include "ui/progress.h"
> @@ -1449,6 +1450,9 @@ int cmd_report(int argc, const char **argv)
> OPT_CALLBACK(0, "addr2line-style", NULL, "addr2line style",
> "addr2line styles (libdw,llvm,libbfd,addr2line)",
> report_parse_addr2line_config),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
> "Symbol demangling. Enabled by default, use --no-demangle to disable."),
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index c8ac9f01a36b..fd0b4609516b 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -63,6 +63,7 @@
> #include <linux/err.h>
> #include "util/dlfilter.h"
> #include "util/record.h"
> +#include "util/unwind.h"
> #include "util/util.h"
> #include "util/cgroup.h"
> #include "util/annotate.h"
> @@ -4159,6 +4160,9 @@ int cmd_script(int argc, const char **argv)
> "Enable symbol demangling"),
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> "Enable kernel symbol demangling"),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_STRING(0, "addr2line", &symbol_conf.addr2line_path, "path",
> "addr2line binary to use for line numbers"),
> OPT_STRING(0, "time", &script.time_str, "str",
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index 70cc91d00804..01edfccebb88 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -216,6 +216,7 @@ ifndef CONFIG_SETNS
> perf-util-y += setns.o
> endif
>
> +perf-util-y += unwind.o
> perf-util-$(CONFIG_LIBDW) += probe-finder.o
> perf-util-$(CONFIG_LIBDW) += dwarf-aux.o
> perf-util-$(CONFIG_LIBDW) += dwarf-regs.o
> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
> index 087002fb1b9b..7988149dc7ed 100644
> --- a/tools/perf/util/config.c
> +++ b/tools/perf/util/config.c
> @@ -23,6 +23,7 @@
> #include "build-id.h"
> #include "debug.h"
> #include "config.h"
> +#include "unwind.h"
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <stdlib.h>
> @@ -525,6 +526,9 @@ int perf_default_config(const char *var, const char *value,
> if (strstarts(var, "addr2line."))
> return addr2line_configure(var, value, dummy);
>
> + if (strstarts(var, "unwind."))
> + return unwind__configure(var, value, dummy);
> +
> /* Add other config variables here. */
> return 0;
> }
> diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
> index 6cd454d7c98e..0dee5aa6a534 100644
> --- a/tools/perf/util/symbol_conf.h
> +++ b/tools/perf/util/symbol_conf.h
> @@ -9,6 +9,15 @@
> struct strlist;
> struct intlist;
>
> +enum unwind_style {
> + UNWIND_STYLE_UNKNOWN = 0,
> + UNWIND_STYLE_LIBDW,
> + UNWIND_STYLE_LIBUNWIND,
> +};
> +
> +#define MAX_UNWIND_STYLE (UNWIND_STYLE_LIBUNWIND + 1)
> +
> +
> enum a2l_style {
> A2L_STYLE_UNKNOWN = 0,
> A2L_STYLE_LIBDW,
> @@ -81,6 +90,7 @@ struct symbol_conf {
> const char *addr2line_path;
> enum a2l_style addr2line_style[MAX_A2L_STYLE];
> int addr2line_timeout_ms;
> + enum unwind_style unwind_style[MAX_UNWIND_STYLE];
> unsigned long time_quantum;
> struct strlist *dso_list,
> *comm_list,
> diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c
> index 05e8e68bd49c..21171a6a878c 100644
> --- a/tools/perf/util/unwind-libdw.c
> +++ b/tools/perf/util/unwind-libdw.c
> @@ -339,7 +339,7 @@ frame_callback(Dwfl_Frame *state, void *arg)
> DWARF_CB_ABORT : DWARF_CB_OK;
> }
>
> -int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> +int libdw__get_entries(unwind_entry_cb_t cb, void *arg,
> struct thread *thread,
> struct perf_sample *data,
> int max_stack,
> @@ -356,7 +356,7 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> int err = -EINVAL, i;
>
> if (!data->user_regs || !data->user_regs->regs)
> - return -EINVAL;
> + return 0;
>
> ui = zalloc(sizeof(*ui) + sizeof(ui->entries[0]) * max_stack);
> if (!ui)
> @@ -430,6 +430,18 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> map_symbol__exit(&ui->entries[i].ms);
>
> dwfl_ui_ti->ui = NULL;
> + int entries = (int)ui->idx;
Moved this 'entries' variable to the stgart of the function to address
this on fedora 44:
CC /tmp/build/perf-tools-next/util/bpf-event.o
CC /tmp/build/perf-tools-next/util/pfm.o
util/unwind-libdw.c: In function ‘libdw__get_entries’:
util/unwind-libdw.c:433:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
433 | int entries = (int)ui->idx;
| ^~~
cc1: all warnings being treated as errors
make[4]: *** [/home/acme/git/perf-tools-next/tools/build/Makefile.build:95: /tmp/build/perf-tools-next/util/unwind-libdw.o] Error 1
- Arnaldo
> free(ui);
> - return 0;
> + /*
> + * Unwinder return contract:
> + * > 0 : unwinding succeeded (stops fallback). If we found frames but hit an error
> + * (e.g. truncated stack), report success to preserve existing frames.
> + * 0 : unwinding failed without yielding frames. Ignore non-fatal errors
> + * (e.g. missing debug info, DWARF corruption) to allow fallback unwinder or
> + * kernel callchain resolution to proceed.
> + * < 0 : fatal error (e.g. -ENOMEM). Aborts unwinding entirely.
> + */
> + if (err)
> + return (err == -ENOMEM) ? -ENOMEM : (entries > 0 ? 1 : 0);
> + return entries;
> }
> diff --git a/tools/perf/util/unwind-libunwind-local.c b/tools/perf/util/unwind-libunwind-local.c
> index 87d496e9dfa6..27e2f7b31789 100644
> --- a/tools/perf/util/unwind-libunwind-local.c
> +++ b/tools/perf/util/unwind-libunwind-local.c
> @@ -744,7 +744,7 @@ static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
> ret = perf_reg_value(&val, perf_sample__user_regs(ui->sample),
> perf_arch_reg_ip(e_machine));
> if (ret)
> - return ret;
> + return 0;
>
> ips[i++] = (unw_word_t) val;
>
> @@ -757,7 +757,7 @@ static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
> addr_space = maps__addr_space(thread__maps(ui->thread));
>
> if (addr_space == NULL)
> - return -1;
> + return 0;
>
> ret = unw_init_remote(&c, addr_space, ui);
> if (ret && !ui->best_effort)
> @@ -785,15 +785,30 @@ static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
> /*
> * Display what we got based on the order setup.
> */
> + int entries = 0;
> for (i = 0; i < max_stack && !ret; i++) {
> int j = i;
>
> if (callchain_param.order == ORDER_CALLER)
> j = max_stack - i - 1;
> - ret = ips[j] ? entry(ips[j], ui->thread, cb, arg) : 0;
> + if (ips[j]) {
> + ret = entry(ips[j], ui->thread, cb, arg);
> + if (ret)
> + break;
> + entries++;
> + }
> }
>
> - return ret;
> + /*
> + * Unwinder return contract:
> + * > 0 : unwinding succeeded (stops fallback).
> + * 0 : unwinding failed without yielding frames. Ignore non-fatal errors
> + * (e.g. stepping failure) to allow fallback unwinder or kernel callchains.
> + * < 0 : fatal error (e.g. -ENOMEM). Aborts unwinding entirely.
> + */
> + if (ret == -ENOMEM)
> + return -ENOMEM;
> + return (entries > 0 || ret == 0) ? entries : 0;
> }
>
> static int _unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> @@ -809,10 +824,10 @@ static int _unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> };
>
> if (!data->user_regs || !data->user_regs->regs)
> - return -EINVAL;
> + return 0;
>
> if (max_stack <= 0)
> - return -EINVAL;
> + return 0;
>
> return get_entries(&ui, cb, arg, max_stack);
> }
> diff --git a/tools/perf/util/unwind-libunwind.c b/tools/perf/util/unwind-libunwind.c
> index cb8be6acfb6f..a0016b897dae 100644
> --- a/tools/perf/util/unwind-libunwind.c
> +++ b/tools/perf/util/unwind-libunwind.c
> @@ -79,7 +79,7 @@ void unwind__finish_access(struct maps *maps)
> ops->finish_access(maps);
> }
>
> -int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> +int libunwind__get_entries(unwind_entry_cb_t cb, void *arg,
> struct thread *thread,
> struct perf_sample *data, int max_stack,
> bool best_effort)
> diff --git a/tools/perf/util/unwind.c b/tools/perf/util/unwind.c
> new file mode 100644
> index 000000000000..4ed4b1d55c69
> --- /dev/null
> +++ b/tools/perf/util/unwind.c
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "debug.h"
> +#include "symbol_conf.h"
> +#include "unwind.h"
> +#include <linux/string.h>
> +#include <string.h>
> +#include <stdlib.h>
> +
> +int unwind__get_entries(unwind_entry_cb_t cb __maybe_unused, void *arg __maybe_unused,
> + struct thread *thread __maybe_unused,
> + struct perf_sample *data __maybe_unused,
> + int max_stack __maybe_unused,
> + bool best_effort __maybe_unused)
> +{
> + int ret = 0;
> +
> +#if defined(HAVE_LIBDW_SUPPORT) || defined(HAVE_LIBUNWIND_SUPPORT)
> + if (symbol_conf.unwind_style[0] == UNWIND_STYLE_UNKNOWN) {
> + int i = 0;
> +#ifdef HAVE_LIBDW_SUPPORT
> + symbol_conf.unwind_style[i++] = UNWIND_STYLE_LIBDW;
> +#endif
> +#ifdef HAVE_LIBUNWIND_SUPPORT
> + symbol_conf.unwind_style[i++] = UNWIND_STYLE_LIBUNWIND;
> +#endif
> + }
> +#endif //defined(HAVE_LIBDW_SUPPORT) || defined(HAVE_LIBUNWIND_SUPPORT)
> +
> + for (size_t i = 0; i < ARRAY_SIZE(symbol_conf.unwind_style); i++) {
> + switch (symbol_conf.unwind_style[i]) {
> + case UNWIND_STYLE_LIBDW:
> + ret = libdw__get_entries(cb, arg, thread, data, max_stack, best_effort);
> + break;
> + case UNWIND_STYLE_LIBUNWIND:
> + ret = libunwind__get_entries(cb, arg, thread, data, max_stack, best_effort);
> + break;
> + case UNWIND_STYLE_UNKNOWN:
> + default:
> +#if !defined(HAVE_LIBDW_SUPPORT) && !defined(HAVE_LIBUNWIND_SUPPORT)
> + pr_warning_once(
> + "Error: dwarf unwinding not supported, build perf with libdw or libunwind.\n");
> +#endif
> + ret = 0;
> + break;
> + }
> + if (ret > 0) {
> + ret = 0;
> + break;
> + }
> + if (ret < 0)
> + break;
> + }
> + return ret;
> +}
> +
> +int unwind__configure(const char *var, const char *value, void *cb __maybe_unused)
> +{
> + static const char * const unwind_style_names[] = {
> + [UNWIND_STYLE_LIBDW] = "libdw",
> + [UNWIND_STYLE_LIBUNWIND] = "libunwind",
> + NULL
> + };
> + char *s, *p, *saveptr;
> + size_t i = 0;
> +
> + if (strcmp(var, "unwind.style"))
> + return 0;
> +
> + if (!value)
> + return -1;
> +
> + s = strdup(value);
> + if (!s)
> + return -1;
> +
> + memset(symbol_conf.unwind_style, 0, sizeof(symbol_conf.unwind_style));
> +
> + p = strtok_r(s, ",", &saveptr);
> + while (p && i < ARRAY_SIZE(symbol_conf.unwind_style)) {
> + bool found = false;
> + char *q = strim(p);
> +
> + for (size_t j = UNWIND_STYLE_LIBDW; j < MAX_UNWIND_STYLE; j++) {
> + if (!strcasecmp(q, unwind_style_names[j])) {
> + symbol_conf.unwind_style[i++] = j;
> + found = true;
> + break;
> + }
> + }
> + if (!found)
> + pr_warning("Unknown unwind style: %s\n", q);
> + p = strtok_r(NULL, ",", &saveptr);
> + }
> +
> + free(s);
> + return 0;
> +}
> +
> +int unwind__option(const struct option *opt __maybe_unused,
> + const char *arg,
> + int unset __maybe_unused)
> +{
> + return unwind__configure("unwind.style", arg, NULL);
> +}
> diff --git a/tools/perf/util/unwind.h b/tools/perf/util/unwind.h
> index 9f7164c6d9aa..28db3e3b9b51 100644
> --- a/tools/perf/util/unwind.h
> +++ b/tools/perf/util/unwind.h
> @@ -4,9 +4,10 @@
>
> #include <linux/compiler.h>
> #include <linux/types.h>
> -#include "util/map_symbol.h"
> +#include "map_symbol.h"
>
> struct maps;
> +struct option;
> struct perf_sample;
> struct thread;
>
> @@ -26,7 +27,9 @@ struct unwind_libunwind_ops {
> struct perf_sample *data, int max_stack, bool best_effort);
> };
>
> -#ifdef HAVE_DWARF_UNWIND_SUPPORT
> +int unwind__configure(const char *var, const char *value, void *cb);
> +int unwind__option(const struct option *opt, const char *arg, int unset);
> +
> /*
> * When best_effort is set, don't report errors and fail silently. This could
> * be expanded in the future to be more permissive about things other than
> @@ -36,8 +39,31 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> struct thread *thread,
> struct perf_sample *data, int max_stack,
> bool best_effort);
> -/* libunwind specific */
> +
> +#ifdef HAVE_LIBDW_SUPPORT
> +int libdw__get_entries(unwind_entry_cb_t cb, void *arg,
> + struct thread *thread,
> + struct perf_sample *data, int max_stack,
> + bool best_effort);
> +#else
> +#include "debug.h"
> +static inline int libdw__get_entries(unwind_entry_cb_t cb __maybe_unused, void *arg __maybe_unused,
> + struct thread *thread __maybe_unused,
> + struct perf_sample *data __maybe_unused,
> + int max_stack __maybe_unused,
> + bool best_effort __maybe_unused)
> +{
> + pr_err("Error: libdw dwarf unwinding not built into perf\n");
> + return 0;
> +}
> +#endif
> +
> #ifdef HAVE_LIBUNWIND_SUPPORT
> +/* libunwind specific */
> +int libunwind__get_entries(unwind_entry_cb_t cb, void *arg,
> + struct thread *thread,
> + struct perf_sample *data, int max_stack,
> + bool best_effort);
> #ifndef LIBUNWIND__ARCH_REG_ID
> #define LIBUNWIND__ARCH_REG_ID(regnum) libunwind__arch_reg_id(regnum)
> #endif
> @@ -47,25 +73,15 @@ int unwind__prepare_access(struct maps *maps, struct map *map, bool *initialized
> void unwind__flush_access(struct maps *maps);
> void unwind__finish_access(struct maps *maps);
> #else
> -static inline int unwind__prepare_access(struct maps *maps __maybe_unused,
> - struct map *map __maybe_unused,
> - bool *initialized __maybe_unused)
> -{
> - return 0;
> -}
> -
> -static inline void unwind__flush_access(struct maps *maps __maybe_unused) {}
> -static inline void unwind__finish_access(struct maps *maps __maybe_unused) {}
> -#endif
> -#else
> -static inline int
> -unwind__get_entries(unwind_entry_cb_t cb __maybe_unused,
> - void *arg __maybe_unused,
> - struct thread *thread __maybe_unused,
> - struct perf_sample *data __maybe_unused,
> - int max_stack __maybe_unused,
> - bool best_effort __maybe_unused)
> +#include "debug.h"
> +static inline int libunwind__get_entries(unwind_entry_cb_t cb __maybe_unused,
> + void *arg __maybe_unused,
> + struct thread *thread __maybe_unused,
> + struct perf_sample *data __maybe_unused,
> + int max_stack __maybe_unused,
> + bool best_effort __maybe_unused)
> {
> + pr_err("Error: libunwind dwarf unwinding not built into perf\n");
> return 0;
> }
>
> @@ -78,5 +94,6 @@ static inline int unwind__prepare_access(struct maps *maps __maybe_unused,
>
> static inline void unwind__flush_access(struct maps *maps __maybe_unused) {}
> static inline void unwind__finish_access(struct maps *maps __maybe_unused) {}
> -#endif /* HAVE_DWARF_UNWIND_SUPPORT */
> +#endif
> +
> #endif /* __UNWIND_H */
> --
> 2.54.0.563.g4f69b47b94-goog
>
^ permalink raw reply
* Re: [PATCH v5 0/7] perf libunwind multiple remote support
From: Arnaldo Carvalho de Melo @ 2026-05-15 0:01 UTC (permalink / raw)
To: Ian Rogers
Cc: adrian.hunter, dapeng1.mi, james.clark, namhyung,
Florian Fainelli, Li Guan, 9erthalion6, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, howardchu95, john.g.garry, jolsa,
leo.yan, libunwind-devel, linux-arm-kernel, linux-kernel,
linux-perf-users, linux-riscv, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will
In-Reply-To: <CAP-5=fW6S1XzZvq=kWj6ma=O1UCDrVV3ZNbzK0fMS_ho6e1qVg@mail.gmail.com>
On Thu, May 14, 2026 at 09:51:09AM -0700, Ian Rogers wrote:
> On Wed, May 13, 2026 at 4:32 PM Ian Rogers <irogers@google.com> wrote:
> > Fix the libunwind build for when libdw and libunwind are feature
> > detected, currently failing with a duplicate symbol.
> >
> > Refactor the libunwind support so that whenever a remote target is
> > available, perf functions using the ELF machine can use that remote
> > target regardless of what the host/local machine is. Migrate existing
> > libunwind supported architectures like powerpc, arm64 and loongarch so
> > that they can work in a cross-architecture way. Add support for
> > RISC-V. Make the code more regular in function names, etc. and avoid
> > including a C-file. This increases the lines of code. It is similar in
> > style to the unwind-libdw implementation. It is hoped that the more
> > uniform nature of the code will help with refactoring the perf
> > registers for SIMD/APX support.
> >
> > Aside from local host testing these patches are under tested, in part
> > as I'm failing to see how to build libunwind with support for multiple
> > remote targets. Please could I get help in testing.
>
> So the patches failed to apply in Sashiko:
> https://sashiko.dev/#/patchset/20260513233151.572332-1-irogers%40google.com
> The baseline logs show perf-tools-next was at commit 8c8f20936143
> ("perf build: Remove NO_GTK2 build test") which is 6 patches
> out-of-date compared to the current tip these patches are against. I
> ran Sashiko locally, so I don't expect a huge amount from the reviews.
> Currently Sashiko is catching up with a backlog because its tokens
> have a lower priority and there was high load earlier in the week.
> Anyway, I could repost the patches for Sashiko review but given the
> backlog I think that would just create noise at the moment. Hopefully
> I can get human review so we can move forward with merging these
> improvements.
Trying to apply it now, will also run sashiko locally.
- Arnaldo
^ permalink raw reply
* Re: [PATCH v2] perf record: Refactor ARM64 leaf caller setup out of arch
From: Arnaldo Carvalho de Melo @ 2026-05-14 23:49 UTC (permalink / raw)
To: Ian Rogers
Cc: james.clark, namhyung, adrian.hunter, alexander.shishkin,
dapeng1.mi, john.g.garry, jolsa, leo.yan, linux-arm-kernel,
linux-kernel, linux-perf-users, mark.rutland, mike.leach, mingo,
peterz, shimin.guo, will
In-Reply-To: <CAP-5=fU7Y5b2KERuYJuKBK0nqD6GAo_r_QhxesbVw6T3bqrgQQ@mail.gmail.com>
On Thu, May 14, 2026 at 10:38:07AM -0700, Ian Rogers wrote:
> On Mon, May 11, 2026 at 10:41 PM Ian Rogers <irogers@google.com> wrote:
> >
> > Code in tools/perf/arch causes portability issues/opaqueness and LTO
> > issues due to the use of weak symbols. Move the adding of LR to the
> > sample_user_regs into arm64-frame-pointer-unwind-support.c conditional
> > on EM_HOST == EM_AARCH64 (false on all non-ARM64 builds). This also
> > better encapsulates the use of the sampled registers by
> > get_leaf_frame_caller_aarch64 and the set up by the new
> > add_leaf_frame_caller_opts_aarch64, exposing opportunities for
> > possibly sampling PC and SP to help the unwinder.
> >
> > Reviewed-by: James Clark <james.clark@linaro.org>
> > Signed-off-by: Ian Rogers <irogers@google.com>
>
> Ping.
Thanks, applied to perf-tools-next, for v7.2.
- Arnaldo
^ permalink raw reply
* Re: [PATCH] ARM: Do not select HAVE_RUST when KASAN is enabled
From: Miguel Ojeda @ 2026-05-14 23:24 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Christian Schrrefl,
linux-arm-kernel, linux-kernel, rust-for-linux, stable
In-Reply-To: <20260511-arm-avoid-rust-with-kasan-v1-1-24d55f4a900b@kernel.org>
On Mon, May 11, 2026 at 10:02 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> When KASAN is enabled, such as with allmodconfig, the build fails when
> building the Rust code with:
>
> error: kernel-address sanitizer is not supported for this target
>
> error: aborting due to 1 previous error
>
> make[4]: *** [rust/Makefile:654: rust/core.o] Error 1
>
> The arm-unknown-linux-gnueabi target does not support KASAN, so avoid
> saying Rust is supported when it is enabled.
>
> Cc: stable@vger.kernel.org
> Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7")
> Link: https://github.com/Rust-for-Linux/linux/issues/1234
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Applied to `rust-fixes` -- thanks everyone!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v3 12/21] objtool: Refactor elf_add_data() to use a growable data buffer
From: sashiko-bot @ 2026-05-14 23:13 UTC (permalink / raw)
To: x86
Cc: linux-arm-kernel, live-patching, Will Deacon, Peter Zijlstra,
linux-kernel, Catalin Marinas, Joe Lawrence, Song Liu,
Mark Rutland, Petr Mladek, Miroslav Benes
In-Reply-To: <a0fe2363d017a2833e98ae50de797fe55c2796a4.1778642120.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] An integer overflow in `elf_add_data()` due to an uncontrolled `sh_addralign` value allows an out-of-bounds heap write.
- [Low] In `elf_add_data`, a failed `calloc` for the new data buffer overwrites `sec->data->d_buf` with NULL and leaks the original buffer.
--
commit 02f18d399bba6e3d751363b4e85f507e3f288e34
Author: Josh Poimboeuf <jpoimboe@kernel.org>
objtool: Refactor elf_add_data() to use a growable data buffer
Instead of calling elf_newdata() for each new piece of data with its own
separate buffer, keep it all in the same growable buffer so the
section's entire data can be accessed if needed.
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
[ ... ]
> @@ -1409,30 +1406,55 @@ void *elf_add_data(struct elf *elf, struct section *sec, const void *data, size_
> return NULL;
> }
>
> - sec->data = elf_newdata(s);
> if (!sec->data) {
[ ... ]
> + sec->data->d_align = sec->sh.sh_addralign;
> }
>
> - sec->data->d_buf = calloc(1, size);
> - if (!sec->data->d_buf) {
> - ERROR_GLIBC("calloc");
> - return NULL;
> + size_old = sec->data->d_size;
> + offset = ALIGN(size_old, sec->sh.sh_addralign);
> + size_new = offset + size;
Could this ALIGN calculation overflow if a malformed ELF file provides an
extremely large sh_addralign value?
If offset wraps around, it seems size_new might also wrap, potentially causing
roundup_pow_of_two to return a small allocation size. Could this lead to an
out-of-bounds write during the subsequent memcpy further down in this function?
> - if (data)
> - memcpy(sec->data->d_buf, data, size);
> + if (!sec->data_overallocated)
> + alloc_size_old = size_old;
> + else
> + alloc_size_old = max(64UL, roundup_pow_of_two(size_old ? : 1));
>
> - sec->data->d_size = size;
> - sec->data->d_align = sec->sh.sh_addralign;
> + alloc_size_new = max(64UL, roundup_pow_of_two(size_new ? : 1));
>
> - offset = ALIGN(sec_size(sec), sec->sh.sh_addralign);
> - sec->sh.sh_size = offset + size;
> + if (alloc_size_new > alloc_size_old) {
> + void *orig_buf = sec->data->d_buf;
> +
> + sec->data->d_buf = calloc(1, alloc_size_new);
> + if (!sec->data->d_buf) {
> + ERROR_GLIBC("calloc");
> + return NULL;
> + }
If calloc fails here, does assigning its result directly to sec->data->d_buf
clobber the valid pointer to orig_buf?
It appears orig_buf is never freed on this error path, which might leak the
original buffer if it was previously owned by objtool. Would it be safer to
keep the original buffer pointer intact on allocation failure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=12
^ permalink raw reply
* [PATCH] arm64: dts: ti: Add LincolnTech OLDI LCD-185 Overlay for AM625-BeaglePlay
From: Swamil Jain @ 2026-05-14 22:55 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, tomi.valkeinen
Cc: r-sharma3, devarsht, praneeth, linux-arm-kernel, devicetree,
linux-kernel, s-jain1
From: Aradhya Bhatia <a-bhatia1@ti.com>
The panel is Lincoln Technology Solutions LCD185-101CT[0]. It is a
Dual-Link LVDS panel and supports WUXGA resolution (1920x1200).
Furthermore, it has an i2c based touch controller: Goodix-GT928.
Add DT overlay for the OLDI panel to connect with BeaglePlay platform.
[0]: https://lincolntechsolutions.com/wp-content/uploads/2024/09/LCD185-101CTL1ARNTT_DS_R1.3.pdf
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
...5-beagleplay-lincolntech-lcd185-panel.dtso | 148 ++++++++++++++++++
.../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 14 ++
3 files changed, 166 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-beagleplay-lincolntech-lcd185-panel.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 7642c06ca834..f0436a102fce 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -12,6 +12,7 @@
dtb-$(CONFIG_ARCH_K3) += k3-am625-beagleplay.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-beagleplay-csi2-ov5640.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-beagleplay-csi2-tevi-ov5640.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am625-beagleplay-lincolntech-lcd185-panel.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-phyboard-lyra-rdk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-tqma62xx-mba62xx.dtb
@@ -177,6 +178,8 @@ k3-am625-beagleplay-csi2-ov5640-dtbs := k3-am625-beagleplay.dtb \
k3-am625-beagleplay-csi2-ov5640.dtbo
k3-am625-beagleplay-csi2-tevi-ov5640-dtbs := k3-am625-beagleplay.dtb \
k3-am625-beagleplay-csi2-tevi-ov5640.dtbo
+k3-am625-beagleplay-lincolntech-lcd185-panel-dtbs := k3-am625-beagleplay.dtb \
+ k3-am625-beagleplay-lincolntech-lcd185-panel.dtbo
k3-am625-phyboard-lyra-disable-eth-phy-dtbs := k3-am625-phyboard-lyra-rdk.dtb \
k3-am6xx-phycore-disable-eth-phy.dtbo
k3-am625-phyboard-lyra-disable-rtc-dtbs := k3-am625-phyboard-lyra-rdk.dtb \
@@ -287,6 +290,7 @@ k3-j784s4-evm-usxgmii-exp1-exp2-dtbs := k3-j784s4-evm.dtb \
k3-j784s4-evm-usxgmii-exp1-exp2.dtbo
dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
+ k3-am625-beagleplay-lincolntech-lcd185-panel.dtb \
k3-am625-phyboard-lyra-disable-eth-phy.dtb \
k3-am625-phyboard-lyra-disable-rtc.dtb \
k3-am625-phyboard-lyra-disable-spi-nor.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay-lincolntech-lcd185-panel.dtso b/arch/arm64/boot/dts/ti/k3-am625-beagleplay-lincolntech-lcd185-panel.dtso
new file mode 100644
index 000000000000..9ebfa9ab7a90
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay-lincolntech-lcd185-panel.dtso
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/**
+ * Lincoln tech Solutions OLDI panel (LCD185-101CT) and touch DT overlay for AM625-BeaglePlay
+ *
+ * AM625-BeaglePlay: https://www.beagleboard.org/boards/beagleplay
+ * Panel datasheet: https://lincolntechsolutions.com/wp-content/uploads/2024/09/LCD185-101CTL1ARNTT_DS_R1.3.pdf
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&backlight_pins_default>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ enable-gpios = <&main_gpio0 0 GPIO_ACTIVE_HIGH>;
+ pwms = <&epwm0 1 20000 0>;
+ };
+
+ lcd {
+ compatible = "lincolntech,lcd185-101ct";
+ backlight = <&backlight>;
+ /*
+ * Note that the OLDI TX 0 transmits the odd set of pixels
+ * while the OLDI TX 1 transmits the even set. This is a
+ * fixed configuration in the IP integration and is not
+ * changeable. The properties, "dual-lvds-odd-pixels" and
+ * "dual-lvds-even-pixels" have been used to merely
+ * identify if a Dual Link configuration is required.
+ * Swapping them will cause an error in the dss oldi driver.
+ */
+ power-supply = <&vsys_5v0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ lcd_in0: endpoint {
+ remote-endpoint = <&oldi_0_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ lcd_in1: endpoint {
+ remote-endpoint = <&oldi_1_out>;
+ };
+ };
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+&oldi0 {
+ status = "okay";
+ ti,companion-oldi = <&oldi1>;
+};
+
+&oldi1 {
+ status = "okay";
+ ti,secondary-oldi;
+ ti,companion-oldi = <&oldi0>;
+};
+
+&oldi0_port0 {
+ oldi_0_in: endpoint {
+ remote-endpoint = <&dpi0_out0>;
+ };
+};
+
+&oldi0_port1 {
+ oldi_0_out: endpoint {
+ remote-endpoint = <&lcd_in0>;
+ };
+};
+
+&oldi1_port0 {
+ oldi_1_in: endpoint {
+ remote-endpoint = <&dpi0_out1>;
+ };
+};
+
+&oldi1_port1 {
+ oldi_1_out: endpoint {
+ remote-endpoint = <&lcd_in1>;
+ };
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VP1: Output to OLDI */
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpi0_out0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&oldi_0_in>;
+ };
+ dpi0_out1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&oldi_1_in>;
+ };
+ };
+};
+
+&main_i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@57 {
+ compatible = "atmel,24c256";
+ reg = <0x57>;
+ };
+
+ touchscreen@5d {
+ compatible = "goodix,gt928";
+ reg = <0x5d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchscreen_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+ irq-gpios = <&main_gpio0 39 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
+ touchscreen-size-x = <1920>;
+ touchscreen-size-y = <1200>;
+ };
+};
+
+&epwm0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
index c468b9c5fc09..dc5b7f6217ad 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
@@ -510,6 +510,20 @@ AM62X_IOPAD(0x0074, PIN_OUTPUT, 1) /* (U25) GPMC0_AD14.VOUT0_DATA22 */
AM62X_IOPAD(0x0078, PIN_OUTPUT, 1) /* (U24) GPMC0_AD15.VOUT0_DATA23 */
>;
};
+
+ touchscreen_pins_default: touchscreen-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x01b4, PIN_OUTPUT, 7) /* (A13) SPI0_CS0.GPIO1_15 */
+ AM62X_IOPAD(0x00a0, PIN_INPUT, 7) /* (K25) GPMC0_WPn.GPIO0_39 */
+ >;
+ };
+
+ backlight_pins_default: bl-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0000, PIN_OUTPUT, 7) /* (H24) OSPI0_CLK.GPIO0_0 */
+ AM62X_IOPAD(0x01b8, PIN_OUTPUT, 2) /* (C13) SPI0_CS1.EHRPWM0_B */
+ >;
+ };
};
&mcu_pmx0 {
^ permalink raw reply related
* Re: [PATCH v3 10/21] objtool: Ignore jumps to the end of the function for checksum runs
From: sashiko-bot @ 2026-05-14 22:30 UTC (permalink / raw)
To: x86
Cc: Mark Rutland, live-patching, linux-arm-kernel, linux-kernel,
Miroslav Benes, Petr Mladek, Will Deacon, Song Liu,
Peter Zijlstra, Joe Lawrence, Catalin Marinas
In-Reply-To: <b3b58101e15e1bb5266e57134f0b65f7d8efdd4b.1778642120.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing parentheses in the jump destination check causes objtool to silently ignore all missing jump targets when branch validation is disabled, instead of only jumps to the end of the function.
--
commit aa068d4053e8b92ff17082c7a023821e72f5d625
Author: Josh Poimboeuf <jpoimboe@kernel.org>
objtool: Ignore jumps to the end of the function for checksum runs
Sometimes Clang arm64 code jumps to the end of the function for UB.
This commit ignores these jumps to the end of the function for
checksum runs to avoid errors.
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 10b18cf9c3608..73451aef68029 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
[ ... ]
> @@ -1593,10 +1609,14 @@ static int add_jump_destinations(struct objtool_file *file)
> /*
> * GCOV/KCOV dead code can jump to the end of
> * the function/section.
> + *
> + * Clang on arm64 also does this sometimes for
> + * undefined behavior.
> */
> - if (file->ignore_unreachables && func &&
> - dest_sec == insn->sec &&
> - dest_off == func->offset + func->len)
> + if (!validate_branch_enabled() ||
> + (file->ignore_unreachables && func &&
> + dest_sec == insn->sec &&
> + dest_off == func->offset + func->len))
> continue;
Does this condition silently ignore all missing jump targets when branch
validation is disabled?
Because of the || without proper parenthetical grouping around the first
two terms, if !validate_branch_enabled() is true (which it is for
--checksum or --noinstr runs), the rest of the condition short-circuits.
This appears to cause objtool to skip the error reporting and silently
leave the jump destination as NULL for any unresolvable jump in the binary,
instead of only those jumping to the end of the function.
Should the logic be grouped to restrict the exception to the end of the
function?
if ((!validate_branch_enabled() || file->ignore_unreachables) &&
func &&
dest_sec == insn->sec &&
dest_off == func->offset + func->len)
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=10
^ permalink raw reply
* Re: [PATCH v3 09/21] kbuild: Only run objtool if there is at least one command
From: sashiko-bot @ 2026-05-14 22:25 UTC (permalink / raw)
To: x86
Cc: Peter Zijlstra, Song Liu, Catalin Marinas, linux-arm-kernel,
linux-kernel, Joe Lawrence, Will Deacon, Miroslav Benes,
Petr Mladek, Nicolas Schier, live-patching, Nathan Chancellor,
Mark Rutland
In-Reply-To: <8699672b82fef17e73a5f2e5528478778dbdab31.1778642120.git.jpoimboe@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Leaking objtool options into vmlinux.o validation causes a fatal build failure (`--cfi requires --prefix`) and silently alters validation behavior.
--
commit 68e454f3a8ccd3d638c67c092eee264996286695
Author: Josh Poimboeuf <jpoimboe@kernel.org>
kbuild: Only run objtool if there is at least one command
This commit splits the objtool arguments into commands and options to
prevent objtool from running when no commands are enabled.
> diff --git a/scripts/Makefile.vmlinux_o b/scripts/Makefile.vmlinux_o
> index 527352c222ff6..09af33203bd8d 100644
> --- a/scripts/Makefile.vmlinux_o
> +++ b/scripts/Makefile.vmlinux_o
[ ... ]
> @@ -36,18 +36,13 @@ endif
> # For !delay-objtool + CONFIG_NOINSTR_VALIDATION, it runs on both translation
> # units and vmlinux.o, with the latter only used for noinstr/unret validation.
>
> -objtool-enabled := $(or $(delay-objtool),$(CONFIG_NOINSTR_VALIDATION))
> -
> -ifeq ($(delay-objtool),y)
> -vmlinux-objtool-args-y += $(objtool-args-y)
> -else
> -vmlinux-objtool-args-$(CONFIG_OBJTOOL_WERROR) += --werror
> +ifneq ($(delay-objtool),y)
> +objtool-cmds-y =
> +objtool-opts-y += --link
Does this code unintentionally retain the options from scripts/Makefile.lib?
Since objtool-cmds-y is cleared here, commands like --prefix are dropped.
However, because objtool-opts-y is only appended to, options like --cfi
remain active.
This causes objtool to fail with a fatal error: "--cfi requires --prefix"
during vmlinux.o validation on configurations with KCFI.
Should objtool-opts-y be assigned directly using = or := instead of
appended?
> endif
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778642120.git.jpoimboe@kernel.org?part=9
^ permalink raw reply
* [PATCH net-next v2 1/3] net: macb: flush PCIe posted write after TSTART doorbell (PCIe-only)
From: Lukasz Raczylo @ 2026-05-14 21:54 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20260514215459.36109-1-lukasz@raczylo.com>
macb_start_xmit() and macb_tx_restart() kick transmission by
OR-ing MACB_BIT(TSTART) into NCR. On PCIe-attached macb
instances (BCM2712 + RP1 PCIe south bridge on Raspberry Pi 5 is
the case I have in front of me), writes to NCR are posted PCIe
writes: they are not guaranteed to reach the device before the
issuing CPU returns. If the TSTART doorbell does not reach the
MAC, no TX begins, no TCOMP completion arrives, and the ring
remains quiescent without any kernel-visible indication.
Add a read-back of NCR after each TSTART write. The read is an
architected PCIe read barrier for earlier posted writes on the
same path; it ensures the doorbell has reached the MAC before
the function returns. As a side effect on macb_start_xmit() it
also flushes the preceding macb_tx_lpi_wake() NCR write -- not
just TSTART -- since the barrier applies to all prior posted
writes by the same requester.
The cost is one non-posted PCIe read per TSTART. To avoid
imposing this on SoC-integrated macb variants (Atmel, Microchip,
SiFive, Xilinx), where NCR is on-chip MMIO and no fabric
posted-write concern exists, gate the readback behind a new
MACB_CAPS_PCIE_POSTED_WRITES capability set only on
raspberrypi_rp1_config.
Note that the raspberrypi/linux vendor fork carries a local
patch around the TSTART site (a queue->tx_pending breadcrumb
that is promoted to queue->txubr_pending by the next TCOMP
interrupt, triggering macb_tx_restart()). That workaround makes
the loss recoverable under traffic, but it cannot help if TCOMP
itself is not raised because no TX started -- which is exactly
the case targeted here. The handshake is not present in
mainline.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb.h | 4 ++++
drivers/net/ethernet/cadence/macb_main.c | 15 +++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 2de56017e..ce9037f9e 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -791,6 +791,10 @@
#define MACB_CAPS_USRIO_HAS_MII BIT(26)
#define MACB_CAPS_USRIO_HAS_REFCLK_SOURCE BIT(27)
#define MACB_CAPS_USRIO_HAS_TSUCLK_SOURCE BIT(28)
+/* Register writes are posted on the parent fabric and need a non-posted
+ * read-back to guarantee delivery. Currently set only on RP1.
+ */
+#define MACB_CAPS_PCIE_POSTED_WRITES BIT(29)
/* LSO settings */
#define MACB_LSO_UFO_ENABLE 0x01
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a12aa2124..6879f3458 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1922,6 +1922,14 @@ static void macb_tx_restart(struct macb_queue *queue)
spin_lock(&bp->lock);
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
+ /*
+ * On PCIe-attached parts, flush the posted-write queue so the
+ * TSTART doorbell reliably reaches the MAC. Without this the
+ * write can sit in the fabric and the MAC never advances,
+ * causing a silent TX stall.
+ */
+ if (bp->caps & MACB_CAPS_PCIE_POSTED_WRITES)
+ (void)macb_readl(bp, NCR);
spin_unlock(&bp->lock);
out_tx_ptr_unlock:
@@ -2560,6 +2568,12 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock(&bp->lock);
macb_tx_lpi_wake(bp);
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
+ /*
+ * Flush PCIe posted-write queue; see comment in macb_tx_restart().
+ * Also flushes the preceding macb_tx_lpi_wake() NCR write.
+ */
+ if (bp->caps & MACB_CAPS_PCIE_POSTED_WRITES)
+ (void)macb_readl(bp, NCR);
spin_unlock(&bp->lock);
if (CIRC_SPACE(queue->tx_head, queue->tx_tail, bp->tx_ring_size) < 1)
@@ -5674,6 +5688,7 @@ static const struct macb_config raspberrypi_rp1_config = {
.caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_CLK_HW_CHG |
MACB_CAPS_JUMBO |
MACB_CAPS_GEM_HAS_PTP |
+ MACB_CAPS_PCIE_POSTED_WRITES |
MACB_CAPS_EEE |
MACB_CAPS_USRIO_HAS_MII,
.dma_burst_length = 16,
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v2 0/3] net: macb: candidate fixes for silent TX stall on BCM2712/RP1
From: Lukasz Raczylo @ 2026-05-14 21:54 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
Hi netdev, Théo, Andrea, linux-rpi,
v2 of the silent TX stall series. The v1 RFC sits at:
https://lore.kernel.org/netdev/cover.1777064117.git.lukasz@raczylo.com/T/
Reframing first. The v1 cover claimed "zero events post-patch";
that was true at the user-space watchdog visibility level only.
A dmesg sweep prompted by Andrea's review -- with patch 3's warn
made unconditional, per his ask -- revealed kernel-level evidence
that patches 1 and 2 are partial at best. Patch 3 is empirically
the load-bearing fix on this platform: it caught and recovered a
real lost-TCOMP stall on pi-data-02 at 2026-05-05T13:24:09Z
(queue 0, tail=259564431 head=259564433 after ~260M TX, HW
ETHS tx_frames counter advancing through the event while driver
tx_tail did not) without user-space involvement.
So the v2 narrative reads:
* Patch 1 (PCIe posted-write flush) and patch 2 (PCIe read
barrier before descriptor check) close two specific
candidate races in the TSTART / TX_USED paths. Plausible
and well-motivated, but I cannot prove either fires in
isolation on this hardware -- my 1 Hz trace shows TX
freezes, not which mechanism caused them.
* Patch 3 (TX stall watchdog) is the safety net that
empirically does the recovery work. 13 days of production
runtime on 24 nodes since 2026-05-02 in the same form
(anchored against the rpi-6.18.y vendor fork, in
raspberrypi/linux#7340 -- merged 2026-05-08 after review
feedback from pelwell that this v2 incorporates).
The v1 cover's "zero stalls in 95 node-hours of post-patch
uptime" framing was misleading. Apologies for that.
## What changed in v2
Patch 1 (PCIe posted-write flush after TSTART doorbell):
* Gates the readback behind a new MACB_CAPS_PCIE_POSTED_WRITES
capability, set only on raspberrypi_rp1_config. v1
applied the readback to every macb variant; SoC-integrated
parts (Atmel, Microchip, SiFive, Xilinx) have no posted-write
fabric and were paying the readback latency for no benefit.
* Commit message notes that the readback also flushes the
preceding macb_tx_lpi_wake() NCR write on the same path --
not just TSTART -- since it functions as a PCIe read barrier
for all prior posted writes by the same requester.
Patch 2 (PCIe read barrier before TX completion descriptor check):
* Dropped the ISR read. v1 read ISR in macb_tx_poll() with
`queue_readl(queue, ISR) & MACB_BIT(TCOMP)`; that's
destructive on RP1 silicon (MACB_CAPS_ISR_CLEAR_ON_WRITE
is not set on raspberrypi_rp1_config; the existing handler
assumes read-clear semantics and processes every bit
returned from queue_readl(queue, ISR) in one pass). v1's
masked-and-discarded read silently consumed any other bit
set in ISR at that instant -- RCOMP being the worst case
(RX completion never scheduled until the line re-asserts).
* v2 substitutes `(void)queue_readl(queue, IMR)` -- IMR is
the read-only interrupt mask mirror, no side effects, still
flushes prior peripheral DMA writes via PCIe completion
ordering. Loses the "directly sample latched TCOMP" half
of v1's claim; keeps the PCIe-barrier half, which is the
half that addresses the documented race in the existing
macb_tx_complete_pending() rmb() comment.
Patch 3 (TX stall watchdog):
* Tail movement is tracked via a `bool tx_stall_tail_moved`
set by macb_tx_complete() under tx_ptr_lock when tail
advances, and cleared by the watchdog tick on the same lock.
v1 snapshotted tx_tail and compared between ticks; while
that worked correctly given tx_tail is free-running u32,
the bool form is unambiguously cleaner, doesn't depend on
counter behaviour, and is what pelwell asked for when he
reviewed the same series on the rpi side
(raspberrypi/linux#7340).
* netif_carrier_ok() gate added at the top of the watchdog
tick. Eliminates the boot-time false positive seen in v1
where, between macb_open() and link-autoneg-completion,
queue->tx_head can advance from kernel-queued packets while
tx_tail stays at 0 (no TCOMPs yet), tripping the snapshot
check. Observed 6 such fires during a 2026-05-02 fleet
rolling reboot.
* netdev_warn_once -> netdev_warn_ratelimited. v1's
netdev_warn_once made operational accounting impossible
after the first fire on a given netdev; ratelimited keeps
bounded log noise but lets operators count events. Andrea
asked for this directly.
Patches 1 and 3 are independently revertable. Patch 2 v2 is a
two-line readback before an existing check; trivially revertable
in isolation, semantically dependent on the existing
macb_tx_complete_pending() recovery path that it strengthens.
## What I haven't done
* TSO+SG-off canary. rtheobald (cilium#43198 #4188846955)
and the launchpad #2133877 commenter (#34) both report
TSO+SG-off *together* mask the stall; my matrix has TSO+GSO
tested off, not TSO+SG. Happy to canary-test this on one
node if reviewers want the data point before deciding which
of patches 1/2 the SG path actually exercises.
* Per-patch isolation testing. All three deployed
simultaneously on the 24-node fleet; I cannot independently
prove patch 1 or patch 2 does anything on its own. Patch 3
has direct production evidence (lost-TCOMP recovery
described above). If reviewers want a bisection-style
canary I can stagger one-patch / two-patch / three-patch
nodes for >=1 week each.
## Status and testing
* Mainline-anchored: v2 builds clean against current net-next
HEAD, applies cleanly. Boot-tested and brief-sanity in a
canary build before this send.
* raspberrypi/linux rpi-6.18.y anchored equivalents: in
production on 24 nodes since 2026-05-02 (now 13 days); in
raspberrypi/linux master since 2026-05-08 (6 days).
* The v2 patch 2 IMR-barrier form was rolled to all 24 Pi
nodes earlier today (2026-05-14, ~14:00 UTC) as a
vendor-fork-anchored update. ~120 cumulative node-hours
of runtime since: zero mid-runtime TX stalls; zero user-space
watchdog RECOVER events. Cover-letter-thread reply with
detail accompanies this series.
The series does not depend on any other in-flight work. Happy
to split, rebase, drop, or restructure on feedback.
Lukasz Raczylo (3):
net: macb: flush PCIe posted write after TSTART doorbell (PCIe-only)
net: macb: insert PCIe read barrier before TX completion descriptor
check
net: macb: add TX stall watchdog to recover from lost TCOMP interrupts
drivers/net/ethernet/cadence/macb.h | 14 ++++
drivers/net/ethernet/cadence/macb_main.c | 95 ++++++++++++++++++++++++
2 files changed, 109 insertions(+)
--
2.54.0
^ permalink raw reply
* [PATCH net-next v2 2/3] net: macb: insert PCIe read barrier before TX completion descriptor check
From: Lukasz Raczylo @ 2026-05-14 21:54 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20260514215459.36109-1-lukasz@raczylo.com>
macb_tx_poll() runs with TCOMP masked, drains the TX ring, then
calls napi_complete_done() and re-enables TCOMP via IER. An
existing comment in the function notes that completions raised
while TCOMP is masked do not re-fire on IER re-enable, and
mitigates this by calling macb_tx_complete_pending(), which
inspects driver-visible ring state (descriptor->ctrl, after
rmb()) and reschedules NAPI if a completion is observable in
memory.
On PCIe-attached parts (BCM2712 + RP1 PCIe south bridge on
Raspberry Pi 5 is the case I have in front of me), the
descriptor DMA write that sets TX_USED may not have retired to
system memory at the point macb_tx_complete_pending() runs. The
rmb() synchronises the CPU view of earlier CPU writes; it is
not sufficient to retire an in-flight peripheral DMA write.
Under that ordering the in-memory descriptor can still read
TX_USED=0 when the hardware has in fact completed the frame;
the check returns false; NAPI exits; the quirk above prevents
the re-enabled IER from re-firing; the ring goes quiescent.
Add a side-effect-free MMIO read between the IER write and the
macb_tx_complete_pending() check. The read functions as an
architected PCIe read barrier for earlier peripheral-originated
DMA writes on the same path, so any in-flight TX_USED update
retires to system memory before the descriptor read.
The register chosen is IMR (the read-only interrupt mask
mirror); reading it has no side effects on either read-clear or
W1C ISR silicon (it is not the ISR), and the read still flushes
prior DMA writes via the PCIe completion-ordering guarantee.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb_main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 6879f3458..f7fa9e7ad 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1984,6 +1984,14 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
* actions if an interrupt is raised just after enabling them,
* but this should be harmless.
*/
+ /*
+ * PCIe read barrier: flush any in-flight peripheral DMA
+ * writes (descriptor TX_USED updates) so the subsequent
+ * macb_tx_complete_pending() check observes them. IMR is
+ * the read-only interrupt mask mirror; the read has no
+ * side effects on either read-clear or W1C ISR silicon.
+ */
+ (void)queue_readl(queue, IMR);
if (macb_tx_complete_pending(queue)) {
queue_writel(queue, IDR, MACB_BIT(TCOMP));
macb_queue_isr_clear(bp, queue, MACB_BIT(TCOMP));
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v2 3/3] net: macb: add TX stall watchdog to recover from lost TCOMP interrupts
From: Lukasz Raczylo @ 2026-05-14 21:54 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20260514215459.36109-1-lukasz@raczylo.com>
On PCIe-attached macb instances (BCM2712 + RP1 PCIe south bridge
on Raspberry Pi 5 is the case I have in front of me), a TCOMP
interrupt can be lost: the TSTART doorbell can be lost in the
posted-write fabric (addressed by an earlier patch), or the
descriptor TX_USED DMA write can be observed late by the driver
(also addressed earlier). When that happens the TX ring stalls
silently until something else kicks TSTART.
Add a per-queue delayed_work that runs once per second. It
detects forward progress on the TX completion path via a per-queue
bool tx_stall_tail_moved that macb_tx_complete() sets when tx_tail
advances and the watchdog clears on each tick. If the ring is
non-empty (queue->tx_head != queue->tx_tail) and the flag is
unset when the tick runs, the watchdog calls the existing
macb_tx_restart() to re-assert TSTART.
The bool form (rather than a tx_tail snapshot) sidesteps any
concern about ring-index aliasing between ticks and is the form
suggested by Phil Elwell when reviewing the same series anchored
against rpi-6.18.y at raspberrypi/linux#7340 (merged 2026-05-08).
No new recovery logic is introduced. macb_tx_restart() already
exists in this file, is correctly locked (tx_ptr_lock, bp->lock),
and verifies that the hardware's TBQP is behind the driver's head
index before re-asserting TSTART. On a healthy ring it is a
no-op at the hardware level.
Cost on a healthy queue: one spin_lock_irqsave / spin_unlock and
two field assignments per tick. The delayed_work is only
scheduled between macb_open() and macb_close() and is cancelled
synchronously on close.
A netif_carrier_ok() gate at the top of the tick skips the stall
check when there is no carrier (no completion is possible without
a link), eliminating a boot-time false positive where queue->tx_head
can advance from kernel-queued packets between macb_open() and link
autoneg completion, while tx_tail stays unchanged because no TCOMPs
have arrived yet.
netdev_warn_ratelimited() is used rather than netdev_warn_once() so
operators can count occurrences across the lifetime of the netdev.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Link: https://github.com/raspberrypi/linux/pull/7340
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb.h | 10 ++++
drivers/net/ethernet/cadence/macb_main.c | 72 ++++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index ce9037f9e..75df0f75b 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -1282,6 +1282,16 @@ struct macb_queue {
dma_addr_t tx_ring_dma;
struct work_struct tx_error_task;
bool txubr_pending;
+
+ /* TX stall watchdog -- see macb_tx_stall_watchdog() in macb_main.c.
+ * tx_stall_tail_moved is set by macb_tx_complete() when tx_tail
+ * advances and cleared by the watchdog tick on each pass (both
+ * under tx_ptr_lock). Using a bool sidesteps any ring-index
+ * aliasing concern between ticks.
+ */
+ struct delayed_work tx_stall_watchdog_work;
+ bool tx_stall_tail_moved;
+
struct napi_struct napi_tx;
dma_addr_t rx_ring_dma;
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index f7fa9e7ad..8245c69e1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1473,6 +1473,8 @@ static int macb_tx_complete(struct macb_queue *queue, int budget)
packets, bytes);
queue->tx_tail = tail;
+ if (packets)
+ queue->tx_stall_tail_moved = true;
if (__netif_subqueue_stopped(bp->dev, queue_index) &&
CIRC_CNT(queue->tx_head, queue->tx_tail,
bp->tx_ring_size) <= MACB_TX_WAKEUP_THRESH(bp))
@@ -2003,6 +2005,70 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
return work_done;
}
+#define MACB_TX_STALL_INTERVAL_MS 1000
+
+/*
+ * TX stall watchdog.
+ *
+ * Recovers from lost TCOMP interrupts on PCIe-attached macb
+ * instances. macb already has a recovery chain
+ * (txubr_pending -> macb_tx_restart()) that fires on TCOMP; if
+ * TCOMP itself is lost the TX ring stalls silently until something
+ * else kicks TSTART. This watchdog runs once per second per queue
+ * and calls macb_tx_restart() if the ring is non-empty and
+ * tx_tail has not advanced since the previous tick.
+ *
+ * Movement is tracked via the tx_stall_tail_moved boolean rather
+ * than a tx_tail snapshot, sidestepping any ring-index aliasing
+ * concern. The bool is set by macb_tx_complete() when tx_tail
+ * advances and cleared here on each tick; both writes are under
+ * tx_ptr_lock so no atomic is required.
+ *
+ * macb_tx_restart() already checks the hardware's TBQP against
+ * the driver's head index before re-asserting TSTART, so on a
+ * healthy ring this is a no-op at the hardware level. The
+ * watchdog only supplies the missing trigger.
+ */
+static void macb_tx_stall_watchdog(struct work_struct *work)
+{
+ struct macb_queue *queue = container_of(to_delayed_work(work),
+ struct macb_queue,
+ tx_stall_watchdog_work);
+ struct macb *bp = queue->bp;
+ unsigned int cur_tail, cur_head;
+ bool stalled = false;
+ unsigned long flags;
+
+ if (!netif_running(bp->dev))
+ return;
+
+ /* No carrier => no completion is possible. Skip the check
+ * but keep the watchdog ticking for when carrier comes up.
+ */
+ if (!netif_carrier_ok(bp->dev))
+ goto reschedule;
+
+ spin_lock_irqsave(&queue->tx_ptr_lock, flags);
+ cur_tail = queue->tx_tail;
+ cur_head = queue->tx_head;
+ if (cur_head != cur_tail && !queue->tx_stall_tail_moved)
+ stalled = true;
+ queue->tx_stall_tail_moved = false;
+ spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
+
+ if (stalled) {
+ netdev_warn_ratelimited(bp->dev,
+ "TX stall detected on queue %u (tail=%u head=%u); re-kicking TSTART\n",
+ (unsigned int)(queue - bp->queues),
+ cur_tail, cur_head);
+ macb_tx_restart(queue);
+ }
+
+reschedule:
+ schedule_delayed_work(&queue->tx_stall_watchdog_work,
+ msecs_to_jiffies(MACB_TX_STALL_INTERVAL_MS));
+}
+
static void macb_hresp_error_task(struct work_struct *work)
{
struct macb *bp = from_work(bp, work, hresp_err_bh_work);
@@ -3192,6 +3258,9 @@ static int macb_open(struct net_device *dev)
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
napi_enable(&queue->napi_rx);
napi_enable(&queue->napi_tx);
+ queue->tx_stall_tail_moved = true;
+ schedule_delayed_work(&queue->tx_stall_watchdog_work,
+ msecs_to_jiffies(MACB_TX_STALL_INTERVAL_MS));
}
macb_init_hw(bp);
@@ -3242,6 +3311,7 @@ static int macb_close(struct net_device *dev)
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
napi_disable(&queue->napi_rx);
napi_disable(&queue->napi_tx);
+ cancel_delayed_work_sync(&queue->tx_stall_watchdog_work);
netdev_tx_reset_queue(netdev_get_tx_queue(dev, q));
}
@@ -4804,6 +4874,8 @@ static int macb_init_dflt(struct platform_device *pdev)
}
INIT_WORK(&queue->tx_error_task, macb_tx_error_task);
+ INIT_DELAYED_WORK(&queue->tx_stall_watchdog_work,
+ macb_tx_stall_watchdog);
q++;
}
--
2.54.0
^ permalink raw reply related
* Re: [RFC PATCH net-next 0/3] net: macb: candidate fixes for silent TX stall on BCM2712/RP1
From: Lukasz Raczylo @ 2026-05-14 21:51 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
Andrea, Théo --
Thanks both. Replying to multiple points in one mail since they
intersect.
First a correction to the v1 cover: the "zero events post-patch"
claim was true only at the user-space watchdog visibility level.
With patch 3's warn made unconditional (which is what Andrea's
review re-tested with on v6.19.10), kernel-level evidence on my
side now matches what Andrea saw -- patches 1 and 2 are partial,
patch 3 is empirically the load-bearing fix on this platform.
The v2 cover acknowledges this and reframes.
## Andrea -- patches 1 and 3
Concrete data from a dmesg sweep across the 24-node fleet
(macb-v2 image, 2026-05-02 to 2026-05-05, 6.18.24 + this series
with netdev_warn_once swapped to netdev_warn):
* 1 mid-runtime real stall, pi-data-02 2026-05-05T13:24:09Z,
queue 0, tail=259564431 head=259564433 (2 stuck descriptors
after ~260M TX). HW ETHS tx_frames counter advanced through
the event (~1535 fps mid-stall); driver tx_tail did not.
Patch 3 watchdog re-kicked TSTART; user-space watchdog
logged zero RECOVER events for that window -- kernel-level
recovery completed before user-space noticed. Consistent
with the lost-TCOMP pattern.
* 6 boot-time false positives during the 2026-05-02 rolling
reboot, all tail=0 head=5-7. Patch 3 v1 has a real bug:
tx_stall_last_tail is initialised to tx_tail (=0) at
macb_open(), first tick fires at +1000 ms; if autoneg
hasn't completed by then, tail is still 0 from no-TCOMPs
while head moves from kernel-queued packets, false stall
fires. v2 fixes this (details below).
## Théo -- the four questions on the cover
Welcome to macb maintenance. Quick answers; raw 1 Hz traces,
dmesg dumps, and event logs available on request for any of
these.
1. Tx-only or Tx+Rx broken?
Tx-only at the MAC counter level. Per-node 1 Hz trace
captures the same signature on every wedge:
/sys/class/net/end0/statistics/tx_packets freezes at a
single second, rx_packets continues to grow, MAC IRQ
counter (on the assigned CPU) continues to advance,
NET_RX softirq counter continues to advance. The
"broken Tx & Rx" reports (lexfrei et al on cilium#43198)
are the user-space symptom: TX dead -> TCP can't ACK ->
nothing comes back -> looks bidirectionally dead from
applications. At the MAC counters the asymmetry is
unambiguous.
2. Recovery: link down/up vs module reload vs power cycle?
On any system that's still otherwise responsive, link
down/up suffices and is the lightest known recovery. My
user-space watchdog has run that primitive on 24 nodes
for ~3 weeks; ~6-10 s wedge-to-Ready, every time.
`modprobe -r macb && modprobe macb` (rtheobald) is a
heavier-weight equivalent of the same thing -- works but
unnecessary if link-toggle alone fixes the silicon state.
"Power cycle only" (lexfrei) was on Ubuntu raspi 6.17 with
the ondemand governor + frequent RCU stalls preceding the
wedge (per launchpad bug body's "KEY OBSERVATION" section);
my read is that case escalated past clean NIC freeze into
kernel-wide unresponsiveness, so a NIC-level recovery
couldn't reach it.
3. TSO / SG / EEE disabling helped some reporters?
Mixed picture, with one gap in my matrix.
Tested fleet-wide since 2026-04-24 as baseline before this
series:
* EEE off (--set-eee end0 eee off + advertise 0x0)
* TSO off (-K tso off)
* GSO off (-K gso off)
* RX/TX rings 4096/2048 (default 512)
* IRQ affinity moved off CPU0 to CPU3
* CPU governor schedutil (default) -- earlier tested
performance, no change
* qdisc fq -> pfifo_fast
With all of those, the stall still fires. Pre-patch
fleet rate was multiple per hour with these knobs already
applied.
Untested by me: TSO + SG (scatter-gather, NETIF_F_SG) off
*together*. That is the specific combination rtheobald
(cilium#43198 comment 4188846955) and the launchpad
commenter (#34) report as masking the stall -- "must be
both, not just one". I tested TSO + GSO, not TSO + SG.
Both patch 1 (PCIe-fabric race on TSTART) and patch 2
(peripheral DMA retirement race on TX_USED) are
consistent with descriptor-fragment-path interactions
that SG-off would mask, so the workaround being real
isn't surprising. Closing the race rather than masking
it should still be the right thing for mainline. Happy
to canary-test TSO+SG-off on one node if you want the
data point before v2 review.
4. cdns,*-max-pipe DT props -- lead dead?
Yes, dead, per the commenter who pursued it (launchpad
#2133877 comment #30, April 2026): they patched mainline
6.18.18 to add the device_property_read calls for
cdns,ar2r-max-pipe / cdns,aw2w-max-pipe / cdns,use-aw2b-fill
*and* added those properties to bcm2712-rpi-5-b.dts; ran
a few hours; their own follow-up: "this is a dud" -- node
hung anyway.
For reference, my build (raspberrypi/linux rpi-6.18.y @
f2f68e79f16f) has the driver-side reads present but the
DTS does not set the properties, so the AMP register
defaults are in effect on my fleet and the bug still
fires. Two independent confirmations the DT props are
not the fix.
## My own audit -- two issues v2 fixes
Worth disclosing before someone else catches them.
* Patch 2 (v1) reads ISR in macb_tx_poll(), masks off
everything except TCOMP, and discards the rest.
raspberrypi_rp1_config does not set
MACB_CAPS_ISR_CLEAR_ON_WRITE -- the driver assumes
read-clear ISR semantics on RP1, and macb_interrupt()
relies on processing every bit it reads in one pass for
that case to be correct. My v1 patch breaks that contract:
any RCOMP / ROVR / TXUBR / etc. set in ISR at the moment of
my read is silently consumed and never processed. RCOMP
being lost is the worst case (RX completion never scheduled
until something else asserts the line). Race window is
~200-500 ns per macb_tx_poll completion; significant at
moderate-to-heavy RX load on a level-triggered IRQ where
the consumed bit drops the line before GIC delivery.
v2 patch 2 drops the ISR read entirely and substitutes
(void)queue_readl(queue, IMR). IMR is the read-only mask
mirror, no side effects, still flushes prior peripheral
DMA writes via PCIe ordering. Loses the "directly sample
latched TCOMP" half of v1's claim; keeps the PCIe-barrier
half (which is the half that actually addresses the
documented race in the existing macb_tx_complete_pending()
rmb() comment).
* Patch 3 (v1) boot-time false positive described above to
Andrea. v2 fixes:
- netif_carrier_ok() gate -- no carrier, no completion is
possible, don't fire.
- tracks tail movement via a bool tx_stall_tail_moved set
by macb_tx_complete() under tx_ptr_lock when tail
advances, cleared by the watchdog tick on the same
lock. Form suggested by pelwell when he reviewed the
same series anchored against rpi-6.18.y at
raspberrypi/linux#7340 (merged 2026-05-08); 13 days of
fleet runtime in this form since 2026-05-02 across 24
nodes. Folded into mainline v2 patch 3 directly rather
than carried as a fix-up.
- netdev_warn_once -> netdev_warn_ratelimited per
Andrea's ask -- operator visibility doesn't disappear
after the first fire.
## v2 follows
Sending [PATCH net-next v2 0/3] threaded under the v1 cover
shortly. Plan to drop "RFC" from the subject prefix (~3 weeks
production runtime + the rpi in-tree merge tip the balance
toward a regular PATCH); happy to revert to RFC if you'd
prefer the iterative-review cadence.
Tested-on context for v2:
* mainline-anchored: builds clean against current net-next
HEAD, applies cleanly. Boot-tested in a canary build of
my Talos image before this reply.
* rpi-6.18.y-anchored equivalents: in production on 24 nodes
since 2026-05-02; in raspberrypi/linux master tip since
2026-05-08.
* The v2 patch 2 IMR-barrier form (the one that fixes the
destructive ISR-read regression described above) was rolled
to all 24 Pi nodes earlier today (2026-05-14, ~14:00 UTC) as
a vendor-fork-anchored update. ~120 cumulative node-hours
of runtime since: zero mid-runtime TX stalls; zero user-space
watchdog RECOVER events; the 5 dmesg "TX stall detected" lines
are all boot-time false positives of the form `tail=0 head=N`
that the new `netif_carrier_ok()` gate in patch 3 eliminates.
Pre-patch baseline rate (~0.5 stall/node-hour at fleet level)
would have predicted on the order of 60 mid-runtime stalls in
that window; observed is 0.
Thanks again to both for the review.
--
Lukasz Raczylo
^ permalink raw reply
* Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts
From: Alex Tran @ 2026-05-14 21:23 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Jyoti Bhayana, David Lechner, Nuno Sá, Andy Shevchenko,
Sudeep Holla, Cristian Marussi, Linus Walleij, Rafael J. Wysocki,
Philipp Zabel, Viresh Kumar, Guenter Roeck, linux-iio,
linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio, linux-pm,
linux-hwmon
In-Reply-To: <20260514164422.0eba9a61@jic23-huawei>
On 5/14/2026 8:44 AM, Jonathan Cameron wrote:
> On Wed, 13 May 2026 10:16:53 -0700
> Alex Tran <alex.tran@oss.qualcomm.com> wrote:
>
>> SCMI client drivers do not consistently log the number of supported
>> entities discovered from firmware. This information is useful during
>> debugging because it shows which domains or resources were exposed by
>> firmware during probe.
>>
>> Add logging of the number of supported entities to the SCMI cpufreq,
>> pinctrl, reset, hwmon, and powercap client drivers after a successful
>> probe. This aligns these drivers with the existing logging in the SCMI
>> power and performance domain drivers.
>>
>> Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
> Hi Alex,
>
> Just curious but why +CC linux-iio and IIO folk?
>
> May be you had a false suggestion to add them from get maintainers.
> If so be sure to check it's suggestions make sense!
>
> Not to worry - we can all hit the delete button ;)
>
> Jonathan
Hi Jonathan,
Originally, there was another patch in this series to add the same functionality to scmi_iio probe but it was dropped. Apparently running b4 prep --auto-to-cc does not prune stale entries from the cover letter. Will manually remove all entries and rerun the command in the future.
Alex
^ permalink raw reply
* [arm-platforms:timers/el2-vtimer 1/17] Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
From: kernel test robot @ 2026-05-14 20:10 UTC (permalink / raw)
To: Marc Zyngier; +Cc: oe-kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git timers/el2-vtimer
head: e793e78f4ead18e3dfe5a3a1be912a7ec5bc55d8
commit: c58180850debdd9b2306a86238860769137f40cd [1/17] ACPI: GTDT: Account for GTDTv3 size when walking the platform timer descriptors
config: arm64-randconfig-002-20260514 (https://download.01.org/0day-ci/archive/20260515/202605150401.Pd0Z0ZjV-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260515/202605150401.Pd0Z0ZjV-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605150401.Pd0Z0ZjV-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
>> Warning: drivers/acpi/arm64/gtdt.c:35 struct member 'v3' not described in 'acpi_gtdt_descriptor'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: Always check register address validity
From: Andrey Skvortsov @ 2026-05-14 21:17 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Jernej Skrabec, Samuel Holland, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <CAGb2v64PvGdViT6DWHiNGoK=5L8DpfjVAdv+LbNf_Uisy6v0Aw@mail.gmail.com>
On 26-03-14 15:33, Chen-Yu Tsai wrote:
> On Sun, Mar 1, 2026 at 10:50 PM Andrey Skvortsov
> <andrej.skvortzov@gmail.com> wrote:
> >
> > From: Samuel Holland <samuel@sholland.org>
> >
> > The register address was already validated for read operations in
> > regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations
> > have the same set of possible addresses, and the address is being truncated
> > from u32 to u8 here as well, so the same check is needed.
> >
> > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
>
> Should probably have:
>
> Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced
> Serial Bus")
>
> I will added (via b4) when applying.
>
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Hi,
do I need to update and resend this patch?
--
Best regards,
Andrey Skvortsov
^ permalink raw reply
* Re: [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings.
From: Stefan Dösinger @ 2026-05-14 20:54 UTC (permalink / raw)
To: Conor Dooley
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260512-musket-gaffe-376f0450a610@spud>
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
Am Dienstag, 12. Mai 2026, 20:02:03 Ostafrikanische Zeit schrieben Sie:
> Unless you want to model top + matrix as a single node with two register
> regions, then list it all. Hiding the relationships is ill-advised IMO.
I actually like the idea of modeling it as a single node. I'll give it a try.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: H. Peter Anvin @ 2026-05-14 19:57 UTC (permalink / raw)
To: kreijack, Goffredo Baroncelli, Christoph Hellwig, David Sterba
Cc: Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <0a8d1ff4-f5a2-49e9-aa45-d25dbe4ded40@libero.it>
On May 14, 2026 12:51:59 PM PDT, Goffredo Baroncelli <kreijack@libero.it> wrote:
>On 13/05/2026 07.47, Christoph Hellwig wrote:
>> On Tue, May 12, 2026 at 01:42:31PM +0200, David Sterba wrote:
>
>>
>>> The degenerate modes of
>>> raid0, 5, or 6 are explicit as a possible middle step when converting
>>> profiles. We can use a fallback implementation for this case if the
>>> accelerated implementations cannot do it.
>>
>> This is not about a degenerated mode. For a degenerated RAID 6, parity
>> generation uses the RAID 5 XOR routines as the second parity will be
>> missing. This is about generating two parities for a single data disk,
>> which must be explicitly selected.
>>
>
>I think that the David concern is : "what happens for an already
>existing btrfs raid6 3 disks filesystem when the user upgrade the kernel ?"
>(I am thinking when a new BG needs to be allocated)...
>
>BR
>GB
>
That's what I'm saying – it should invoke the RAID-1 code under the cover (as with 3 disks, D = P = Q.)
^ 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