Re: [PATCH 3/3] arm64: zynqmp: Add EBDEE EdgeBoard FZ3A development board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dt: zynqmp: peripherals fail to probe due to missing LPD_LSBUS clock override
- [Medium] dt: zynqmp: missing non-removable and bus-width properties for eMMC
--

commit cf011196c14a8a65736d50052e13ac3e134bc620
Author: Pufan Jin <2254650260@qq.com>
Subject: arm64: zynqmp: Add EBDEE EdgeBoard FZ3A development board

This commit adds the device tree for the EBDEE EdgeBoard FZ3A carrier
board built around the MYIR MYS-CZU3EG SoM. It enables various board
peripherals including Ethernet, I2C, eMMC, PCIe, USB, DisplayPort,
and UARTs.

> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ebdee-edgeboard-fz3a.dts b/arch/arm64/boot/dts/xilinx/zynqmp-ebdee-edgeboard-fz3a.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-ebdee-edgeboard-fz3a.dts
[ ... ]
> +	/*
> +	 * The PM firmware on this ZU3EG does not report the LPD_LSBUS
> +	 * clock id as valid, so <&zynqmp_clk LPD_LSBUS> resolves to no
> +	 * clock at all and drivers that require their bus clock fail to
> +	 * probe.
> +	 */
> +	lpd_lsbus: clock-lpd-lsbus {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <100000000>;
> +	};
[ ... ]
> +&gem3 {
> +	clocks = <&lpd_lsbus>, <&zynqmp_clk GEM3_REF>,
> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
> +		 <&zynqmp_clk GEM_TSU>;
> +	phy-mode = "rgmii-id";
> +	status = "okay";
> +};
[ ... ]
> +&sdhci0 {
> +	no-1-8-v;
> +	status = "okay";
> +};

[Severity: High]
Since the PM firmware's LPD_LSBUS clock is broken as noted above, will sdhci0
fail to probe without a clock override? The base device tree maps LPD_LSBUS to
sdhci0, so it seems it will inherit the broken clock if not explicitly
overridden here like it was for gem3.

[Severity: Medium]
The commit message states this board has an 8GB eMMC. Should this node
include the non-removable and bus-width = <8>; properties? Without them,
does the MMC core treat this as a removable SD card and run at a degraded
1-bit or 4-bit bus width?

[ ... ]
> +&uart0 {
> +	status = "okay";
> +};

[Severity: High]
Will this console UART also fail to probe without the lpd_lsbus clock
workaround? If it inherits the broken LPD_LSBUS clock from the base device
tree, does that result in no console output on boot?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_E21E2A584AF8EE0505C2C0809838621C8209@qq.com?part=3