Re: [PATCH 2/2] arm64: dts: socfpga: Add dma-coherent to XGMAC nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Other SMMU-attached DMA masters in the base SoC `.dtsi` lack the `dma-coherent` property, risking data corruption.
- [High] The `dma-coherent` property is applied at the board `.dts` level instead of the SoC `.dtsi` level, leaving `gmac1` unprotected.
--

commit 3e00440f9beb8b27250cd5096c497340a958ee43
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

arm64: dts: socfpga: Add dma-coherent to XGMAC nodes

This commit adds the dma-coherent property to XGMAC nodes in various
Agilex3 and Agilex5 board files. The commit message notes that transactions
going through the enabled SMMU are cache coherent, and this property prevents
redundant cache operations.

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
> index bdb608bb30ea6..dd878547c3056 100644
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
> @@ -45,6 +45,7 @@ &gmac2 {
>  	phy-mode = "rgmii-id";
>  	phy-handle = <&emac2_phy0>;
>  	max-frame-size = <9000>;
> +	dma-coherent;

Should this hardware integration property be added directly to the base
socfpga_agilex5.dtsi file instead of the individual board files?

By adding it at the board level, it appears gmac1 (which is defined in
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi) is missed. If a future board
enables gmac1, it will silently lack this property, which could cause explicit
arm64 cache invalidations to discard dma writes and result in stale data.

Also, the commit message mentions that transactions going through the SMMU
are cache coherent. Does this mean other SMMU-attached devices in the
base socfpga_agilex5.dtsi also need this property?

For example, looking at arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi,
several other components are routed through the SMMU but lack dma-coherent:

		usb0: usb@10b00000 {
			...
			iommus = <&smmu 6>;
		};

		dmac0: dma-controller@0 {
			...
			iommus = <&smmu 8>;
		};

If these physically coherent devices are mapped as non-coherent, the kernel
will issue explicit cache invalidations (like dc ivac during dma_unmap_single
for device-to-memory transfers).

Because a coherent device writes directly into the CPU cache, this post-dma
kernel cache invalidation will discard the newly written data. Could this
cause silent regressions with active data corruption for devices like usb
storage or dma controllers?

[ ... ]

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