Re: [PATCH v2 8/9] ARM: dts: stm32: add Ruiside ART-Pi2 board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Inconsistent Alternate Function (AF) mapping for SDMMC1_D2 pin
- [High] Missing alignment constraint for no-map DMA pool causes MPU region exhaustion
--

--- Patch [8]: [PATCH v2 8/9] ARM: dts: stm32: add Ruiside ART-Pi2 board ---
commit 7778d903d666ebc7aafa183daaea78a638999301
Author: Liu Changjie <liucj1228@outlook.com>

ARM: dts: stm32: add Ruiside ART-Pi2 board

Adds the ART-Pi2 board based on the STM32H7R7 SoC. Includes configuration
for external HyperRAM, UART4, user LEDs, button, and the microSD slot
with a coherent DMA pool.

[ ... ]
> diff --git a/arch/arm/boot/dts/st/stm32h7r7l8-art-pi2.dts b/arch/arm/boot/dts/st/stm32h7r7l8-art-pi2.dts
> new file mode 100644
> index 0000000000000..ead1418178af7
> --- /dev/null
> +++ b/arch/arm/boot/dts/st/stm32h7r7l8-art-pi2.dts
[ ... ]
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		dma_pool: dma-pool {
> +			compatible = "shared-dma-pool";
> +			no-map;
> +			size = <0x00200000>;
> +			linux,dma-default;
> +		};

[Severity: High]
Does this no-map memory region require an alignment constraint to prevent MPU
region exhaustion?

Without an alignment property, memblock may allocate this 2MiB hole at a
default alignment. On ARM Cortex-M7 (PMSAv7), MPU regions require power-of-2
sizes and aligned base addresses. An unaligned hole can force the MPU to use
many small regions to cover the remaining RAM, quickly exhausting the
typical 8-region limit and silently truncating system memory.

Could we add an alignment = <0x00200000> property here?

> +	};
[ ... ]
> diff --git a/arch/arm/boot/dts/st/stm32h7rs-pinctrl.dtsi b/arch/arm/boot/dts/st/stm32h7rs-pinctrl.dtsi
> new file mode 100644
> index 0000000000000..08f09f5621964
> --- /dev/null
> +++ b/arch/arm/boot/dts/st/stm32h7rs-pinctrl.dtsi
[ ... ]
> +&pinctrl {
> +	sdmmc1_b4_pins_a: sdmmc1-b4-0 {
> +		pins {
> +			pinmux = <STM32_PINMUX('C', 8, AF11)>, /* SDMMC1_D0 */
> +				 <STM32_PINMUX('C', 9, AF11)>, /* SDMMC1_D1 */
> +				 <STM32_PINMUX('C', 10, AF12)>, /* SDMMC1_D2 */

[Severity: High]
Is it intentional that SDMMC1_D2 uses AF12 while the surrounding SDMMC1 pins
in this group use AF11?

If this is an oversight, the D2 data line will not be routed to the SDMMC1
controller when initialized in 4-bit mode, leading to communication failure
with the SD card.

> +				 <STM32_PINMUX('C', 11, AF11)>, /* SDMMC1_D3 */
> +				 <STM32_PINMUX('C', 12, AF11)>, /* SDMMC1_CK */
> +				 <STM32_PINMUX('D', 2, AF11)>; /* SDMMC1_CMD */
> +			slew-rate = <3>;
> +			drive-push-pull;
> +			bias-disable;
> +		};
> +	};
> +
> +	sdmmc1_b4_od_pins_a: sdmmc1-b4-od-0 {
> +		pins1 {
> +			pinmux = <STM32_PINMUX('C', 8, AF11)>, /* SDMMC1_D0 */
> +				 <STM32_PINMUX('C', 9, AF11)>, /* SDMMC1_D1 */
> +				 <STM32_PINMUX('C', 10, AF12)>, /* SDMMC1_D2 */

[Severity: High]
The same AF12 mapping appears here for SDMMC1_D2 in the open-drain
configuration group. Should this also be AF11?

> +				 <STM32_PINMUX('C', 11, AF11)>, /* SDMMC1_D3 */
> +				 <STM32_PINMUX('C', 12, AF11)>; /* SDMMC1_CK */
> +			slew-rate = <3>;
> +			drive-push-pull;
> +			bias-disable;
> +		};
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/MN0PR19MB6091DB524E7A07E16D108F52ACDF2@MN0PR19MB6091.namprd19.prod.outlook.com?part=8