Re: [PATCH net-next v7 1/3] dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4

["Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>]

On 2026-10-08 19:00:01 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] ptp: devm_ioremap_resource() conflict with rtsn Ethernet driver
> --
> 
> commit 2999d29f8c3c04d8ff6cdf49a3fa0d43c2a42ee4
> Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> 
> dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
> 
> This commit adds device tree bindings for the R-Car Gen4 gPTP timer. The
> timer provides clock synchronization and is shared among different Ethernet
> devices across Gen4 platforms.
> 
> > diff --git a/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> 
> [ ... ]
> 
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
> > +    #include <dt-bindings/power/r8a779g0-sysc.h>
> > +
> > +    ptp@e6449000 {
> > +            compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
> > +            reg = <0xe6449000 0x500>;
> 
> [Severity: High]
> Does this new node's memory region conflict with the existing Ethernet TSN
> driver?

Yes it does, please read the cover letter to see why.

> 
> The existing renesas,ethertsn binding also claims this exact same memory
> region for the generalized Precision Time Protocol target.
> 
> During probe in drivers/net/ethernet/renesas/rtsn.c:rtsn_probe(), the
> existing Ethernet driver requests this region:
> 
>         res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
>         ...
>         priv->gptp = devm_ioremap_resource(&pdev->dev, res);
> 
> Because both drivers use devm_ioremap_resource(), which attempts to acquire
> exclusive access to the underlying physical memory via
> devm_request_mem_region(), whichever driver probes second will fail with
> -EBUSY. This will cause a driver probe failure and make the device unusable.
> 
> How should this shared memory resource be managed so both drivers can probe
> successfully?
> 
> > +            clocks = <&cpg CPG_MOD 2723>;
> > +            power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +            resets = <&cpg 2723>;
> > +    };
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261007185920.4042783-1-niklas.soderlund+renesas@ragnatech.se?part=1

-- 
Kind Regards,
Niklas Söderlund