Re: [PATCH net-next v3 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 2 potential issue(s) to consider:
- [High] The newly added gPTP timer binding creates a standalone device that maps the exact same `reg` memory region already claimed by the existing `renesas,ethertsn.yaml` binding, leading to an I/O memory conflict.
- [Medium] The binding schema is missing the `interrupts` and `interrupt-names` properties, which are necessary to describe the gPTP timer's hardware interrupts.
--

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

dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4

Add bindings for the R-Car Gen4 gPTP timer. The timer enables accurate
synchronization of the clock in the control system. The timer is
system-wide and used by different Ethernet devices on each Gen4 platform.

> 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

[Severity: Medium]
Should interrupts and interrupt-names be included in the allowed properties?

On the S4-8 (r8a779f0) SoC, the gPTP timer's hardware interrupts (gptp0_status,
gptp1_status) are currently described in the rswitch node. 

Modeling the gPTP timer as an independent device requires defining its
interrupts in this new standalone node, but they will be rejected because
additionalProperties is false.

> +
> +  reg:
> +    maxItems: 1

[Severity: High]
Does this standalone gPTP timer mapping conflict with the existing
renesas,ethertsn.yaml binding?

The newly added gPTP timer binding creates a standalone device that maps the
exact same reg memory region already claimed by the ethertsn binding.

For example, in arch/arm64/boot/dts/renesas/r8a779g0.dtsi, the gptp node uses:

    reg = <0 0xe6449000 0 0x500>;

While the tsn0 node also uses:

    reg = <...>, <0 0xe6449000 0 0x500>;
    reg-names = "tsnes", "gptp";

Because the RTSN driver and the new gPTP driver both call
devm_ioremap_resource(), won't whichever driver probes second fail with -EBUSY?
Removing the region from tsn0 would violate the unmodified
renesas,ethertsn.yaml schema, which strictly requires the gptp region.

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