* Re: [PATCH v3 16/21] objtool/klp: Filter arm64 mapping symbols in find_symbol_by_offset()
From: Song Liu @ 2026-05-15 21:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Catalin Marinas, Will Deacon, linux-arm-kernel, Mark Rutland,
Miroslav Benes, Petr Mladek
In-Reply-To: <236050080db7b2462fdb13a03ed48a8efb2415a4.1778642120.git.jpoimboe@kernel.org>
On Tue, May 12, 2026 at 8:34 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> ARM64 ELF objects contain $d/$x mapping symbols (STT_NOTYPE) at offset 0
> in data/text sections. These aren't "real" symbols so filter them from
> find_symbol_by_offset(), consistent with the existing section symbol
> filter.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Acked-by: Song Liu <song@kernel.org>
^ permalink raw reply
* [PATCH 3/6] ARM: dts: imx: Add bus-type for ov5642/ov5640
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add bus-type (MEDIA_BUS_TYPE_PARALLEL) for ov5642/ov5640. i.MX53 and
i.MX6UL only supports parallel csi interface. Fix below CHECK_DTBS
warnings:
arm/boot/dts/nxp/imx/imx53-smd.dtb: ov5642@3c (ovti,ov5642): port:endpoint: 'bus-type' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-smd.dts b/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
index a1e19f9709b2c7c7d02812f2b5c2afd382fb5d86..8c02731c7ba9db794627e085feb8a4e957d8c5c3 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interfaces.h>
#include "imx53.dtsi"
/ {
@@ -314,6 +315,7 @@ camera: ov5642@3c {
port {
ov5642_to_ipu_csi0: endpoint {
remote-endpoint = <&ipu_csi0_from_parallel_sensor>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
hsync-active = <1>;
vsync-active = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
index 3d147b160ecf150f2f3b6afa8b5873fabc2ba96f..32afe4130e21126bf6e476db1091c4a45b8cf5bc 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
@@ -217,6 +217,7 @@ camera@3c {
port {
ov5640_to_parallel: endpoint {
remote-endpoint = <¶llel_from_ov5640>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
data-shift = <2>; /* lines 9:2 are used */
hsync-active = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/6] ARM: dts: cleanup some CHECK_DTBS warning for imx5/6 (round 2)
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
Cleanup CHECK_DTBS warning for imx_v6_v7_defconfig. (below 500 line warning
left) after apply pending binding doc patch.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (6):
ARM: dts: imx: add (power|vdd)-supply for related node
ARM: dts: imx: remove redundant bus-width for video-mux
ARM: dts: imx: Add bus-type for ov5642/ov5640
ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 11 ++++++++++-
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 ----
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 5 ++---
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 2 +-
29 files changed, 36 insertions(+), 38 deletions(-)
---
base-commit: d26bfe9856a36453f591b9620dac996ff9f02443
change-id: 20260511-imx25_dts_simple_warning_2-10d3c75b8889
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH 4/6] ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Remove the undocumented and unused compatible karo,imx6qdl-tx6-sgtl5000 and
retain only the generic simple-audio-card sound configuration.
The karo,imx6qdl-tx6-sgtl5000 compatible is not documented and is not
referenced by any in-kernel driver. The audio setup is already fully
described using simple-audio-card, which is the standard and supported
binding for this hardware configuration.
No known users (such as uboot) rely on karo,imx6qdl-tx6-sgtl5000.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-tx6dl-comtft.dtb: /sound: failed to match any schema with compatible: ['karo,imx6qdl-tx6-sgtl5000', 'simple-audio-card']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
index 57297d6521cf09f1fd629ae375c9994ebb683375..ec1528ff3ea0146157a56f2ecba500e651f857ff 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
@@ -148,8 +148,7 @@ reg_usbotg_vbus: regulator-usbotg-vbus {
};
sound {
- compatible = "karo,imx6qdl-tx6-sgtl5000",
- "simple-audio-card";
+ compatible = "simple-audio-card";
simple-audio-card,name = "imx6qdl-tx6-sgtl5000-audio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
--
2.43.0
^ permalink raw reply related
* [PATCH 5/6] ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
The edt,edt-ft5x06 compatible is not referenced in
drivers/input/touchscreen/edt-ft5x06.c and is not documented.
There is no publicly available datasheet or binding information that
distinguishes edt-ft5206/ft5306/ft5406 variants and the driver treats these
FT5x06-family controllers with the same configuration model. So switch to
the lowest common and documented baseline compatible edt,edt-ft5206.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dtb: /soc/bus@60000000/i2c@63fc8000/touchscreen@38: failed to match any schema with compatible: ['edt,edt-ft5x06']
ABI impact consideration:
Not affect Linux kernel ABI because edt,edt-ft5x06 is not used by the
existing driver. U-Boot does not parse or use edt,edt-ft* touchscreen
compatibles.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Change binding doc discuss at
- https://lore.kernel.org/imx/aasmQiZJO2gSKzNH@lizhi-Precision-Tower-5810/
---
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 2 +-
13 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
index 2acbc86cabb3193f1b27b5de3155cf3d88381f49..aa1c7e5012c6af16e559c914777de476d6eab966 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
@@ -248,7 +248,7 @@ &i2c1 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts b/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
index 872cf7e16f20c923e7772e8def7df46276d683ef..6a1063c455f0c225c3d23ac4621c9957c95d491e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
@@ -201,7 +201,7 @@ sgtl5000: codec@a {
};
polytouch: edt-ft5x06@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06_1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts b/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
index 0225a621ec7a9e697ba95cf0617513156f8c521f..ccf6a048c9184c95105231f50acd96038ab353d9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
@@ -169,7 +169,7 @@ &i2c3 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
index 610b2a72fe82557c51fbad1bfff65154540e2279..cebfd622df688ecd01cecc0621d1ed23512da007 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
@@ -256,7 +256,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
index ef0c26688446ef5a92c94f553ab900ae4e5fdcfb..f8a7218b13ef20675c0e9b7af1f56c0b7bcc2b11 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
@@ -405,7 +405,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
index 6a353a99e13daa2f13ba91d7311f60c88b40695b..9fe52e0ca7aa24379ad11c62236d586885242aa0 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
@@ -333,7 +333,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
index c39a9ebdaba1c56b7422c1beb77ba9ddd502609f..ca4cb986efbc204a4ccc8b4d3eb035f4b3504dcd 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
@@ -217,7 +217,7 @@ &i2c2 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio5>;
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
index ec1528ff3ea0146157a56f2ecba500e651f857ff..fe25934e06b1fea9bc2b16cb53c24a11ca0525f9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
@@ -292,7 +292,7 @@ sgtl5000: sgtl5000@a {
};
polytouch: edt-ft5x06@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
index bf7dbb4f1f3ed99a9b9cff76e052bd1d9aa8bafe..e99ba04216b8670173bed60b98f0011b423b23aa 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
@@ -62,7 +62,7 @@ &i2c3 {
status = "okay";
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
index 6cfc943a8fa3ee4452244bf4198d65a319453d66..f79090fb2e6e2e7bfe886d67f45df06923bb96ac 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
@@ -65,7 +65,7 @@ &i2c3 {
status = "okay";
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
index 1992dfb53b45cd308522c3e922d5758f5b8fe527..192c6a95ae589f491473a92277e38ad1d4c7b23c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
@@ -317,7 +317,7 @@ sgtl5000: codec@a {
};
polytouch: polytouch@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
index 347dd0fe4f82e00ff5fa57487f3333d61c4b27c5..fca8aab9d850791d5df1569a9a3ef4301bd0503c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
@@ -70,7 +70,7 @@ pca9554: io-expander@25 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touchscreen>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
index 62221131336f12b9233474496888e0d34631765b..673bbe49de52500a9218fb06c4212a5a4238d677 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
@@ -49,7 +49,7 @@ sgtl5000: codec@a {
&i2c4 {
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touchscreen>;
--
2.43.0
^ permalink raw reply related
* [PATCH 6/6] ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Replace the vendor-specific PHY compatible string with the generic
ethernet-phy-ieee802.3-c22 compatible.
The marvell,88E1510 compatible is listed in whitelist_phys[] and is
never matched against a PHY driver. PHY devices are expected to use
the generic ethernet-phy-ieee802.3-c22 compatible unless a specific
MDIO driver match is required.
The 88E1510 is compatible with Clause 22 PHY devices, so use the
generic compatible string instead.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6q-display5-tianma-tm070-1280x768.dtb: /soc/bus@2100000/ethernet@2188000/mdio/ethernet-phy@0: failed to match any schema with compatible: ['marvell,88E1510']
Known other user (uboot) did not use marvell,88E1510.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi b/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
index 4e448b4810f27ba67332811519a199a7ff0ee004..21e8bbdab4e695c0da169f1a8714398c6964ca35 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
@@ -208,7 +208,7 @@ mdio {
#address-cells = <1>;
#size-cells = <0>;
ethernet_phy0: ethernet-phy@0 {
- compatible = "marvell,88E1510";
+ compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
/* Set LED0 control: */
/* On - Link, Blink - Activity, Off - No Link */
--
2.43.0
^ permalink raw reply related
* [PATCH 1/6] ARM: dts: imx: add (power|vdd)-supply for related node
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add required power-supply and vdd-supply properties to fix below CHECK_DTB
warnings:
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dtb: panel (edt,etm0700g0dh6): 'power-supply' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 9 +++++++++
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
4 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
index 6210673f93bea67c4f717b11439069d86f90b008..2acbc86cabb3193f1b27b5de3155cf3d88381f49 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
@@ -84,6 +84,7 @@ panel {
pinctrl-0 = <&pinctrl_display_gpio>;
pinctrl-names = "default";
enable-gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3p2v>;
port {
panel_in: endpoint {
@@ -98,6 +99,13 @@ beeper {
gpios = <&gpio6 3 GPIO_ACTIVE_HIGH>;
};
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
reg_usbh1_vbus: regulator-usbh1-vbus {
compatible = "regulator-fixed";
regulator-name = "vbus";
@@ -259,6 +267,7 @@ eeprom@50 {
dac@60 {
compatible = "microchip,mcp4725";
reg = <0x60>;
+ vdd-supply = <®_3v3>;
};
};
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
index e395004e80e6d2caba6da8350f1f6ac2dc01f61d..34cb0c344ff6ee10b59d29d528d54051c2a0f82c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
@@ -10,6 +10,7 @@
/ {
panel: panel-rgb {
compatible = "powertip,ph800480t013-idf02";
+ power-supply = <®_5v>;
port {
panel_rgb_in: endpoint {
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
index 1a00d290092ad447d45d5e0cb5117183c4bc3dfe..c1e065359fd2d5a2ca287a960155f00c75069899 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
@@ -29,6 +29,13 @@ memory@70000000 {
reg = <0x70000000 0x20000000>;
};
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
reg_usb1_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts b/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
index 24fc3ff1c70c2f3c9ac4309f9c7c723f003096d9..cd9a050fa906e4a7273ae3a290375c30853ea075 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
@@ -109,6 +109,7 @@ led-heartbeat {
panel: panel {
compatible = "innolux,n133hse-ea1";
backlight = <&backlight>;
+ power-supply = <®_lvds_lcd>;
};
reg_2p5v: regulator-2p5v {
--
2.43.0
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: imx: remove redundant bus-width for video-mux
From: Frank Li via B4 Relay @ 2026-05-15 21:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Remove redundant bus-width property according to video-mux.yaml to fix
below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-gw51xx.dtb: ipu1_csi0_mux (video-mux): port@4:endpoint: Unevaluated properties are not allowed ('bus-width' was unexpected)
from schema $id: http://devicetree.org/schemas/media/video-mux.yaml
The bus-width already set at remote endpoint (camera).
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 ----
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 --
10 files changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
index 9ea23dd54f3ce0d8e3abad2c2ced7798a2854489..62b05fe70cd97b16553b65371ee8efb77168d61b 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
index 182e8194c2490b520aa065e11933795aaa6d7a71..c1787510d3941d77ca1e9f76560d2e57852bf995 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
index a106c4e3e32995f4fe7801f04ce549dd50283c85..934b0325e6f5acffd72f8063bf7d9e5de02b1093 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
index 6e1c493c9c8c49343313a71f0c72570915a311cd..31996ddde117acbe50166da8fbe6a6290a895211 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu2_csi1_mux: endpoint {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
index f13df8e9c8c4b213d4371d93ef6e4a19e969dcd6..f224273fa863ecbc41e14df1f0324b5ef4192a9e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu2_csi1_mux: endpoint {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
index d5d46908cf6ed8f15ec03584146d7af5b2d9d72d..804ee044be52d716a6e6cfb97b8aa4520d3b9baa 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
@@ -90,12 +90,10 @@ tda1997x_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <16>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
- bus-width = <16>;
};
&ipu1_csi0 {
@@ -104,12 +102,10 @@ &ipu1_csi0 {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
index beff5a0f58ab48d4d7b8f14f9e695763dc2e3bdf..fb18b87adb441e4e11ddab602c3e3a8e302fa81c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
@@ -384,12 +384,10 @@ adv7180_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
index 6136a95b9259977bd2debb05e2a480cd1e2fb765..55647c1dacfa5d26c386ebf490c50ef825b99e94 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
@@ -440,12 +440,10 @@ tda1997x_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <16>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
- bus-width = <16>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
index 552114a69f5b9575a3685fcbbae11a7fc2673e45..bdbcad5e35d8258353831f211776e4fd8c2e684d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
@@ -397,12 +397,10 @@ adv7180_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
index b9dde0af3b995feb49fef38fb0fda69eee3a5750..40d8887cb8bc7f3ce1948fbeadbde6c0d4d1ff0c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
@@ -245,12 +245,10 @@ accelerometer@1c {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: allwinner: Cubie A5E: enable SPI flash
From: Andre Przywara @ 2026-05-15 21:51 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi
In-Reply-To: <CAGb2v66drOyBgNU0hFo356MKTFnggNmyzrANok+-U31NzZCUEw@mail.gmail.com>
On Sat, 16 May 2026 00:12:17 +0800
Chen-Yu Tsai <wens@kernel.org> wrote:
> On Wed, May 13, 2026 at 5:19 PM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > Hi Chen-Yu,
> >
> > thanks for chipping in!
> >
> > On 5/13/26 07:21, Chen-Yu Tsai wrote:
> > > Hi,
> > >
> > > On Tue, May 12, 2026 at 6:18 AM Andre Przywara <andre.przywara@arm.com> wrote:
> > >>
> > >> The Cubie A5E board comes with 16MiB of SPI NOR flash.
> > >>
> > >> Enable the SPI0 DT node and describe the configuration.
> > >>
> > >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > >> ---
> > >> .../boot/dts/allwinner/sun55i-a527-cubie-a5e.dts | 15 +++++++++++++++
> > >> 1 file changed, 15 insertions(+)
> > >>
> > >> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
> > >> index bfdf1728cd14b..7ad22fc85d1fd 100644
> > >> --- a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
> > >> +++ b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
> > >> @@ -344,6 +344,21 @@ &r_pio {
> > >> vcc-pm-supply = <®_aldo3>;
> > >> };
> > >>
> > >> +&spi0 {
> > >> + pinctrl-names = "default";
> > >> + pinctrl-0 = <&spi0_pc_pins>, <&spi0_cs0_pc_pin>,
> > >> + <&spi0_hold_pc_pin>, <&spi0_wp_pc_pin>;
> > >
> > > This whole thing needs to be an overlay. The HOLD and WP pins
> > > conflict with eMMC usage, so it seems that Radxa only populates
> > > one or the other.
> > >
> > > If you look at the pictures on their official website, you'll see the
> > > SPI NOR chip populated, but not the eMMC chip. On the linux-sunxi wiki
> > > page, you'll see the opposite.
> >
> > Well, I have a hard time spotting any actual eMMC SKUs in the shops anyway.
> > But you are right, the hold and WP pins conflict with eMMC, whereas the
> > other pins are not.
> >
> > > And you probably want to enable QSPI, like Sashiko mentioned.
> >
> > Well, in the interest of keeping this simple and enabling the usage of
> > SPI flash for all the users out there, I'd rather drop the extra pins.
> > This is mostly really useful for booting the firmware, maybe loading a
> > tiny kernel or other data once, so performance is not a big concern in
> > this use case. The BootROM surely does not use QSPI.
>
> Given that the pins are tied on physically, if someone then enables mmc2
> for a potentially present eMMC, the two pins could be toggled by the
> MMC controller, causing the flash to misbehave. I'm slightly concerned
> about this possibility.
That's a good point, but that means it's really a hardware design
issue: you cannot have SPI together with eMMC on this board.
I don't know if Radxa ships the eMMC SKUs without SPI flash, I
will try to query Tom Cubie about this.
I would prefer to go with SPI flash, at least for now: I think that's
what most users have, and the eMMC versions are rare so far? Since we
don't have an eMMC node in the DT anyway, that should be fine for now.
If someone adds eMMC support later, we would need to figure this out.
We could mark one as disabled, and leave it up to users (or U-Boot)
to decide which to enable.
On the H6 there is a similar problem: PC5 is both SPI0_CS and MMC2_CMD,
so on the PineH64 we disable the SPI flash, in favour of eMMC, which is
more useful for users (but sunxi-fel SPI access and U-Boot SPI loading
work nevertheless). But given the apparent prevalence of SPI boards vs.
those with eMMC for the Cubie A5E, I would go with SPI on this one.
Does that make sense? Any thoughts?
Cheers,
Andre
> > And as you say, if people are really interested in the last bit of
> > performance, they can use an overlay.
> >
> > Cheers,
> > Andre
> >
> > >
> > >
> > > ChenYu
> > >
> > >
> > >> + status = "okay";
> > >> +
> > >> + flash@0 {
> > >> + compatible = "winbond,w25q128", "jedec,spi-nor";
> > >> + reg = <0>;
> > >> + spi-max-frequency = <40000000>;
> > >> + #address-cells = <1>;
> > >> + #size-cells = <1>;
> > >> + };
> > >> +};
> > >> +
> > >> &uart0 {
> > >> pinctrl-names = "default";
> > >> pinctrl-0 = <&uart0_pb_pins>;
> > >> --
> > >> 2.46.4
> > >>
> > >
> >
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: socfpga: arria10: Increase JFFS2 rootfs partition size
From: Dinh Nguyen @ 2026-05-15 21:54 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, robh, krzk+dt, conor+dt
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260511081520.20247-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On 5/11/26 03:15, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Niravkumar L Rabara <niravkumar.l.rabara@altera.com>
>
> Increase the JFFS2 partition size to support larger root filesystem.
> Also fix the partition label to match the actual start address.
>
> Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> .../arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts b/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts
> index a662df319a84..5f9b98b0b393 100644
> --- a/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts
> +++ b/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts
> @@ -18,9 +18,9 @@ partition@0 {
> label = "Boot and fpga data";
> reg = <0x0 0x02500000>;
> };
> - partition@1c00000 {
> + partition@2500000 {
> label = "Root Filesystem - JFFS2";
> - reg = <0x02500000 0x05500000>;
> + reg = <0x02500000 0x3db00000>;
> };
> };
> };
Applied!
Thanks,
Dinh
^ permalink raw reply
* Re: [PATCH v2 3/9] iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq submission functions
From: Jason Gunthorpe @ 2026-05-15 22:00 UTC (permalink / raw)
To: Nicolin Chen
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <ageKAQC7yAzI0xB6@Asurada-Nvidia>
On Fri, May 15, 2026 at 02:02:57PM -0700, Nicolin Chen wrote:
> On Wed, May 13, 2026 at 08:57:42PM -0300, Jason Gunthorpe wrote:
> > Continue removing struct arm_smmu_cmdq_ent in favour of the HW based
> > struct arm_smmu_cmd. Switch the lower level issue commands to work on
> > the native struct by lifting arm_smmu_cmdq_build_cmd() into all the
> > callers.
> >
> > Following patches will revise each of the arm_smmu_cmdq_build_cmd()
> > call sites to replace it with the HW struct.
> >
> > Reviewed-by: Mostafa Saleh <smostafa@google.com>
> > Reviewed-by: Pranjal Shrivastava <praan@google.com>
> > Tested-by: Pranjal Shrivastava <praan@google.com>
> > Tested-by: Mostafa Saleh <smostafa@google.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> [...]
> > @@ -3446,6 +3447,7 @@ arm_smmu_install_new_domain_invs(struct arm_smmu_attach_state *state)
> > static void arm_smmu_inv_flush_iotlb_tag(struct arm_smmu_inv *inv)
> > {
> > struct arm_smmu_cmdq_ent cmd = {};
> > + struct arm_smmu_cmd hw_cmd;
>
> Following the other pattern, this could be:
> "cmd" -> "ent" and "hw_cmd" -> "cmd"?
>
> That being said, at the end of the series, these all get removed.
Yeah, I made choices to minimize the diffs
Jason
^ permalink raw reply
* Re: [PATCH 5/8] arm64: dts: qcom: Add GPU support for Kaanapali
From: Akhil P Oommen @ 2026-05-15 22:08 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Will Deacon, Robin Murphy,
Joerg Roedel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Rob Clark, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter
In-Reply-To: <14a2fbfd-97c1-4ba7-aa51-a07134102d3b@oss.qualcomm.com>
On 5/14/2026 6:13 PM, Konrad Dybcio wrote:
> On 5/12/26 12:23 AM, Akhil P Oommen wrote:
>> Adreno 840 present in Kaanapali SoC is the second generation GPU in
>> A8x family. It is based on the new slice architecture with 3 slices,
>> higher GMEM/caches etc.
>>
>> There is some re-arrangement in the reglist to properly cover maximum
>> register region. Other than this, the DT description is mostly similar
>> to the existing chipsets except the OPP tables.
>>
>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>> ---
>
> [...]
>
>> + gpu_opp_table: opp-table {
>> + compatible = "operating-points-v2-adreno",
>> + "operating-points-v2";
>> +
>> + opp-222000000 {
>> + opp-hz = /bits/ 64 <222000000>;
>> + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
>> + opp-peak-kBps = <2136718>;
>> + opp-supported-hw = <0x0f>;
>> + /* ACD is disabled */
>> + };
>
> The clock plan also has a 160 MHz OPP @ LOWSVS_D3 and there's a couple of
> interim OPPs that you have that aren't part of it (but maybe you have
> better docs)
I somehow assumed that the 160Mhz was a thermal-only corner. Seems it is
not. Let me revisit the OPP table again. Yeah, the doc is outdated.
Looks like there was some last minute updates to the OPP table.
Also, we should update a6xx_hfi.h to accommodate more than 16 GX levels.
-Akhil.
>
> Otherwise lgtm but the size of the GPU region and the GMU base look
> slightly confusing when I'm comparing them against the reg map
>
> Konrad
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: display/msm: gpu: Document Adreno X2-185
From: Akhil P Oommen @ 2026-05-15 22:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel,
linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu
In-Reply-To: <20260514-pearl-mamba-of-inquire-e4888f@quoll>
On 5/14/2026 3:43 PM, Krzysztof Kozlowski wrote:
> On Wed, May 13, 2026 at 12:51:19AM +0530, Akhil P Oommen wrote:
>> Adreno X2-185 GPU found in Glymur chipsets belongs to the A8x family.
>> It features a new slice architecture with 4 slices, significantly higher
>> bandwidth throughput compared to mobile counterparts, raytracing support,
>> and the highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among
>> other improvements. Update the dt bindings documentation to describe this
>> GPU.
>>
>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/display/msm/gpu.yaml | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>
> Someone needs to start applying Adreno GPU patches...
> https://lore.kernel.org/all/20260301142033.88851-2-krzysztof.kozlowski@oss.qualcomm.com/
>
>
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
>> index 04b2328903ca..e67cd708dda2 100644
>> --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
>> +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
>> @@ -411,6 +411,22 @@ allOf:
>> - clocks
>> - clock-names
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: qcom,adreno-44070001
>> + then:
>> + properties:
>> + reg:
>> + minItems: 2
>> + maxItems: 2
>> +
>> + reg-names:
>> + items:
>> + - const: kgsl_3d0_reg_memory
>> + - const: cx_mem
>
> Are you sure there is no cx_dbgc? If not, then just minItems+maxItems
> like for 'reg:'.
I merged cx_dbgc region into the kgsl_3d0_reg_memory region for A8xx
series. It was getting in the way of covering the entire GPU MMIO in DT
without overlaps.
We don't prefer overlapping regions even if it is within a single
device, right?
-Akhil.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [net-next v8 2/3] net: ethernet: mtk_eth_soc: Add RSS support
From: Jakub Kicinski @ 2026-05-15 22:45 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Mason Chang, AngeloGioacchino Del Regno, netdev, Russell King,
linux-kernel, Andrew Lunn, Eric Dumazet, linux-mediatek,
Daniel Golle, Matthias Brugger, Paolo Abeni, Lorenzo Bianconi,
David S. Miller, linux-arm-kernel, Felix Fietkau,
Frank Wunderlich
In-Reply-To: <935a73a6e458b2d4fed2e59192e725483ca62126@linux.dev>
On Fri, 15 May 2026 11:13:05 +0000 Frank Wunderlich wrote:
> > > We can adjust SMP affinity with the following command:
> > > echo [CPU bitmap num] > /proc/irq/[virtual IRQ ID]/smp_affinity,
> > > with interrupts evenly assigned to 4 CPUs, we were able to measure
> > > an RX throughput of 7.3Gbps using iperf3 on the MT7988. Further
> > > optimizations will be carried out in the future.
> > >
> > Would be great to split this up a little more for ease of review.
>
> you mean splitting the code into more separate patches or the commit description?
The code, seemed like it should at the very least be split into
multi-queue/napi support (mostly driver changes) vs RSS programming
and config.
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-15 22:51 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agXfm3mS_M3fvRrN@google.com>
On Thu, May 14, 2026 at 02:43:39PM +0000, Mostafa Saleh wrote:
> > That's a somewhat different problem, we have the dev->trusted stuff
> > that is supposed to deal with this kind of security. We need it for
> > IOMMU based systems too, eg hot plug thunderbolt should have it.
>
> I see that it is used only for dma-iommu and for PCI devices.
> However, I think that should be a problem with other CCA solutions
> with emulated devices as they are untrusted. As I'd expect they
> would have virtio devices.
Yes, any security solution with an out of TCB device should be using either
memory encryption so the kernel already bounces or this trusted stuff
and a force strict dma-iommu so the dma layer is careful.
This is more policy from userspace what devices they want in or out of
their TCB. Like you make accept the device into T=1 but then still
want to keep it out of your TCB with the vIOMMU, I can see good
arguments for something like that.
> > > While we can debate the aesthetics of the setup , this is
> > > the exisitng behaviour for Linux, which existed for years
> > > and pKVM relies on and is used extensively.
> > > And, this patch alters that long-standing logic and introduces
> > > a functional regression.
> >
> > Yeah, Aneesh needs to do something here, I'm pointing out it is
> > entirely seperate thing from the CC path we are working on which is
> > decoupling CC from reylying on force swiotlb.
>
> I am looking into converting pKVM to use the CC stuff, I replied with
> a patch to Aneesh in this thread. However, I need to do more testing
> and make sure there are not any unwanted consequences.
Yeah, it is a nice patch and I think it will help reduce the
complexity if it aligns to CCA type stuff.
> > In a pkvm world it should be the same, the S2 table for the SMMU will
> > control what the device can access, and if the SMMU points to a
> > "private" or "shared" page is not something the device needs to know
> > or care about.
>
> I see that's because dma-iommu chooses the attrs for iommu_map().
Long term the DMA API path through the dma-iommu will pass the
ATTR_CC_SHARED through to iommu_map so when the arch requires a
different IOPTE it can construct it.
> In pKVM, dma_addr_t and IOPTE are the same for private and shared,
> so nothing differs in that case.
Yes, so you don't have to worry.
> We don’t expect pass-through devices to interact with shared
> memory (T=0) at the moment.
> However, I can see use cases for that, where the host and the guest
> collaborate with device passthrough and require zero copy.
Once you add the CC patch it becomes immediately possible though
because the user can allocate a CC shared DMA HEAP and feed that all
over the place.
> One other interesting case for device-passthrough is non-coherent
> devices which then require private pools for bouncing.
Why does shared/private matter for bouncing? Why do you need to bounce
at all? Do cmo's not work in pkvm guests?
Jason
^ permalink raw reply
* Re: [PATCH] iommu: Allow device driver to use its own PASID space for SVA
From: Jason Gunthorpe @ 2026-05-15 23:18 UTC (permalink / raw)
To: Joonwon Kang
Cc: will, robin.murphy, joro, jpb, Alexander.Grest, amhetre, baolu.lu,
easwar.hariharan, jacob.jun.pan, kees, kevin.tian, nicolinc,
praan, smostafa, tglx, mingo, bp, dave.hansen, x86, hpa, peterz,
sohil.mehta, kas, alexander.shishkin, ryasuoka, xin, linux-kernel,
iommu, linux-arm-kernel
In-Reply-To: <20260515094605.3195841-1-joonwonkang@google.com>
On Fri, May 15, 2026 at 09:46:05AM +0000, Joonwon Kang wrote:
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0ca3912ecb7f..61e2e52105e5 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -864,6 +864,8 @@ static bool try_fixup_enqcmd_gp(void)
> return false;
>
> pasid = mm_get_enqcmd_pasid(current->mm);
> + if (pasid == IOMMU_PASID_INVALID)
> + return false;
If you do this then probably you should get rid of mm_valid_pasid(),
mm_get_enqcmd_pasid() already has the NULL check so the two functions
are kind of pointless.
You also missed the other place calling mm_valid_pasid() that should
really be sensitive to this as well:
static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits)
{
[..]
if (mm_valid_pasid(mm) &&
!test_bit(MM_CONTEXT_FORCE_TAGGED_SVA, &mm->context.flags))
return -EINVAL;
Make that removal a prep patch
I didn't try to check the rest closely but the approach looked sane to
me
Jason
^ permalink raw reply
* Re: [PATCH v2 4/9] iommu/arm-smmu-v3: Convert arm_smmu_cmdq_batch cmds to struct arm_smmu_cmd
From: Nicolin Chen @ 2026-05-15 23:29 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <4-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:43PM -0300, Jason Gunthorpe wrote:
> Convert the batch's type to also get the remaining helper functions to
> use the new type and complete replacing naked u64s with the new struct.
>
> The low-level queue_write()/queue_read()/queue_remove_raw() functions
> remain u64-based since they are shared by event and PRI queues which
> have different entry sizes.
>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH v2 05/17] arm64: dts: allwinner: Add EL2 virtual timer interrupt
From: Andre Przywara @ 2026-05-15 23:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Heiko Stuebner, Shawn Lin, Orson Zhai,
Baolin Wang, Michal Simek, linux-sunxi
In-Reply-To: <20260514150945.3917510-6-maz@kernel.org>
On Thu, 14 May 2026 16:09:33 +0100
Marc Zyngier <maz@kernel.org> wrote:
> The ARMv8.2 based CPUs used in the A523 SoC (and derivatives)
> are missing the EL2 virtual timer interrupt. Add it.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Works, with [v2 03/17] and this patch I see the arch timer IRQ being
int ID 28, and working, where it was 26 before. dmesg confirms that:
[ 0.000000] arch_timer: cp15 timer running at 24.00MHz (hyp-virt).
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre
> ---
> arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
> index 5afa8d92acbfb..d3c47966e8fc8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
> @@ -101,7 +101,8 @@ timer {
> interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 12 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> soc {
^ permalink raw reply
* Re: [PATCH v2 5/9] iommu/arm-smmu-v3: Remove CMDQ_OP_CFGI_CD_ALL from arm_smmu_cmdq_build_cmd()
From: Nicolin Chen @ 2026-05-15 23:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <5-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:44PM -0300, Jason Gunthorpe wrote:
> Nothing uses this, just dead code.
>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH 3/3] usb: dwc3: xilinx: fix error handling in zynqmp init error paths
From: Thinh Nguyen @ 2026-05-16 0:04 UTC (permalink / raw)
To: Pandey, Radhey Shyam
Cc: Thinh Nguyen, Radhey Shyam Pandey, gregkh@linuxfoundation.org,
michal.simek@amd.com, p.zabel@pengutronix.de,
linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, git@amd.com, stable@vger.kernel.org
In-Reply-To: <7eca29f8-9847-4ee1-ae3c-8c507bc295c7@amd.com>
On Thu, May 14, 2026, Pandey, Radhey Shyam wrote:
> On 5/14/2026 7:13 AM, Thinh Nguyen wrote:
> > On Mon, May 11, 2026, Radhey Shyam Pandey wrote:
> > > Fix error handling and resource cleanup i.e remove invalid
> > > phy_exit() after failed phy_init(), route failures through
> > > proper cleanup paths and return 0 explicitly on success.
> > >
> > > Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> > > ---
> > > drivers/usb/dwc3/dwc3-xilinx.c | 27 +++++++++++++++------------
> > > 1 file changed, 15 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> > > index 94458b3da1a0..b832505e1b04 100644
> > > --- a/drivers/usb/dwc3/dwc3-xilinx.c
> > > +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> > > @@ -176,15 +176,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> > > }
> > > ret = phy_init(priv_data->usb3_phy);
> > > - if (ret < 0) {
> > > - phy_exit(priv_data->usb3_phy);
> > > + if (ret < 0)
> > > goto err;
> > > - }
> > > ret = reset_control_deassert(apbrst);
> > > if (ret < 0) {
> > > dev_err(dev, "Failed to release APB reset\n");
> > > - goto err;
> > > + goto err_phy_exit;
> > > }
> > > if (priv_data->usb3_phy) {
> > > @@ -200,26 +198,24 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> > > ret = reset_control_deassert(crst);
> > > if (ret < 0) {
> > > dev_err(dev, "Failed to release core reset\n");
> > > - goto err;
> > > + goto err_phy_exit;
> > > }
> > > ret = reset_control_deassert(hibrst);
> > > if (ret < 0) {
> > > dev_err(dev, "Failed to release hibernation reset\n");
> > > - goto err;
> > > + goto err_phy_exit;
> > > }
> > > ret = phy_power_on(priv_data->usb3_phy);
> > > - if (ret < 0) {
> > > - phy_exit(priv_data->usb3_phy);
> > > - goto err;
> > > - }
> > > + if (ret < 0)
> > > + goto err_phy_exit;
> > > /* ulpi reset via gpio-modepin or gpio-framework driver */
> > > reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > > if (IS_ERR(reset_gpio)) {
> > > - return dev_err_probe(dev, PTR_ERR(reset_gpio),
> > > - "Failed to request reset GPIO\n");
> > > + ret = PTR_ERR(reset_gpio);
> > > + goto err_phy_power_off;
> > > }
> > > if (reset_gpio) {
> > > @@ -229,6 +225,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> > > }
> > > dwc3_xlnx_set_coherency(priv_data, XLNX_USB_TRAFFIC_ROUTE_CONFIG);
> > > +
> > > + return 0;
> > > +
> > > +err_phy_power_off:
> > > + phy_power_off(priv_data->usb3_phy);
> > > +err_phy_exit:
> > > + phy_exit(priv_data->usb3_phy);
> > > err:
> > > return ret;
> > > }
> > > --
> > > 2.44.4
> > >
> >
> > This fix should be a separate patch from this cleanup series.
> >
>
> Sure, will split it into a separate patch. Does this patch look fine?
> If so i can add the Reviewed-by tag in v2 or address any further
> comments if needed.
>
This patch looks good. You can add my Acked-by when resubmit:
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Thanks,
Thinh
^ permalink raw reply
* Re: [GIT PULL] arm64 fixes for 7.1-rc4
From: pr-tracker-bot @ 2026-05-16 0:06 UTC (permalink / raw)
To: Catalin Marinas
Cc: Linus Torvalds, Will Deacon, James Morse, Ben Horgan,
linux-arm-kernel, linux-kernel
In-Reply-To: <agdbnfcTQATqM1K8@arm.com>
The pull request you sent on Fri, 15 May 2026 18:45:01 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/36343a8ff328efd3eb5604e3567d63e6c7906deb
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Reserve RX headroom to avoid skb reallocation
From: patchwork-bot+netdevbpf @ 2026-05-16 0:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev, xuegang.lu
In-Reply-To: <20260513-airoha-rx-headroom-v1-1-bd87798e422d@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 13 May 2026 17:03:59 +0200 you wrote:
> Reserve NET_SKB_PAD + NET_IP_ALIGN bytes of headroom for received packets
> to avoid skb head reallocation when pushing protocol headers into the skb.
>
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 14 ++++++++------
> drivers/net/ethernet/airoha/airoha_eth.h | 2 ++
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> [...]
Here is the summary with links:
- [net-next] net: airoha: Reserve RX headroom to avoid skb reallocation
https://git.kernel.org/netdev/net-next/c/bbfb1983944f
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 v2 0/9] Remove SMMUv3 struct arm_smmu_cmdq_ent
From: Samiullah Khawaja @ 2026-05-16 0:46 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Nicolin Chen, Pasha Tatashin, patches,
Pranjal Shrivastava, Mostafa Saleh
In-Reply-To: <0-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:39PM -0300, Jason Gunthorpe wrote:
>[ This is part of the patch pile to move SMMUv3 over to the generic page
>table:
>1) Introduction of new gather items and RISCV usage
> https://patch.msgid.link/r/0-v2-b5156f657dc1+25f-iommu_riscv_inv_jgg@nvidia.com
>2) Remove SMMUv3 struct arm_smmu_cmdq_ent
>3) Organize the SMMUv3 invalidation flow so iommupt can use it
>4) Use the generic iommu page table for SMMUv3
>
>The whole branch is here:
> https://github.com/jgunthorpe/linux/commits/iommu_pt_arm64/
>]
>
>The invalidation logic has this multi-step process where it first
>writes the command into a 32 byte struct arm_smmu_cmdq_ent, then it
>calls a function which converts it into a 16 byte HW struct, and
>sometimes it then edits the HW struct a little bit before passing it
>off to the batch or submission functions.
>
>Instead just generate the HW struct directly by moving the FIELD_PREP
>blocks out of the big case statement and into helper functions. Call the
>right function in all the places that were building arm_smmu_cmdq_ent.
>
>Add a type for the CMDQ entry similar to the STE/CD types that wraps the
>two u64s for clarity and use it everywhere.
>
>This is intended to have no functional change. It makes the following
>patches work better and removes a bunch of LOC. I've run several AI tools
>with instruction to look for functional changes, which did find one subtle
>mistake in PRI response.
>
>The removal of arm_smmu_cmdq_build_cmd() also achieves what Mostafa is
>doing in the pkvm series by making the command formation entirely header
>based with the arm_smmu_make_cmd_*() mini inlines.
>
>This series has no dependencies. Several people have already tested this
>on various ARM systems along with the full iommupt conversion.
>
>v2:
> - Collect tags and add a commit message note about ATS
>v1: https://patch.msgid.link/r/0-v1-b7dc0a0d4aa0+3723d-smmu_no_cmdq_ent_jgg@nvidia.com
>
>Jason Gunthorpe (9):
> iommu/arm-smmu-v3: Add struct arm_smmu_cmd to represent the HW format
> command
> iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq selection functions
> iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq submission
> functions
> iommu/arm-smmu-v3: Convert arm_smmu_cmdq_batch cmds to struct
> arm_smmu_cmd
> iommu/arm-smmu-v3: Remove CMDQ_OP_CFGI_CD_ALL from
> arm_smmu_cmdq_build_cmd()
> iommu/arm-smmu-v3: Directly encode simple commands
> iommu/arm-smmu-v3: Directly encode CMDQ_OP_ATC_INV
> iommu/arm-smmu-v3: Directly encode CMDQ_OP_SYNC
> iommu/arm-smmu-v3: Directly encode TLBI commands
>
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 24 +-
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 475 +++++++-----------
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 248 +++++----
> .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 16 +-
> 4 files changed, 350 insertions(+), 413 deletions(-)
>
>
>base-commit: d8fa633ffaf43316bc3ee8d7b21366cc92c02002
>--
>2.43.0
>
>
Sanity tested on non-coherent rockchip rk3588s with nvme.
Tested-by: Samiullah Khawaja <skhawaja@google.com>
^ permalink raw reply
* Re: [PATCH 0/2] spi: atmel: two fixes
From: Mark Brown @ 2026-05-16 2:33 UTC (permalink / raw)
To: Felix Gu
Cc: Ryan Wanner, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Radu Pirea, Richard Genoud, Wenyou Yang, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260516-atmel-v1-0-674fb4707af6@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
On Sat, May 16, 2026 at 01:20:33AM +0800, Felix Gu wrote:
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> Felix Gu (2):
> spi: atmel: fix resource leak on DMA buffer allocation failure
> spi: atmel: fix DMA resource leak on probe error paths
This needs a rebase for current mainline, I didn't check but I suspect
it's conflicting witj Johan's fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: stm: stm32_i2s: Use guard() for spin locks
From: Mark Brown @ 2026-05-16 3:00 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: Olivier Moysan, Arnaud Pouliquen, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Maxime Coquelin, Alexandre Torgue, linux-sound,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <CAABR9nHR13e3d46_Z7Q8ZkjQzKbkcPs2Er4sAvq6G1EEj-xoXw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Fri, May 15, 2026 at 11:48:55AM +0700, Bui Duc Phuc wrote:
> From a maintainer perspective, is there generally interest in gradually
> converging these drivers toward more modern/common PM patterns,
> or is preserving existing hardware-specific sequencing usually preferred
> unless there is a concrete issue to solve?
There are likely to be different considerations for different drivers,
on some systems the power savings from managing the clocks may not be
meaingful or we may need the clocks for register access. In general
it's nicer to actively manage the clocks but it's not super urgent to do
so from a framework point of view, it's more a how much work the people
working on the individual drivers want to do and if there's a use case
for specific hardware.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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