Re: [PATCH net-next v4 3/3] arm64: dts: renesas: r8a779g0: Add gPTP node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Resource conflict and probe failure due to overlapping MMIO mappings between gptp and tsn0 nodes.
- [High] Hardware state corruption of the shared gPTP module due to an uncoordinated shared reset line.
--

commit 6d2ee2b897e0e7be7fd397823f8cda63b923ce38
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

arm64: dts: renesas: r8a779g0: Add gPTP node

The gPTP module is shared between the RAVB and RTSN Ethernet devices on
the SoC.

> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> index 82a7278836e57..b9b860ef70351 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> @@ -589,6 +589,15 @@ tmu4: timer@ffc00000 {
>  			status = "disabled";
>  		};
>  
> +		gptp: ptp@e6449000 {
> +			compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
> +			reg = <0 0xe6449000 0 0x500>;

[Severity: High]
Will this result in a probe failure when requesting the memory region?

The new gptp node claims the 0xe6449000 memory region here, but the
existing tsn0 node below incorrectly retains the exact same region.

The drivers for these nodes both request exclusive access to the memory:

drivers/ptp/ptp_rcar_gen4.c:ptp_rcar_gen4_probe() {
    ...
    priv->base = devm_platform_ioremap_resource(pdev, 0);
    ...
}

drivers/net/ethernet/renesas/rtsn.c:rtsn_probe() {
    ...
    ptpaddr = devm_ioremap_resource(&pdev->dev, res);
    ...
}

Since these wrappers enforce exclusive access, whichever driver probes
second will get an -EBUSY failure.

Should the tsn0 node be updated to drop this overlapping region?

> +			clocks = <&cpg CPG_MOD 2723>;
> +			power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> +			resets = <&cpg 2723>;

[Severity: High]
Can an interface reset corrupt the shared gPTP hardware state?

The gptp node is assigned the shared reset line 2723 here, and the commit
message notes that the gPTP module is shared between the RAVB and RTSN
Ethernet devices.

However, the rtsn driver aggressively asserts this shared reset line:

drivers/net/ethernet/renesas/rtsn.c:rtsn_reset() {
    ...
    reset_control_reset(priv->reset);
    ...
}

If a network administrator toggles the tsn0 interface state, will this
abruptly wipe out the clock state of the shared gPTP hardware and break
other consumers like RAVB that rely on it?

> +			status = "disabled";
> +		};
> +
>  		tsn0: ethernet@e6460000 {
>  			compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
>  			reg = <0 0xe6460000 0 0x7000>,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702125525.2230427-1-niklas.soderlund+renesas@ragnatech.se?part=3