Re: [PATCH net-next v7 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] dts: overlapping memory regions for gptp and tsn0 cause probe failure
- [High] dts: shared reset line between gptp and tsn0 causes probe failure and state corruption
--

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

arm64: dts: renesas: r8a779g0: Add gPTP node

This commit adds a new gPTP node to the r8a779g0 device tree. The gPTP module
is intended to be 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 8a291447b9045..7430b663cf92e 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> @@ -606,6 +606,15 @@ mfis: system-controller@e6260000 {
>  			status = "disabled";
>  		};
>  
> +		gptp: ptp@e6449000 {
> +			compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
> +			reg = <0 0xe6449000 0 0x500>;

[Severity: High]
Does this memory region overlap with the existing tsn0 node?

The tsn0 node independently claims an overlapping memory region starting at
0xe6449000. When both devices are enabled in a board device tree, the driver
probing second will fail with -EBUSY because the kernel resource framework
enforces exclusive access to physical memory regions. This could permanently
disable either the PTP timer or the Ethernet TSN interface.

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

[Severity: High]
Will sharing this reset line cause probe failures or hardware state corruption?

Both the newly added gptp node and the existing tsn0 node specify the same
hardware reset line. The rtsn driver exclusively acquires this reset. The
second driver to initialize will fail to acquire it, leading to a probe failure.

Furthermore, even if the drivers are updated to request a shared reset, the
rtsn driver unconditionally pulses this shared reset line during hardware
initialization:

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

Since the gPTP block is shared across multiple Ethernet devices, pulsing this
reset asynchronously wipes out the gPTP timer registers, which could
permanently break PTP synchronization for the system.

> +			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/20261007185920.4042783-1-niklas.soderlund+renesas@ragnatech.se?part=3