* [PATCH v4 7/7] ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Enable CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI so the factory EUI-48 stored
in the SST26VF QSPI flash SFDP can be used as a MAC address on boards
such as the sama5d27_wlsom1.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/configs/sama5_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index bd7f0b5f7d66..14dda4b0cfd0 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -220,6 +220,7 @@ CONFIG_PWM=y
CONFIG_PWM_ATMEL=y
CONFIG_PWM_ATMEL_HLCDC_PWM=y
CONFIG_PWM_ATMEL_TCB=y
+CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI=y
CONFIG_EXT4_FS=y
CONFIG_FANOTIFY=y
CONFIG_AUTOFS_FS=m
--
2.43.0
^ permalink raw reply related
* [PATCH v6 13/16] arm64: dts: st: add usart1 pins for stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add the usart1 pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v1)
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 4e570e2e5157..d515e44832d7 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -766,6 +766,39 @@ pins {
};
};
+ /omit-if-no-ref/
+ usart1_pins_b: usart1-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 8, AF6)>; /* USART1_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 10, AF6)>; /* USART1_RX */
+ bias-disable;
+ };
+ };
+
+ /omit-if-no-ref/
+ usart1_idle_pins_b: usart1-idle-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 8, ANALOG)>; /* USART1_TX */
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 10, AF6)>; /* USART1_RX */
+ bias-disable;
+ };
+ };
+
+ /omit-if-no-ref/
+ usart1_sleep_pins_b: usart1-sleep-1 {
+ pins {
+ pinmux = <STM32_PINMUX('B', 8, ANALOG)>, /* USART1_TX */
+ <STM32_PINMUX('B', 10, ANALOG)>; /* USART1_RX */
+ };
+ };
+
/omit-if-no-ref/
usart2_pins_a: usart2-0 {
pins1 {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 00/16] arm64: support Engicam MicroGEA-STM32MP257-RMM board
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Amelie Delaunay, Arnd Bergmann,
Bjorn Andersson, Christophe Parant, Conor Dooley,
Dmitry Baryshkov, Eric Biggers, Geert Uytterhoeven,
Himanshu Bhavani, Krzysztof Kozlowski, Krzysztof Kozlowski,
Luca Weiss, Maxime Coquelin, Michal Simek, Rob Herring,
Sven Peter, devicetree, linux-arm-kernel, linux-stm32
This series adds initial support for the Engicam MicroGEA-STM32MP257-RMM
board based on the MicroGEA-STM32MP257 SoM.
The support includes device tree descriptions for both the SoM and the
carrier board, together with the required pinctrl definitions for the
peripherals used.
The series also updates the arm64 defconfig accordingly.
Changes in v6:
- Update arch/arm64/configs/defconfig to match the current upstream defconfig
after merge window changes (no functional changes).
Changes in v5:
- Add patch 2/16 arm64: dts: st: add power-domains to sdmmc1 on stm32mp231
- Add patch 3/16 arm64: dts: st: add power-domains to sdmmc1 on stm32mp251
- Increase slew-rate to <1> of ltdc pins to support the 27 MHz pixel clock
and prevent timing violations.
- Change SDMMC2_CK pin bias from pull-up to bias-disable to avoid signal
integrity issues on the clock line
- Fix touchscreen resolution to 480x854
- Fix SPI1 CS0 polarity to GPIO_ACTIVE_LOW
Changes in v4:
- Drop inclusion of stm32mp25xf.dtsi from stm32mp257-engicam-microgea.dtsi
Changes in v3:
- Add power-domains property in the SDMMC2 node.
- Drop patch "arm64: defconfig: cleanup the defconfig"
Changes in v2:
- Add Acked-by of Conor Dooley for patch 0/1 "dt-bindings: arm: stm32:
support Engicam MicroGEA-STM32MP257-RMM board"
- Add resets property to dts CAN node. Suggested by Sashiko.
- Drop the clocks property from the sai1 node in stm32mp257-engicam-microgea-rmm.dts
to avoid overriding the peripheral bus clock reference defined in the base
SoC device tree. Suggested by Sashiko.
- Reference the existing labeled nodes directly at the root level using
&sai1a and &sai1b in stm32mp257-engicam-microgea-rmm.dts instead of
redefining the entire node structure and redeclaring the labels. Suggested by Sashiko.
- Drop the #clock-cells property from sai1a and remove the reference to sai1a from
the clocks array in sai1b, relying strictly on the st,sync property to handle
internal synchronization.
Dario Binacchi (16):
dt-bindings: arm: stm32: support Engicam MicroGEA-STM32MP257-RMM board
arm64: dts: st: add power-domains to sdmmc1 on stm32mp231
arm64: dts: st: add power-domains to sdmmc1 on stm32mp251
arm64: dts: st: add SDMMC2 support on stm32mp25
arm64: dts: st: add CAN1 support on stm32mp25
arm64: dts: st: add i2c1 pins for stm32mp25
arm64: dts: st: add ltdc pins for stm32mp25
arm64: dts: st: add can1 pins for stm32mp25
arm64: dts: st: add pwm2/pwm4 pins for stm32mp25
arm64: dts: st: add sai1 pins for stm32mp25
arm64: dts: st: add sdmmc2 pins for stm32mp25
arm64: dts: st: add spi1 pins for stm32mp25
arm64: dts: st: add usart1 pins for stm32mp25
arm64: dts: st: support Engicam MicroGEA-STM32MP257 SoM
arm64: dts: st: support Engicam MicroGEA-STM32MP257-RMM board
arm64: defconfig: enable configs for Engicam MicroGEA-STM32MP257-RMM
.../devicetree/bindings/arm/stm32/stm32.yaml | 7 +
arch/arm64/boot/dts/st/Makefile | 1 +
arch/arm64/boot/dts/st/stm32mp231.dtsi | 1 +
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 328 ++++++++++++++++++
arch/arm64/boot/dts/st/stm32mp251.dtsi | 17 +
arch/arm64/boot/dts/st/stm32mp253.dtsi | 16 +
.../st/stm32mp257-engicam-microgea-rmm.dts | 319 +++++++++++++++++
.../dts/st/stm32mp257-engicam-microgea.dtsi | 63 ++++
arch/arm64/configs/defconfig | 4 +
9 files changed, 756 insertions(+)
create mode 100644 arch/arm64/boot/dts/st/stm32mp257-engicam-microgea-rmm.dts
create mode 100644 arch/arm64/boot/dts/st/stm32mp257-engicam-microgea.dtsi
--
2.43.0
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
branch: stm32mp257d-microgea
^ permalink raw reply
* [PATCH v6 11/16] arm64: dts: st: add sdmmc2 pins for stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add the sdmmc2 pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v5)
Changes in v5:
- Change SDMMC2_CK pin bias from pull-up to bias-disable to
avoid signal integrity issues on the clock line. Suggested by Sashiko
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 80 +++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 002fbc724b9d..c816a6aece47 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -622,6 +622,86 @@ pins {
};
};
+ /omit-if-no-ref/
+ sdmmc2_b4_pins_a: sdmmc2-b4-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('E', 13, AF12)>, /* SDMMC2_D0 */
+ <STM32_PINMUX('E', 11, AF12)>, /* SDMMC2_D1 */
+ <STM32_PINMUX('E', 8, AF12)>, /* SDMMC2_D2 */
+ <STM32_PINMUX('E', 12, AF12)>, /* SDMMC2_D3 */
+ <STM32_PINMUX('E', 15, AF12)>; /* SDMMC2_CMD */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('E', 14, AF12)>; /* SDMMC2_CK */
+ slew-rate = <2>;
+ drive-push-pull;
+ bias-disable;
+ };
+ };
+
+ /omit-if-no-ref/
+ sdmmc2_b4_od_pins_a: sdmmc2-b4-od-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('E', 13, AF12)>, /* SDMMC2_D0 */
+ <STM32_PINMUX('E', 11, AF12)>, /* SDMMC2_D1 */
+ <STM32_PINMUX('E', 8, AF12)>, /* SDMMC2_D2 */
+ <STM32_PINMUX('E', 12, AF12)>; /* SDMMC2_D3 */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('E', 14, AF12)>; /* SDMMC2_CK */
+ slew-rate = <2>;
+ drive-push-pull;
+ bias-disable;
+ };
+ pins3 {
+ pinmux = <STM32_PINMUX('E', 15, AF12)>; /* SDMMC2_CMD */
+ slew-rate = <1>;
+ drive-open-drain;
+ bias-pull-up;
+ };
+ };
+
+ /omit-if-no-ref/
+ sdmmc2_b4_sleep_pins_a: sdmmc2-b4-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('E', 13, ANALOG)>, /* SDMMC2_D0 */
+ <STM32_PINMUX('E', 11, ANALOG)>, /* SDMMC2_D1 */
+ <STM32_PINMUX('E', 8, ANALOG)>, /* SDMMC2_D2 */
+ <STM32_PINMUX('E', 12, ANALOG)>, /* SDMMC2_D3 */
+ <STM32_PINMUX('E', 14, ANALOG)>, /* SDMMC2_CK */
+ <STM32_PINMUX('E', 15, ANALOG)>; /* SDMMC2_CMD */
+ };
+ };
+
+ /omit-if-no-ref/
+ sdmmc2_d47_pins_a: sdmmc2-d47-0 {
+ pins {
+ pinmux = <STM32_PINMUX('E', 10, AF12)>, /* SDMMC2_D4 */
+ <STM32_PINMUX('E', 9, AF12)>, /* SDMMC2_D5 */
+ <STM32_PINMUX('E', 6, AF12)>, /* SDMMC2_D6 */
+ <STM32_PINMUX('E', 7, AF12)>; /* SDMMC2_D7 */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ };
+
+ /omit-if-no-ref/
+ sdmmc2_d47_sleep_pins_a: sdmmc2-d47-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('E', 10, ANALOG)>, /* SDMMC2_D4 */
+ <STM32_PINMUX('E', 9, ANALOG)>, /* SDMMC2_D5 */
+ <STM32_PINMUX('E', 6, ANALOG)>, /* SDMMC2_D6 */
+ <STM32_PINMUX('E', 7, ANALOG)>; /* SDMMC2_D7 */
+ };
+ };
+
/omit-if-no-ref/
spi3_pins_a: spi3-0 {
pins1 {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 01/16] dt-bindings: arm: stm32: support Engicam MicroGEA-STM32MP257-RMM board
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Conor Dooley, Alexandre Torgue, Amelie Delaunay,
Christophe Parant, Conor Dooley, Himanshu Bhavani,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add devicetree bindings for Engicam MicroGEA-STM32MP257-RMM board based
on the Engicam MicroGEA-STM32MP257 SoM (System-on-Module).
The use of an enum for a single element is justified by the future
addition of other boards based on the same SoM.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
(no changes since v2)
Changes in v2:
- Add Acked-by of Conor Dooley for patch 0/1 "dt-bindings: arm: stm32:
support Engicam MicroGEA-STM32MP257-RMM board"
Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index c6af3a46364f..c5ce81e3ce45 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -203,6 +203,13 @@ properties:
- st,stm32mp257f-ev1
- const: st,stm32mp257
+ - description: Engicam MicroGEA STM32MP257 SoM based Boards
+ items:
+ - enum:
+ - engicam,microgea-stm32mp257-rmm
+ - const: engicam,microgea-stm32mp257
+ - const: st,stm32mp257
+
- description: ST STM32MP235 based Boards
items:
- enum:
--
2.43.0
^ permalink raw reply related
* [PATCH v6 09/16] arm64: dts: st: add pwm2/pwm4 pins for stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add the pwm2 and pwm4 pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v1)
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 6482dd47e977..695c9d771853 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -433,6 +433,23 @@ pins {
};
};
+ /omit-if-no-ref/
+ pwm2_pins_a: pwm2-0 {
+ pins {
+ pinmux = <STM32_PINMUX('I', 7, AF7)>; /* TIM2_CH1 */
+ bias-pull-down;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ };
+
+ /omit-if-no-ref/
+ pwm2_sleep_pins_a: pwm2-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('I', 7, ANALOG)>; /* TIM2_CH1 */
+ };
+ };
+
/omit-if-no-ref/
pwm3_pins_a: pwm3-0 {
pins {
@@ -450,6 +467,23 @@ pins {
};
};
+ /omit-if-no-ref/
+ pwm4_pins_a: pwm4-0 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 12, AF7)>; /* TIM4_CH1 */
+ bias-pull-down;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ };
+
+ /omit-if-no-ref/
+ pwm4_sleep_pins_a: pwm4-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 12, ANALOG)>; /* TIM4_CH1 */
+ };
+ };
+
/omit-if-no-ref/
pwm8_pins_a: pwm8-0 {
pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 07/16] arm64: dts: st: add ltdc pins for stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
Add the LTDC pins used on MicroGEA-STM32MP257-RMM board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v5)
Changes in v5:
- Increase slew-rate to <1> to support the 27 MHz pixel clock and
prevent timing violations. Suggested by Sashiko
arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index db485b9ed904..50f454630cf2 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -260,6 +260,77 @@ pins {
};
};
+ /omit-if-no-ref/
+ ltdc_pins_a: ltdc-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 6, AF14)>, /* LCD_CLK */
+ <STM32_PINMUX('G', 2, AF13)>, /* LCD_HSYNC */
+ <STM32_PINMUX('G', 1, AF13)>, /* LCD_VSYNC */
+ <STM32_PINMUX('C', 5, AF14)>, /* LCD_DE */
+ <STM32_PINMUX('H', 4, AF10)>, /* LCD_R0 */
+ <STM32_PINMUX('F', 7, AF13)>, /* LCD_R1 */
+ <STM32_PINMUX('C', 11, AF13)>, /* LCD_R2 */
+ <STM32_PINMUX('A', 1, AF11)>, /* LCD_R3 */
+ <STM32_PINMUX('B', 15, AF13)>, /* LCD_R4 */
+ <STM32_PINMUX('G', 3, AF13)>, /* LCD_R5 */
+ <STM32_PINMUX('A', 10, AF12)>, /* LCD_R6 */
+ <STM32_PINMUX('G', 7, AF13)>, /* LCD_R7 */
+ <STM32_PINMUX('F', 8, AF13)>, /* LCD_G0 */
+ <STM32_PINMUX('H', 5, AF10)>, /* LCD_G1 */
+ <STM32_PINMUX('C', 9, AF13)>, /* LCD_G2 */
+ <STM32_PINMUX('C', 10, AF13)>, /* LCD_G3 */
+ <STM32_PINMUX('A', 6, AF10)>, /* LCD_G4 */
+ <STM32_PINMUX('G', 11, AF13)>, /* LCD_G5 */
+ <STM32_PINMUX('G', 12, AF13)>, /* LCD_G6 */
+ <STM32_PINMUX('A', 9, AF12)>, /* LCD_G7 */
+ <STM32_PINMUX('F', 6, AF13)>, /* LCD_B0 */
+ <STM32_PINMUX('A', 3, AF11)>, /* LCD_B1 */
+ <STM32_PINMUX('G', 15, AF13)>, /* LCD_B2 */
+ <STM32_PINMUX('I', 0, AF13)>, /* LCD_B3 */
+ <STM32_PINMUX('I', 1, AF13)>, /* LCD_B4 */
+ <STM32_PINMUX('A', 7, AF10)>, /* LCD_B5 */
+ <STM32_PINMUX('F', 5, AF13)>, /* LCD_B6 */
+ <STM32_PINMUX('I', 4, AF13)>; /* LCD_B7 */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <1>;
+ };
+ };
+
+ /omit-if-no-ref/
+ ltdc_sleep_pins_a: ltdc-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 6, ANALOG)>, /* LCD_CLK */
+ <STM32_PINMUX('G', 2, ANALOG)>, /* LCD_HSYNC */
+ <STM32_PINMUX('G', 1, ANALOG)>, /* LCD_VSYNC */
+ <STM32_PINMUX('C', 5, ANALOG)>, /* LCD_DE */
+ <STM32_PINMUX('H', 4, ANALOG)>, /* LCD_R0 */
+ <STM32_PINMUX('F', 7, ANALOG)>, /* LCD_R1 */
+ <STM32_PINMUX('C', 11, ANALOG)>, /* LCD_R2 */
+ <STM32_PINMUX('A', 1, ANALOG)>, /* LCD_R3 */
+ <STM32_PINMUX('B', 15, ANALOG)>, /* LCD_R4 */
+ <STM32_PINMUX('G', 3, ANALOG)>, /* LCD_R5 */
+ <STM32_PINMUX('A', 10, ANALOG)>, /* LCD_R6 */
+ <STM32_PINMUX('G', 7, ANALOG)>, /* LCD_R7 */
+ <STM32_PINMUX('F', 8, ANALOG)>, /* LCD_G0 */
+ <STM32_PINMUX('H', 5, ANALOG)>, /* LCD_G1 */
+ <STM32_PINMUX('C', 9, ANALOG)>, /* LCD_G2 */
+ <STM32_PINMUX('C', 10, ANALOG)>, /* LCD_G3 */
+ <STM32_PINMUX('A', 6, ANALOG)>, /* LCD_G4 */
+ <STM32_PINMUX('G', 11, ANALOG)>, /* LCD_G5 */
+ <STM32_PINMUX('G', 12, ANALOG)>, /* LCD_G6 */
+ <STM32_PINMUX('A', 9, ANALOG)>, /* LCD_G7 */
+ <STM32_PINMUX('F', 6, ANALOG)>, /* LCD_B0 */
+ <STM32_PINMUX('A', 3, ANALOG)>, /* LCD_B1 */
+ <STM32_PINMUX('G', 15, ANALOG)>, /* LCD_B2 */
+ <STM32_PINMUX('I', 0, ANALOG)>, /* LCD_B3 */
+ <STM32_PINMUX('I', 1, ANALOG)>, /* LCD_B4 */
+ <STM32_PINMUX('A', 7, ANALOG)>, /* LCD_B5 */
+ <STM32_PINMUX('F', 5, ANALOG)>, /* LCD_B6 */
+ <STM32_PINMUX('I', 4, ANALOG)>; /* LCD_B7 */
+ };
+ };
+
/omit-if-no-ref/
ospi_port1_clk_pins_a: ospi-port1-clk-0 {
pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 05/16] arm64: dts: st: add CAN1 support on stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
The controller is compliant with ISO 11898-1: 2015 (CAN protocol
specification version 2.0 part A, B) and CAN FD protocol specification
version 1.0.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v2)
Changes in v2:
- Add resets property to dts CAN node. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp253.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi b/arch/arm64/boot/dts/st/stm32mp253.dtsi
index eeceb086252b..7e82f01fdc10 100644
--- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
@@ -43,6 +43,22 @@ &optee {
};
&rifsc {
+ m_can1: can@402d0000 {
+ compatible = "bosch,m_can";
+ reg = <0x402d0000 0x400>, <0x40310000 0xd50>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&rcc CK_BUS_FDCAN>, <&rcc CK_KER_FDCAN>;
+ clock-names = "hclk", "cclk";
+ resets = <&rcc FDCAN_R>;
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ access-controllers = <&rifsc 56>;
+ power-domains = <&CLUSTER_PD>;
+ status = "disabled";
+ };
+
ethernet2: ethernet@482d0000 {
compatible = "st,stm32mp25-dwmac", "snps,dwmac-5.20";
reg = <0x482d0000 0x4000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 04/16] arm64: dts: st: add SDMMC2 support on stm32mp25
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
The SDMMC2 controller supports SD cards, eMMC memories and SDIO devices.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v3)
Changes in v3:
- Add power-domains property. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp251.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index ae36d703532c..44938c036e30 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -1668,6 +1668,22 @@ sdmmc1: mmc@48220000 {
status = "disabled";
};
+ sdmmc2: mmc@48230000 {
+ compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00353180>;
+ reg = <0x48230000 0x400>, <0x44230800 0x8>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc CK_KER_SDMMC2>;
+ clock-names = "apb_pclk";
+ resets = <&rcc SDMMC2_R>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <120000000>;
+ access-controllers = <&rifsc 77>;
+ power-domains = <&CLUSTER_PD>;
+ status = "disabled";
+ };
+
ethernet1: ethernet@482c0000 {
compatible = "st,stm32mp25-dwmac", "snps,dwmac-5.20";
reg = <0x482c0000 0x4000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 02/16] arm64: dts: st: add power-domains to sdmmc1 on stm32mp231
From: Dario Binacchi @ 2026-06-30 9:24 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, francesco.utel, michael, domenico.acri,
Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260630092628.1695560-1-dario.binacchi@amarulasolutions.com>
The sdmmc1 node was introduced early in the SoC bring-up before power
domains were systematically mapped. Add the missing power-domains
property to align it with the rest of the peripheral nodes.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v5)
Changes in v5:
- Added in version 5. Suggested by Sashiko.
arch/arm64/boot/dts/st/stm32mp231.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/st/stm32mp231.dtsi b/arch/arm64/boot/dts/st/stm32mp231.dtsi
index 9e1d240888ff..0feb8943efae 100644
--- a/arch/arm64/boot/dts/st/stm32mp231.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp231.dtsi
@@ -727,6 +727,7 @@ sdmmc1: mmc@48220000 {
cap-mmc-highspeed;
max-frequency = <120000000>;
access-controllers = <&rifsc 76>;
+ power-domains = <&cluster_pd>;
status = "disabled";
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 6/7] ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Describe the QSPI flash SFDP as an NVMEM provider with the
microchip,sst26vf-sfdp-eui layout, which exposes the factory-programmed
EUI-48 as a "mac-address" cell, and point macb0 at it through
nvmem-cells. This yields a stable MAC address on boards where U-Boot does
not program one, instead of falling back to a random address.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi | 11 +++++++++++
.../boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts | 2 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 062aa02a98ed..6016d7f2a39c 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -240,6 +240,17 @@ qspi1_flash: flash@0 {
m25p,fast-read;
status = "disabled";
+ sfdp {
+ compatible = "jedec,sfdp";
+
+ nvmem-layout {
+ compatible = "microchip,sst26vf-sfdp-eui";
+
+ mac_address_eui48: mac-address {
+ };
+ };
+ };
+
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
index 35a933eec573..5e87bf04bc47 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
@@ -97,6 +97,8 @@ uart6: serial@200 {
&macb0 {
status = "okay";
+ nvmem-cells = <&mac_address_eui48>;
+ nvmem-cell-names = "mac-address";
};
&pioA {
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/7] nvmem: layouts: add Microchip/SST SFDP EUI layout driver
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Add an NVMEM layout that exposes the factory-programmed EUI-48 identifier
from the Microchip/SST vendor SFDP parameter table (e.g. SST26VF064BEUI)
as a "mac-address" cell, for use as a network MAC address. The vendor
table is located at runtime via the SFDP NVMEM device (no offset in DT),
and a read_post_process callback reverses the LSB-first bytes into
canonical MAC order. Binds to an "nvmem-layout" node with compatible
"microchip,sst26vf-sfdp-eui".
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
MAINTAINERS | 6 +
drivers/nvmem/layouts/Kconfig | 10 ++
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 +++++++++++++++++++++++
4 files changed, 199 insertions(+)
create mode 100644 drivers/nvmem/layouts/sst26vf-sfdp-eui.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..dc3411b0c3b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17812,6 +17812,12 @@ F: Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
+MICROCHIP SST SFDP EUI NVMEM LAYOUT DRIVER
+M: Manikandan Muralidharan <manikandan.m@microchip.com>
+S: Maintained
+F: Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
+F: drivers/nvmem/layouts/sst26vf-sfdp-eui.c
+
Microchip Timer Counter Block (TCB) Capture Driver
M: Kamel Bouhara <kamel.bouhara@bootlin.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 5e586dfebe47..855c7db530da 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -26,6 +26,16 @@ config NVMEM_LAYOUT_ONIE_TLV
If unsure, say N.
+config NVMEM_LAYOUT_SST26VF_SFDP_EUI
+ tristate "Microchip/SST SFDP EUI-48 layout support"
+ help
+ Say Y here if you want to expose the factory-programmed EUI-48
+ identifier stored in the Microchip/SST vendor-specific SFDP parameter
+ table (e.g. SST26VF064BEUI) as NVMEM cells, so that network drivers
+ can use them as a MAC address.
+
+ If unsure, say N.
+
config NVMEM_LAYOUT_U_BOOT_ENV
tristate "U-Boot environment variables layout"
select CRC32
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 4940c9db0665..b99eac1f63f2 100644
--- a/drivers/nvmem/layouts/Makefile
+++ b/drivers/nvmem/layouts/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o
obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o
+obj-$(CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI) += sst26vf-sfdp-eui.o
obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o
diff --git a/drivers/nvmem/layouts/sst26vf-sfdp-eui.c b/drivers/nvmem/layouts/sst26vf-sfdp-eui.c
new file mode 100644
index 000000000000..641318d6f0af
--- /dev/null
+++ b/drivers/nvmem/layouts/sst26vf-sfdp-eui.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NVMEM layout for the factory-programmed EUI-48 identifier stored in the
+ * Microchip/SST vendor-specific SFDP parameter table (e.g. SST26VF064BEUI).
+ *
+ * The whole SFDP is exposed as a read-only NVMEM device by the SPI NOR core.
+ * This layout locates the Microchip vendor parameter table at runtime and
+ * registers the EUI-48 address as an NVMEM cell, so that a network driver can
+ * consume it as a MAC address. No offset is hardcoded in the device tree.
+ *
+ * Copyright (C) 2026 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan <manikandan.m@microchip.com>
+ */
+
+#include <linux/etherdevice.h>
+#include <linux/minmax.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/unaligned.h>
+#include <uapi/linux/if_ether.h>
+
+/* SFDP header and parameter header, as laid out on the flash. */
+struct sfdp_header {
+ u8 signature[4];
+ u8 minor;
+ u8 major;
+ u8 nph;
+ u8 unused;
+};
+
+struct sfdp_parameter_header {
+ u8 id_lsb;
+ u8 minor;
+ u8 major;
+ u8 length;
+ u8 parameter_table_pointer[3];
+ u8 id_msb;
+};
+
+#define SFDP_SIGNATURE 0x50444653U
+
+#define SFDP_PARAM_HEADER_ID(h) (((h)->id_msb << 8) | (h)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(h) get_unaligned_le24((h)->parameter_table_pointer)
+
+/* Microchip (vendor) parameter table identifier: id_msb << 8 | id_lsb. */
+#define SFDP_MCHP_VENDOR_ID 0x01bf
+
+#define SFDP_MCHP_EUI48_MARKER_OFFSET 0x60
+#define SFDP_MCHP_EUI48_MARKER 0x30
+#define SFDP_MCHP_EUI48_OFFSET 0x61
+
+static int sfdp_eui_read_post_process(void *priv, const char *id, int index,
+ unsigned int offset, void *buf,
+ size_t bytes)
+{
+ u8 *data = buf;
+ int i;
+
+ /* SFDP stores the address least-significant octet first; reverse it. */
+ for (i = 0; i < bytes / 2; i++)
+ swap(data[i], data[bytes - 1 - i]);
+
+ if (bytes == ETH_ALEN && !is_valid_ether_addr(buf))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int sfdp_eui_find_vendor_table(struct nvmem_device *nvmem, u32 *ptp)
+{
+ struct sfdp_parameter_header ph;
+ struct sfdp_header hdr;
+ int nph, i, ret;
+
+ ret = nvmem_device_read(nvmem, 0, sizeof(hdr), &hdr);
+ if (ret < 0)
+ return ret;
+
+ if (get_unaligned_le32(hdr.signature) != SFDP_SIGNATURE)
+ return -EINVAL;
+
+ /* The number of parameter headers (NPH) field is zero-based. */
+ nph = hdr.nph;
+
+ for (i = 0; i <= nph; i++) {
+ ret = nvmem_device_read(nvmem, sizeof(hdr) + i * sizeof(ph),
+ sizeof(ph), &ph);
+ if (ret < 0)
+ return ret;
+
+ if (SFDP_PARAM_HEADER_ID(&ph) != SFDP_MCHP_VENDOR_ID)
+ continue;
+
+ *ptp = SFDP_PARAM_HEADER_PTP(&ph);
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+static int sfdp_eui_add_cells(struct nvmem_layout *layout)
+{
+ struct nvmem_device *nvmem = layout->nvmem;
+ struct device *dev = &layout->dev;
+ struct nvmem_cell_info info = { };
+ struct device_node *layout_np;
+ u32 base = 0;
+ u8 marker;
+ int ret;
+
+ ret = sfdp_eui_find_vendor_table(nvmem, &base);
+ if (ret == -ENOENT) {
+ dev_dbg(dev, "no Microchip SFDP vendor table found\n");
+ return 0;
+ }
+ if (ret)
+ return ret;
+
+ /* The EUI-48 is present only if its marker byte is programmed. */
+ ret = nvmem_device_read(nvmem, base + SFDP_MCHP_EUI48_MARKER_OFFSET,
+ 1, &marker);
+ if (ret < 0)
+ return ret;
+ if (marker != SFDP_MCHP_EUI48_MARKER) {
+ dev_dbg(dev, "EUI-48 not programmed (marker 0x%02x)\n", marker);
+ return 0;
+ }
+
+ layout_np = of_nvmem_layout_get_container(nvmem);
+ if (!layout_np)
+ return -ENOENT;
+
+ info.name = "mac-address";
+ info.offset = base + SFDP_MCHP_EUI48_OFFSET;
+ info.bytes = ETH_ALEN;
+ info.np = of_get_child_by_name(layout_np, "mac-address");
+ info.read_post_process = sfdp_eui_read_post_process;
+
+ ret = nvmem_add_one_cell(nvmem, &info);
+ if (ret)
+ of_node_put(info.np);
+ else
+ dev_dbg(dev, "exposed EUI-48 at SFDP offset 0x%x\n", info.offset);
+
+ of_node_put(layout_np);
+
+ return ret;
+}
+
+static int sfdp_eui_probe(struct nvmem_layout *layout)
+{
+ layout->add_cells = sfdp_eui_add_cells;
+
+ return nvmem_layout_register(layout);
+}
+
+static void sfdp_eui_remove(struct nvmem_layout *layout)
+{
+ nvmem_layout_unregister(layout);
+}
+
+static const struct of_device_id sfdp_eui_of_match_table[] = {
+ { .compatible = "microchip,sst26vf-sfdp-eui" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sfdp_eui_of_match_table);
+
+static struct nvmem_layout_driver sfdp_eui_layout = {
+ .driver = {
+ .name = "microchip-sst26vf-sfdp-eui-layout",
+ .of_match_table = sfdp_eui_of_match_table,
+ },
+ .probe = sfdp_eui_probe,
+ .remove = sfdp_eui_remove,
+};
+module_nvmem_layout_driver(sfdp_eui_layout);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Manikandan Muralidharan <manikandan.m@microchip.com>");
+MODULE_DESCRIPTION("NVMEM layout for the EUI-48 in the Microchip/SST SFDP vendor table");
--
2.43.0
^ permalink raw reply related
* [PATCH v4 5/7] ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI flash
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Move the QSPI flash partitions under a "partitions" node with the
"fixed-partitions" compatible, as required by the current MTD partition
binding, instead of declaring them as direct children of the flash node.
No functional change.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
.../dts/microchip/at91-sama5d27_wlsom1.dtsi | 52 +++++++++++--------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 0417f53b3e96..062aa02a98ed 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -240,34 +240,40 @@ qspi1_flash: flash@0 {
m25p,fast-read;
status = "disabled";
- at91bootstrap@0 {
- label = "at91bootstrap";
- reg = <0x0 0x40000>;
- };
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
- bootloader@40000 {
- label = "bootloader";
- reg = <0x40000 0xc0000>;
- };
+ bootloader@40000 {
+ label = "bootloader";
+ reg = <0x40000 0xc0000>;
+ };
- bootloaderenvred@100000 {
- label = "bootloader env redundant";
- reg = <0x100000 0x40000>;
- };
+ bootloaderenvred@100000 {
+ label = "bootloader env redundant";
+ reg = <0x100000 0x40000>;
+ };
- bootloaderenv@140000 {
- label = "bootloader env";
- reg = <0x140000 0x40000>;
- };
+ bootloaderenv@140000 {
+ label = "bootloader env";
+ reg = <0x140000 0x40000>;
+ };
- dtb@180000 {
- label = "device tree";
- reg = <0x180000 0x80000>;
- };
+ dtb@180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
- kernel@200000 {
- label = "kernel";
- reg = <0x200000 0x600000>;
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
};
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Register the cached SFDP as a read-only NVMEM device rooted at the
flash's "sfdp" child node, exposing it in on-flash byte order. This lets
NVMEM cells reference any SFDP data: a fixed-layout for parameters at a
known offset, or an nvmem-layout parser for vendor data whose location
must be discovered at runtime. The device is only registered when an
"sfdp" node is present in the device tree.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
drivers/mtd/spi-nor/core.c | 5 +++
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 83 ++++++++++++++++++++++++++++++++++++++
3 files changed, 89 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..e04ba3e3dee9 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3204,6 +3204,11 @@ static int spi_nor_init_params(struct spi_nor *nor)
spi_nor_init_params_deprecated(nor);
}
+ /* Expose the SFDP as an NVMEM device. */
+ ret = spi_nor_register_sfdp_nvmem(nor);
+ if (ret)
+ return ret;
+
ret = spi_nor_late_init_params(nor);
if (ret)
return ret;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index ba2d1a862c9d..0a6484298c5c 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -698,6 +698,7 @@ int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
int spi_nor_check_sfdp_signature(struct spi_nor *nor);
int spi_nor_parse_sfdp(struct spi_nor *nor);
+int spi_nor_register_sfdp_nvmem(struct spi_nor *nor);
static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
{
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 4600983cb579..2df818bca6b5 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -6,6 +6,8 @@
#include <linux/bitfield.h>
#include <linux/mtd/spi-nor.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
#include <linux/slab.h>
#include <linux/sort.h>
@@ -1612,3 +1614,84 @@ int spi_nor_parse_sfdp(struct spi_nor *nor)
kfree(param_headers);
return err;
}
+
+static int spi_nor_sfdp_nvmem_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct spi_nor *nor = priv;
+ struct sfdp *sfdp = nor->sfdp;
+ size_t sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
+
+ if (offset >= sfdp_size || bytes > sfdp_size - offset)
+ return -EINVAL;
+
+ /* The cached SFDP is kept in on-flash (little-endian) byte order. */
+ memcpy(val, (u8 *)sfdp->dwords + offset, bytes);
+
+ return 0;
+}
+
+static void spi_nor_sfdp_nvmem_put_np(void *data)
+{
+ of_node_put(data);
+}
+
+/**
+ * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
+ * rooted at the flash's "sfdp" child node. This lets generic (fixed-layout) or
+ * vendor (nvmem-layout) cells reference any SFDP data. The device is only
+ * registered when an "sfdp" node is described in the device tree.
+ *
+ * Return: 0 on success or if there is nothing to do, -errno otherwise.
+ */
+int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
+{
+ struct device *dev = nor->dev;
+ struct nvmem_config config = { };
+ struct nvmem_device *nvmem;
+ struct device_node *np;
+ int ret;
+
+ if (!nor->sfdp)
+ return 0;
+
+ np = of_get_child_by_name(dev_of_node(dev), "sfdp");
+ if (!np)
+ return 0;
+
+ /*
+ * Register the put before devm_nvmem_register() so it runs last on
+ * detach, after the NVMEM device that uses the node is gone.
+ */
+ ret = devm_add_action_or_reset(dev, spi_nor_sfdp_nvmem_put_np, np);
+ if (ret)
+ return ret;
+
+ config.dev = dev;
+ config.of_node = np;
+ config.name = "sfdp";
+ config.id = NVMEM_DEVID_AUTO;
+ config.owner = THIS_MODULE;
+ config.read_only = true;
+ config.word_size = 1;
+ config.stride = 1;
+ config.size = (int)(nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords));
+ config.reg_read = spi_nor_sfdp_nvmem_read;
+ config.priv = nor;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem)) {
+ /* NVMEM support is optional. */
+ if (PTR_ERR(nvmem) == -EOPNOTSUPP)
+ return 0;
+ return dev_err_probe(dev, PTR_ERR(nvmem),
+ "failed to register SFDP NVMEM device\n");
+ }
+
+ dev_dbg(dev, "exposed %d-byte SFDP as an NVMEM device\n", config.size);
+
+ return 0;
+}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/7] dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Add a binding for the NVMEM layout that exposes the factory-programmed
EUI-48 identifier from the Microchip/SST vendor-specific SFDP parameter
table (e.g. SST26VF064BEUI) as a "mac-address" NVMEM cell, and reference
it from nvmem-layout.yaml.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
.../layouts/microchip,sst26vf-sfdp-eui.yaml | 60 +++++++++++++++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
2 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml b/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
new file mode 100644
index 000000000000..37357efb7840
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the Microchip/SST SFDP EUI-48 identifier
+
+maintainers:
+ - Manikandan Muralidharan <manikandan.m@microchip.com>
+
+description:
+ Some Microchip/SST serial flashes (for example the SST26VF064BEUI) are
+ factory programmed with a globally unique EUI-48 identifier stored in a
+ vendor-specific SFDP parameter table and permanently write-protected. This
+ layout locates that table and exposes the EUI-48 as an NVMEM cell so that,
+ for example, a network driver can use it as a MAC address. The location of
+ the data is discovered at runtime from the SFDP; no offset is encoded in the
+ device tree.
+
+select: false
+
+properties:
+ compatible:
+ const: microchip,sst26vf-sfdp-eui
+
+ mac-address:
+ type: object
+ description:
+ The factory-programmed EUI-48 identifier, usable as a MAC address.
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+
+ sfdp {
+ compatible = "jedec,sfdp";
+
+ nvmem-layout {
+ compatible = "microchip,sst26vf-sfdp-eui";
+
+ mac-address {
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index 382507060651..e63b93083821 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -20,6 +20,7 @@ description: |
oneOf:
- $ref: fixed-layout.yaml
- $ref: kontron,sl28-vpd.yaml
+ - $ref: microchip,sst26vf-sfdp-eui.yaml
- $ref: onie,tlv-layout.yaml
- $ref: u-boot,env.yaml
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan Muralidharan @ 2026-06-30 9:24 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260630092406.150587-1-manikandan.m@microchip.com>
Add an optional "sfdp" child node (compatible "jedec,sfdp") that
describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
.../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 587af4968255..98fd954598ab 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -103,6 +103,20 @@ properties:
spi-cpol: true
spi-cpha: true
+ sfdp:
+ $ref: /schemas/nvmem/nvmem.yaml#
+ unevaluatedProperties: false
+ description:
+ The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
+ read-only NVMEM device. This allows standard or vendor-specific SFDP
+ data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
+ consumed through NVMEM cells.
+ properties:
+ compatible:
+ const: jedec,sfdp
+ required:
+ - compatible
+
dependencies:
spi-cpol: [ spi-cpha ]
spi-cpha: [ spi-cpol ]
@@ -122,6 +136,10 @@ examples:
spi-max-frequency = <40000000>;
m25p,fast-read;
reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+
+ sfdp {
+ compatible = "jedec,sfdp";
+ };
};
};
...
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] firmware: arm_ffa: Handle maximum RX/TX buffer size
From: Sudeep Holla @ 2026-06-30 9:24 UTC (permalink / raw)
To: Sebastian Ene, Seth Forshee; +Cc: Sudeep Holla, linux-arm-kernel, linux-kernel
In-Reply-To: <20260602-b4-ffa-rxtx-map-fixes-v2-1-7cb06508da84@nvidia.com>
On Tue, 02 Jun 2026 21:54:06 +0000, Seth Forshee wrote:
> A partition manager may reject unsupported RX/TX buffer sizes by
> returning INVALID_PARAMETERS. Commit 83210251fd70 ("firmware: arm_ffa:
> Use the correct buffer size during RXTX_MAP") has the effect of rounding
> up the buffer size from FFA_FEATURES to be PAGE_SIZE-aligned, which may
> be larger than what the partition manager supports. This caused RXTX_MAP
> to fail for some FF-A implementations on kernels with PAGE_SIZE > 4K.
>
> [...]
Applied to sudeep.holla/linux (for-next/ffa/fixes), thanks!
[1/1] firmware: arm_ffa: Handle maximum RX/TX buffer size
https://git.kernel.org/sudeep.holla/c/53716a4d745f
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v4 0/7] Read MAC address from SST vendor specific SFDP region
From: Manikandan Muralidharan @ 2026-06-30 9:23 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
Some Microchip/SST QSPI flashes (e.g. the SST26VF064BEUI) are factory
programmed with globally unique, write-protected EUI-48 and EUI-64
identifiers stored in a vendor-specific SFDP parameter table. On boards
that have no on-board EEPROM (sama5d27_wlsom1, sama5d29 curiosity,
sam9x75 curiosity) this is a reliable source for an Ethernet MAC address,
instead of relying on a U-Boot-provided or random address.
This v4 reworks the approach into a generic NVMEM framework with no vendor
code in the SPI NOR core:
- The SPI NOR core now exposes the entire SFDP as a generic read-only
NVMEM device, rooted at a new "sfdp" child node of the flash.
- A new NVMEM layout driver (drivers/nvmem/layouts/) locates the
Microchip vendor parameter table at runtime and presents the EUI-48 as
a "mac-address" cell.
- Arbitrary parameters can be read with a standard fixed-layout
(known offset) or with an nvmem-layout parser (location discovered at runtime).
Changes in v4:
- Rework per v3 review: remove the vendor-specific SFDP handling from the
SPI NOR core; expose the whole SFDP as a generic read-only NVMEM device
and move the EUI extraction into an nvmem-layout driver.
- Introduce a new nvmem-layout driver to discover the vendor-table location
at runtime; no offset hardcoded in the device tree.
- Describe the SFDP via a dedicated "sfdp" subnode (compatible
"jedec,sfdp"), which also resolves the v3 dtbs_check "Unevaluated
properties ('nvmem-layout')" warning.
- Reverse the stored EUI bytes into canonical MAC order.
- Enable the layout in sama5_defconfig.
Changes in v3:
- 2/3 - add support to update the QSPI partition into 'fixed-partition'
binding in sama5d27_wlsom1
- 3/3 - add nvmem-layout in qspi node for EUI48 MAC Address and nvmem cell
properties for macb node in sama5d27_wlsom1
Changes in v2:
- 1/3 - parse the SST vendor table, read and store the addresses
into a resource - managed space. Register the addresses
into NVMEM framework
- 2/3 - add support to update the QSPI partition into 'fixed-partition'
binding
v3: https://lore.kernel.org/linux-arm-kernel/20250521070336.402202-1-manikandan.m@microchip.com/
Manikandan Muralidharan (7):
dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via
NVMEM
dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout
mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
nvmem: layouts: add Microchip/SST SFDP EUI layout driver
ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI
flash
ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout
.../bindings/mtd/jedec,spi-nor.yaml | 18 ++
.../layouts/microchip,sst26vf-sfdp-eui.yaml | 60 ++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
MAINTAINERS | 6 +
.../dts/microchip/at91-sama5d27_wlsom1.dtsi | 61 +++---
.../dts/microchip/at91-sama5d27_wlsom1_ek.dts | 2 +
arch/arm/configs/sama5_defconfig | 1 +
drivers/mtd/spi-nor/core.c | 5 +
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 83 ++++++++
drivers/nvmem/layouts/Kconfig | 10 +
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 ++++++++++++++++++
13 files changed, 409 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
create mode 100644 drivers/nvmem/layouts/sst26vf-sfdp-eui.c
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.43.0
^ permalink raw reply
* [PATCH 3/9] firmware: arm_scmi: Clean up channels on setup failure
From: Sudeep Holla @ 2026-06-30 9:05 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel
Cc: Cristian Marussi, Sudeep Holla, Sashiko, Sudeep Holla
In-Reply-To: <20260630-scmi_core_fixes-v1-0-f932c1e51992@kernel.org>
scmi_channels_setup() can fail after the common BASE channel or earlier
protocol channels have already been registered in the TX/RX IDRs.
Route this failure through the existing channel cleanup label so the
transport channels, transport devices and IDR state created before the
failure are released before the probe error path frees the SCMI instance
ID.
Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b9ba566fc759..861087b2920e 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -3262,7 +3262,7 @@ static int scmi_probe(struct platform_device *pdev)
ret = scmi_channels_setup(info);
if (ret) {
err_str = "failed to setup channels\n";
- goto clear_ida;
+ goto clear_txrx_setup;
}
ret = bus_register_notifier(&scmi_bus_type, &info->bus_nb);
@@ -3377,7 +3377,6 @@ static int scmi_probe(struct platform_device *pdev)
bus_unregister_notifier(&scmi_bus_type, &info->bus_nb);
clear_txrx_setup:
scmi_cleanup_txrx_channels(info);
-clear_ida:
ida_free(&scmi_id, info->id);
out_err:
--
2.43.0
^ permalink raw reply related
* [PATCH 5/9] firmware: arm_scmi: Free transport channel on IDR failure
From: Sudeep Holla @ 2026-06-30 9:06 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel
Cc: Cristian Marussi, Sudeep Holla, Sashiko, Sudeep Holla
In-Reply-To: <20260630-scmi_core_fixes-v1-0-f932c1e51992@kernel.org>
If transport channel setup succeeds but the following IDR insertion fails,
the error path destroys the transport device and frees the channel info
without invoking the transport cleanup callback.
Call chan_free() before destroying the device so transport specific
resources such as IRQs, mailbox channels and mapped shared memory are
released consistently with the normal teardown path.
Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 861087b2920e..4b369b003003 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2808,6 +2808,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
"unable to allocate SCMI idr slot err %d\n", ret);
/* Destroy channel and device only if created by this call. */
if (tdev) {
+ info->desc->ops->chan_free(prot_id, cinfo, idr);
scmi_device_destroy(info->dev, prot_id, name);
devm_kfree(info->dev, cinfo);
}
--
2.43.0
^ permalink raw reply related
* [PATCH 4/9] firmware: arm_scmi: Fix SCMI device destroy lifetimes
From: Sudeep Holla @ 2026-06-30 9:06 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel
Cc: Cristian Marussi, Sudeep Holla, Sashiko, Sudeep Holla
In-Reply-To: <20260630-scmi_core_fixes-v1-0-f932c1e51992@kernel.org>
scmi_child_dev_find() drops the reference returned by
device_find_child() before returning the scmi_device pointer. A
concurrent unregister can then release the device while the destroy path
is still using the returned pointer.
Make the lookup helper return the device_find_child() reference and keep
it until scmi_device_destroy() has finished unregistering the child.
Also split device_unregister() in __scmi_device_destroy() so the SCMI bus
ID is not made reusable until after device_del() has removed the old
scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the
same ID while the old device is still registered.
Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback")
Fixes: 9ca67840c0dd ("firmware: arm_scmi: Balance device refcount when destroying devices")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/bus.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index d4beefa4234f..e1deb1b3011d 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -250,8 +250,9 @@ static int scmi_match_by_id_table(struct device *dev, const void *data)
return __scmi_dev_match_by_id_table(scmi_dev, id_table, false);
}
-static struct scmi_device *scmi_child_dev_find(struct device *parent,
- int prot_id, const char *name)
+/* Returns a device_find_child() reference which must be dropped by caller. */
+static struct scmi_device *
+scmi_child_dev_find_get(struct device *parent, int prot_id, const char *name)
{
struct scmi_device_id id_table[2] = { 0 };
struct device *dev;
@@ -263,9 +264,6 @@ static struct scmi_device *scmi_child_dev_find(struct device *parent,
if (!dev)
return NULL;
- /* Drop the refcnt bumped implicitly by device_find_child */
- put_device(dev);
-
return to_scmi_dev(dev);
}
@@ -422,8 +420,9 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
atomic_set(&scmi_syspower_registered, 0);
+ device_del(&scmi_dev->dev);
ida_free(&scmi_bus_id, scmi_dev->id);
- device_unregister(&scmi_dev->dev);
+ put_device(&scmi_dev->dev);
}
static struct scmi_device *
@@ -440,9 +439,11 @@ __scmi_device_create(struct device_node *np, struct device *parent,
* each DT defined protocol at probe time, and the concurrent
* registration of SCMI drivers.
*/
- scmi_dev = scmi_child_dev_find(parent, protocol, name);
- if (scmi_dev)
+ scmi_dev = scmi_child_dev_find_get(parent, protocol, name);
+ if (scmi_dev) {
+ put_device(&scmi_dev->dev);
return scmi_dev;
+ }
/*
* Ignore any possible subsequent failures while creating the device
@@ -492,8 +493,8 @@ __scmi_device_create(struct device_node *np, struct device *parent,
return scmi_dev;
put_dev:
+ ida_free(&scmi_bus_id, scmi_dev->id);
put_device(&scmi_dev->dev);
- ida_free(&scmi_bus_id, id);
return NULL;
}
@@ -574,9 +575,11 @@ void scmi_device_destroy(struct device *parent, int protocol, const char *name)
{
struct scmi_device *scmi_dev;
- scmi_dev = scmi_child_dev_find(parent, protocol, name);
- if (scmi_dev)
+ scmi_dev = scmi_child_dev_find_get(parent, protocol, name);
+ if (scmi_dev) {
__scmi_device_destroy(scmi_dev);
+ put_device(&scmi_dev->dev);
+ }
}
EXPORT_SYMBOL_GPL(scmi_device_destroy);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/9] firmware: arm_scmi: Fix transport device teardown lookup
From: Sudeep Holla @ 2026-06-30 9:05 UTC (permalink / raw)
To: arm-scmi, linux-arm-kernel
Cc: Cristian Marussi, Sudeep Holla, Sashiko, Sudeep Holla
In-Reply-To: <20260630-scmi_core_fixes-v1-0-f932c1e51992@kernel.org>
SCMI transport devices are deliberately excluded from normal SCMI bus
matching so protocol drivers cannot bind to the internal transport
children. However, scmi_device_destroy() uses the same protocol/name
lookup to find devices that must be unregistered during channel teardown.
Split the match helper so driver matching still skips transport devices,
while explicit child lookup can find them for teardown. Use a shared
transport-device name prefix macro for both matching and name generation.
Since transport-device names are derived from direction and protocol ID,
reject duplicate protocol channel setup before creating or finding a
transport device. This prevents malformed firmware with duplicate
protocol child nodes from reusing an existing transport device and then
destroying it when the duplicate IDR insertion fails.
Fixes: 9593804c44c2 ("firmware: arm_scmi: Exclude transport devices from bus matching")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/bus.c | 22 +++++++++++++++++-----
drivers/firmware/arm_scmi/common.h | 2 ++
drivers/firmware/arm_scmi/driver.c | 5 ++++-
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index f643a1f0e282..d4beefa4234f 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -201,21 +201,33 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
scmi_protocol_device_unrequest(entry);
}
-static int scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
- const struct scmi_device_id *id_table)
+static bool scmi_device_is_transport(const struct scmi_device *scmi_dev)
+{
+ return !strncmp(scmi_dev->name, SCMI_TRANSPORT_DEVNAME_PREFIX,
+ strlen(SCMI_TRANSPORT_DEVNAME_PREFIX));
+}
+
+static int __scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
+ const struct scmi_device_id *id_table,
+ bool skip_transport)
{
if (!id_table || !id_table->name)
return 0;
- /* Always skip transport devices from matching */
for (; id_table->protocol_id && id_table->name; id_table++)
if (id_table->protocol_id == scmi_dev->protocol_id &&
- strncmp(scmi_dev->name, "__scmi_transport_device", 23) &&
+ !(skip_transport && scmi_device_is_transport(scmi_dev)) &&
!strcmp(id_table->name, scmi_dev->name))
return 1;
return 0;
}
+static int scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
+ const struct scmi_device_id *id_table)
+{
+ return __scmi_dev_match_by_id_table(scmi_dev, id_table, true);
+}
+
static int scmi_dev_match_id(struct scmi_device *scmi_dev,
const struct scmi_driver *scmi_drv)
{
@@ -235,7 +247,7 @@ static int scmi_match_by_id_table(struct device *dev, const void *data)
struct scmi_device *scmi_dev = to_scmi_dev(dev);
const struct scmi_device_id *id_table = data;
- return scmi_dev_match_by_id_table(scmi_dev, id_table);
+ return __scmi_dev_match_by_id_table(scmi_dev, id_table, false);
}
static struct scmi_device *scmi_child_dev_find(struct device *parent,
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index b9723c105fc1..fe8c22cfb9f7 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -34,6 +34,8 @@
#define SCMI_SHMEM_MAX_PAYLOAD_SIZE 104
+#define SCMI_TRANSPORT_DEVNAME_PREFIX "__scmi_transport_device"
+
enum scmi_error_codes {
SCMI_SUCCESS = 0, /* Success */
SCMI_ERR_SUPPORT = -1, /* Not supported */
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b9245238e293..b9ba566fc759 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2751,6 +2751,9 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
idx = tx ? 0 : 1;
idr = tx ? &info->tx_idr : &info->rx_idr;
+ if (idr_find(idr, prot_id))
+ return -EEXIST;
+
if (!info->desc->ops->chan_available(of_node, idx)) {
cinfo = idr_find(idr, SCMI_PROTOCOL_BASE);
if (unlikely(!cinfo)) /* Possible only if platform has no Rx */
@@ -2768,7 +2771,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
cinfo->no_completion_irq = info->desc->no_completion_irq;
/* Create a unique name for this transport device */
- snprintf(name, 32, "__scmi_transport_device_%s_%02X",
+ snprintf(name, sizeof(name), SCMI_TRANSPORT_DEVNAME_PREFIX "_%s_%02X",
idx ? "rx" : "tx", prot_id);
/* Create a uniquely named, dedicated transport device for this chan */
tdev = scmi_device_create(of_node, info->dev, prot_id, name);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC v8 05/24] arm64: Implement asm/kpkeys.h using POE
From: Kevin Brodsky @ 2026-06-30 9:16 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <f8507ad6-761c-4073-85ae-bddb2a07d660@kernel.org>
On 22/06/2026 15:35, David Hildenbrand (Arm) wrote:
> On 5/26/26 13:15, Kevin Brodsky wrote:
>> Implement the kpkeys interface if CONFIG_ARM64_POE is enabled.
>> The permissions for KPKEYS_PKEY_DEFAULT (pkey 0) are set to RWX as
>> this pkey is also used for code mappings.
>>
>> To allow <asm/kpkeys.h> to be included from assembly, also add
>> appropriate #ifdef's to <asm/por.h>.
>>
>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
>> ---
>> arch/arm64/include/asm/kpkeys.h | 59 +++++++++++++++++++++++++++++++++++++++++
>> arch/arm64/include/asm/por.h | 4 +++
>> 2 files changed, 63 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kpkeys.h b/arch/arm64/include/asm/kpkeys.h
>> new file mode 100644
>> index 000000000000..4dbfeb3dfcfe
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kpkeys.h
>> @@ -0,0 +1,59 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __ASM_KPKEYS_H
>> +#define __ASM_KPKEYS_H
>> +
>> +#include <asm/barrier.h>
>> +#include <asm/cpufeature.h>
>> +#include <asm/por.h>
>> +
>> +#include <asm-generic/kpkeys.h>
>> +
>> +/*
>> + * Equivalent to por_set_kpkeys_context(0, KPKEYS_CTX_DEFAULT), but can also be
>> + * used in assembly.
>> + */
>> +#define POR_EL1_INIT POR_ELx_PERM_PREP(KPKEYS_PKEY_DEFAULT, POE_RWX)
> Okay, this matches
>
> #define POR_EL0_INIT POR_ELx_PERM_PREP(0, POE_RWX)
>
> Is there a good reason we need KPKEYS_PKEY_DEFAULT at all (and not similarly
> just hardcode it to 0)?
I did wonder about that. As per the discussion on patch 1 I don't see
that value ever changing, so I'm fine with hardcoding 0 if that feels
more consistent/intuitive.
> Just wondering, because apparently we didn't care about adding an indicator for
> user space pkey 0.
It's never too late to add a constant for userspace as well, but of
course since it's been ABI for so long the value isn't going to change.
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +static inline bool arch_supports_kpkeys(void)
>> +{
>> + return system_supports_poe();
>> +}
>> +
>> +#ifdef CONFIG_ARM64_POE
>> +
>> +static inline u64 por_set_kpkeys_context(u64 por, int ctx)
>> +{
>> + por = por_elx_set_pkey_perms(por, KPKEYS_PKEY_DEFAULT, POE_RWX);
>> +
>> + return por;
> Why not
>
> return por_elx_set_pkey_perms(por, KPKEYS_PKEY_DEFAULT, POE_RWX);
>
> ?
Because of patch 17, I wanted to minimise the diff. Happy to change it
if that feels less surprising.
> In light of API discussions, it would be nicer if arch_kpkeys_set_context()
> would just return the old context. But that would mean that restoring the
> context would require another read_sysreg_s(SYS_POR_EL1);
Correct, that's what I wanted to avoid.
> So instead of returning magic register values, that should be wrapped in some
> arch state struct as mentioned as reply to a previous patch.
Agreed.
>> +}
>> +
>> +static __always_inline void __kpkeys_set_pkey_reg_nosync(u64 pkey_reg)
>> +{
>> + write_sysreg_s(pkey_reg, SYS_POR_EL1);
>> +}
>> +
>> +static __always_inline u64 arch_kpkeys_set_context(int ctx)
>> +{
>> + u64 prev_por = read_sysreg_s(SYS_POR_EL1);
>> + u64 new_por = por_set_kpkeys_context(prev_por, ctx);
> Both can be const.
Sure.
> But maybe you just use a single "por" variable.
Not sure how? prev_por is returned and new_por is based on its value.
>> +
>> + __kpkeys_set_pkey_reg_nosync(new_por);
>> + isb();
>> +
>> + return prev_por;
>> +}
>> +
>> +static __always_inline void arch_kpkeys_restore_pkey_reg(u64 pkey_reg)
>> +{
>> + __kpkeys_set_pkey_reg_nosync(pkey_reg);
>> + isb();
> Why is that isb() for both callers outside of the function? Do you expect
> another user that doesn't need the isb?
Outside of __kpkeys_set_pkey_reg_nosync() that is? That function is also
used by patch 22, which doesn't want the ISB because we already have an
ISB somewhere else. The naming follows that of __set_pte_nosync().
- Kevin
^ permalink raw reply
* [PATCH v4 09/10] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun Chen @ 2026-06-30 7:47 UTC (permalink / raw)
To: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing
Cc: catalin.marinas, will, alex, akpm, pasha.tatashin, pratyush,
ruirui.yang, m.szyprowski, robin.murphy
In-Reply-To: <20260630074715.4126796-1-chenwandun1@gmail.com>
From: Wandun Chen <chenwandun@lixiang.com>
Apply the same non-dumpable reserved memory filtering to RISC-V kdump
as was done for arm64. Use of_reserved_mem_kdump_exclude() to drop
flagged regions from the elfcorehdr PT_LOAD segments, and
of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
---
arch/riscv/kernel/machine_kexec_file.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 59d4bbc848a8..25359d583bc3 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -10,6 +10,7 @@
#include <linux/elf.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/of_reserved_mem.h>
#include <linux/libfdt.h>
#include <linux/types.h>
#include <linux/memblock.h>
@@ -64,6 +65,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
nr_ranges = 1; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
+ nr_ranges += of_reserved_mem_kdump_nr_ranges();
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
if (!cmem)
@@ -77,6 +79,8 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
/* Exclude crashkernel region */
ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ if (!ret)
+ ret = of_reserved_mem_kdump_exclude(cmem);
if (!ret)
ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC v8 04/24] arm64: Introduce por_elx_set_pkey_perms() helper
From: Kevin Brodsky @ 2026-06-30 9:15 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <e334c595-92ab-4eb9-a096-35602d57ae6d@kernel.org>
On 22/06/2026 15:16, David Hildenbrand (Arm) wrote:
> On 5/26/26 13:15, Kevin Brodsky wrote:
>> Introduce a helper that sets the permissions of a given pkey
>> (POIndex) in the POR_ELx format, and make use of it in
>> arch_set_user_pkey_access().
>>
>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
>> ---
>> arch/arm64/include/asm/por.h | 7 +++++++
>> arch/arm64/mm/mmu.c | 26 ++++++++++----------------
>> 2 files changed, 17 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/por.h b/arch/arm64/include/asm/por.h
>> index d913d5b529e4..bffb4d2b1246 100644
>> --- a/arch/arm64/include/asm/por.h
>> +++ b/arch/arm64/include/asm/por.h
>> @@ -31,4 +31,11 @@ static inline bool por_elx_allows_exec(u64 por, u8 pkey)
>> return perm & POE_X;
>> }
>>
>> +static inline u64 por_elx_set_pkey_perms(u64 por, u8 pkey, u64 perms)
>> +{
>> + u64 shift = POR_ELx_PERM_SHIFT(pkey);
>> +
>> + return (por & ~(POE_MASK << shift)) | (perms << shift);
>> +}
>> +
>> #endif /* _ASM_ARM64_POR_H */
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index dd85e093ffdb..493310cf0486 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -2339,8 +2339,8 @@ void __cpu_replace_ttbr1(pgd_t *pgdp, bool cnp)
>> #ifdef CONFIG_ARCH_HAS_PKEYS
>> int arch_set_user_pkey_access(int pkey, unsigned long init_val)
>> {
>> - u64 new_por;
>> - u64 old_por;
>> + u64 new_perms;
> You should spell out the renaming of the variable.
Sure, will do.
> Given that perms is 4bit per key, should we use a u8 for it instead?
We could, in fact I'm just noticing that this all very inconsistent
right now: the POE_* constants are defined as UL, but por_elx_allows_*
and other functions use u8. I'll clean that up in a separate patch and
use u8 here.
>> + u64 por;
>>
>> if (!system_supports_poe())
>> return -ENOSPC;
>> @@ -2354,25 +2354,19 @@ int arch_set_user_pkey_access(int pkey, unsigned long init_val)
>> return -EINVAL;
>>
>> /* Set the bits we need in POR: */
>> - new_por = POE_RWX;
>> + new_perms = POE_RWX;
>> if (init_val & PKEY_DISABLE_WRITE)
>> - new_por &= ~POE_W;
>> + new_perms &= ~POE_W;
>> if (init_val & PKEY_DISABLE_ACCESS)
>> - new_por &= ~POE_RW;
>> + new_perms &= ~POE_RW;
>> if (init_val & PKEY_DISABLE_READ)
>> - new_por &= ~POE_R;
>> + new_perms &= ~POE_R;
>> if (init_val & PKEY_DISABLE_EXECUTE)
>> - new_por &= ~POE_X;
>> + new_perms &= ~POE_X;
>>
>> - /* Shift the bits in to the correct place in POR for pkey: */
>> - new_por = POR_ELx_PERM_PREP(pkey, new_por);
>> -
>> - /* Get old POR and mask off any old bits in place: */
>> - old_por = read_sysreg_s(SYS_POR_EL0);
>> - old_por &= ~(POE_MASK << POR_ELx_PERM_SHIFT(pkey));
>> -
>> - /* Write old part along with new part: */
>> - write_sysreg_s(old_por | new_por, SYS_POR_EL0);
>> + por = read_sysreg_s(SYS_POR_EL0);
>> + por = por_elx_set_pkey_perms(por, pkey, new_perms);
>> + write_sysreg_s(por, SYS_POR_EL0);
> Was wondering whether to move reading+writing of the register into the same
> helper, but you cannot reuse this exactly the same way for SYS_POR_EL1 as it seems.
It wouldn't be useful because the new user of the helper,
por_set_kpkeys_context(), doesn't itself read or write the register.
> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Thanks!
- Kevin
^ 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