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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The device tree changes introduce a standalone node for the gPTP timer which maps the exact same physical memory region already mapped by the existing Ethernet controller, leading to a resource conflict during probe.
--

commit b3e38755e98012153ce2a29973eff93cb0cf332d
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 enables system-wide clock synchronization and is shared by 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
> index 0000000000000..3edd64d400387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> @@ -0,0 +1,64 @@

[ ... ]

> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - renesas,r8a779f0-gptp # S4-8
> +          - renesas,r8a779g0-gptp # V4H
> +          - renesas,r8a779h0-gptp # V4M
> +      - const: renesas,rcar-gen4-gptp
> +
> +  reg:
> +    maxItems: 1

[Severity: High]
Will this standalone reg mapping conflict with the existing Ethernet TSN
node?

The device tree bindings introduce a standalone node for the gPTP timer
which maps the exact same physical memory region (e.g. 0xe6449000) already
claimed by the existing renesas,ethertsn device node via its gptp reg
resource.

At runtime, the new ptp_rcar_gen4 driver maps this with:

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

And the existing rtsn driver does the same:

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

Since devm_ioremap_resource() internally calls request_mem_region(), which
claims exclusive access to the physical memory, the second driver to probe
will be rejected with -EBUSY and fail to load.

Should shared hardware registers be modeled using a provider-consumer
pattern with phandles instead of duplicating reg mappings across distinct
nodes?

> +
> +  clocks:
> +    maxItems: 1

[ ... ]

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