Re: [PATCH v5 2/4] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Incorrect Driver Binding and Missing Initialization due to omitted fallback string
- [High] Incorrect `phy-mode` setting causes RGMII double-delay and link failure
- [Low] Missing DT Binding Documentation for 'altr,socfpga-stmmac-agilex5-tsn'
--

--- Patch [2]: [PATCH v5 2/4] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board ---
commit 2098e6284de4334f7035c13bb19d6fcdee253f03
Author: Nazim Amirul <[email protected]>

arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

This commit adds a device tree for the Intel SoCFPGA Agilex5 SoCDK TSN
Config2 board variant. It enables gmac1 as a TSN port utilizing a
GMII-to-RGMII FPGA soft IP converter. The port is configured with a custom
compatible string to reflect the converter integration.

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
> new file mode 100644
> index 0000000000000..9d39f843b4240
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
[ ... ]
> +&gmac1 {
> +	status = "okay";
> +	compatible = "altr,socfpga-stmmac-agilex5-tsn",
> +		     "snps,dwxgmac-2.10";

[Severity: Low]
Is this new compatible string "altr,socfpga-stmmac-agilex5-tsn" documented
in any device tree binding schema? It appears this will cause validation
failures when running make dtbs_check.

[Severity: High]
Does dropping the fallback strings "altr,socfpga-stmmac-agilex5" and
"snps,dwxgmac" break driver binding and initialization?

Since dwmac-socfpga.c has no match for the new string, the node will fall
back to the generic STMMAC driver via "snps,dwxgmac-2.10".

The generic platform code in devm_stmmac_probe_config_dt() checks for
"snps,dwxgmac" to identify an XGMAC. Without it, the core type is left
initialized as DWMAC_CORE_MAC100, which will cause initialization to fail.

Furthermore, bypassing dwmac-socfpga.c prevents platform-specific resets like
stmmaceth-ocp from being de-asserted.

> +	phy-mode = "rgmii-id";

[Severity: High]
Does this phy-mode setting cause a double-delay on the RGMII interface?

The commit message states that the GMII-to-RGMII converter provides the
RGMII TX/RX clock delays. However, setting phy-mode to "rgmii-id"
instructs the PHY device to insert its own internal clock delays.

If the MAC-side converter already adds the delays, should this be set to
"rgmii" instead so the PHY knows delays are already provided?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817030213.6769-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2