[PATCH net-next v8 0/3] ptp: Add driver for R-Car Gen4

[PATCH net-next v8 0/3] ptp: Add driver for R-Car Gen4

[Niklas Söderlund]

Hello,

This series is the first part cleaning up how PTP timer support is
implemented on R-Car Gen4. Currently there is partial support for it in
some of the Ethernet devices that can use it, but not all.

The partial support have been implemented by hacking the gPTP module
directly into the first Ethernet device driver that used it, RTSN for
V4H and RSWITCH for S4. This is understandable as earlier R-Car
generations had a dedicated gPTP timer for each Ethernet device, but on
Gen4 there is a single system-wide PTP timer shared by all.

The current implementation makes it impossible for other Ethernet
devices on the platform to use the PTP timer without messing around with
other Ethernet device drivers.

The effort to clean this up starts with this series which adds the
system-wide gPTP timer as its own driver and device tree node.

This series will be followed by work to the RTSN and RSWITCH drivers
will be be switched from its current partial support by mapping the gPTP
address space directly to instead use this driver.

Having both this and RTSN/RSWITCH described and enabled (!) in device
tree will not work as they will try to use the same memory region. For
this reason this new solution will only be enabled on platforms
after all user's of the gPTP clock have moved to only use the new
centralized timer. But in the interim both devices will be described
(but not enabled) in the platforms base dtsi file.

For some platforms this is straight forward, such as V4H Sparrow Hawk,
which only have the RAVB Ethernet interface. This platform currently
have no users of the PTP timer, but still advertise it supports it. This
and the soon to be posted RAVB patches solves that.

The gPTP driver itself is heavily influence by the existing partial
support for gPTP in the RTSN and RSWITCH drivers and the Renesas BSP.

Niklas Söderlund (3):
  dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
  ptp: Add driver for R-Car Gen4
  arm64: dts: renesas: r8a779g0: Add gPTP node

 .../bindings/ptp/renesas,rcar-gen4-gptp.yaml  |  64 +++++
 MAINTAINERS                                   |   7 +
 arch/arm64/boot/dts/renesas/r8a779g0.dtsi     |   9 +
 drivers/ptp/Kconfig                           |  12 +
 drivers/ptp/Makefile                          |   1 +
 drivers/ptp/ptp_rcar_gen4.c                   | 225 ++++++++++++++++++
 6 files changed, 318 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
 create mode 100644 drivers/ptp/ptp_rcar_gen4.c

-- 
2.55.0

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

[Niklas Söderlund]

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.

  - On R-Car S4 it is shared between RSWITCH and RAVB.

  - On R-Car V4H it is shared between RTSN and RAVB.

  - On R-Car V4M it is only used by RAVB.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
* Changes since v1
- Drop 'binding for' for patch subject.
- Drop comment for renesas,rcar-gen4-gptp compatible to match other
  Renesas bindings.
- Drop unused label in example.
- Rename node ptp in example.
---
 .../bindings/ptp/renesas,rcar-gen4-gptp.yaml  | 64 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++
 2 files changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml

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 000000000000..3edd64d40038
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2026 Renesas Electronics Corp.
+# Copyright (C) 2026 Niklas Söderlund <niklas.soderlund@ragnatech.se>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ptp/renesas,rcar-gen4-gptp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen4 gPTP timer
+
+maintainers:
+  - Niklas Söderlund <niklas.soderlund@ragnatech.se>
+
+description:
+  The R-Car Gen4 gPTP 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.
+
+    - On R-Car S4 it is shared between RSWITCH and RAVB.
+    - On R-Car V4H it is shared between RTSN and RAVB.
+    - On R-Car V4M it is only used by RAVB.
+
+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
+
+  clocks:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - power-domains
+  - resets
+
+additionalProperties: false
+
+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>;
+            clocks = <&cpg CPG_MOD 2723>;
+            power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+            resets = <&cpg 2723>;
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index fe23913b1e43..085fedac38ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23822,6 +23822,12 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
 F:	drivers/mtd/nand/raw/renesas-nand-controller.c
 
+RENESAS R-CAR GEN4 GPTP DRIVER
+M:	Niklas Söderlund <niklas.soderlund@ragnatech.se>
+L:	linux-renesas-soc@vger.kernel.org
+S:	Supported
+F:	Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
+
 RENESAS R-CAR GYROADC DRIVER
 M:	Marek Vasut <marek.vasut+renesas@mailbox.org>
 L:	linux-iio@vger.kernel.org
-- 
2.55.0

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

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 5 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 4

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new renesas,rcar-gen4-gptp binding describes the gPTP
  timer as a standalone device.
- [Low] The binding sets additionalProperties: false and has no
  'interrupts' property, but the Gen4 gPTP IP appears to have status…
- [Low] The commit message and the binding description (renesas,rcar-
  gen4-gptp.yaml line 19) say that on R-Car S4 the timer is 'shared…
- [Low] Not confirmed (baseline decision: false).
- [Low] Not confirmed (baseline decision: false).

--

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

This adds a DT binding for the R-Car Gen4 gPTP timer on S4, V4H and V4M.
The timer is described as a standalone node with reg, clocks,
power-domains and resets. The patch also adds a MAINTAINERS entry for the
binding.

> 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 @@

[ ... ]

> +description:
> +  The R-Car Gen4 gPTP 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.
> +
> +    - On R-Car S4 it is shared between RSWITCH and RAVB.

[Severity: Low]
Is the S4 part of this accurate? The tree doesn't seem to have an EtherAVB
on S4:

- renesas,etheravb.yaml lists only r8a779a0, r8a779g0 and r8a779h0 under
  renesas,etheravb-rcar-gen4. There is no renesas,etheravb-r8a779f0.
- ravb_main.c has no S4 match.
- r8a779f0.dtsi only has the renesas,r8a779f0-ether-switch node and no
  etheravb node.

Also, "ptp: Add driver for R-Car Gen4" later in the series only mentions
RSWITCH for S4.

The commit message makes the same claim:

  - On R-Car S4 it is shared between RSWITCH and RAVB.

> +    - On R-Car V4H it is shared between RTSN and RAVB.
> +    - On R-Car V4M it is only used by RAVB.

[ ... ]

> +  resets:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - power-domains
> +  - resets

[Severity: Low]
This is a minor point. On V4H, the reset (and clock) here is the RTSN
module reset 2723, which tsn0 also uses. On S4 it would be the RSWITCH
module.

In the final series state this does not cause a conflict:

- ptp_rcar_gen4.c never calls any reset_control API.
- rtsn and ptp_rcar_gen4 cannot be bound at the same time because of the
  exclusive MMIO claim described below.

Once that register overlap is resolved and both drivers can bind,
rtsn_reset() would pulse the shared line:

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

Would that reset the timer that RAVB relies on?

"ptp: Add driver for R-Car Gen4" says the gPTP shares its clock and reset
with RSWITCH or RTSN. Could the binding description say so too?

> +
> +additionalProperties: false

[Severity: Low]
The binding has additionalProperties: false and no interrupts property.
How would the timer's interrupt outputs be described on this node?

On S4, r8a779f0.dtsi routes dedicated SPIs named "gptp0_status" and
"gptp1_status" in the rswitch node. They might come from the gPTP block,
though they could also be RSWITCH status aggregation. The tree alone
doesn't make that clear.

A binding should describe the hardware fully, even where the driver doesn't
use a resource. Should an optional interrupts property be added here?

> +
> +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: Medium]
Isn't this the same register window that renesas,ethertsn.yaml already
requires as the second reg entry of the RTSN node?

Documentation/devicetree/bindings/net/renesas,ethertsn.yaml:
  reg-names:
    items:
      - const: tsnes
      - const: gptp

r8a779g0.dtsi uses this window in tsn0:

		tsn0: ethernet@e6460000 {
			compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
			reg = <0 0xe6460000 0 0x7000>,
			      <0 0xe6449000 0 0x500>;
			reg-names = "tsnes", "gptp";

rtsn_probe() maps that region exclusively and registers its own PHC on it:

drivers/net/ethernet/renesas/rtsn.c:rtsn_probe() {
    ...
	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
    ...
	ptpaddr = devm_ioremap_resource(&pdev->dev, res);
    ...
	priv->ptp_priv = rcar_gen4_ptp_alloc(pdev, ptpaddr);
    ...
}

Later in the series, "arm64: dts: renesas: r8a779g0: Add gPTP node" adds a
ptp@e6449000 node with the same reg, clock and reset. In "ptp: Add driver
for R-Car Gen4", ptp_rcar_gen4_probe() maps it with
devm_platform_ioremap_resource(), which is also an exclusive request.

Take a V4H board with &tsn0 enabled, such as White Hawk Single. If it also
enables &gptp so that RAVB can use ptp-timer = <&gptp>, won't whichever of
rtsn and ptp_rcar_gen4 probes second fail with -EBUSY? That would lose
either the TSN interface or the PTP clock that RAVB needs.

S4 has a similar overlap. The gPTP block sits at RSWITCH base +
RSWITCH_GPTP_OFFSET_S4, inside the base region that renesas_eth_sw_probe()
maps exclusively. A renesas,r8a779f0-gptp node written to this binding
would overlap that region.

dtc doesn't check for reg overlap between non-sibling nodes, so this would
only show up at runtime.

Is there a transition plan for the gptp reg entry in renesas,ethertsn.yaml
and for the rswitch mapping, such as deprecating the ethertsn gptp reg?
The commit message doesn't mention the overlap or the DT ABI impact.

> +            clocks = <&cpg CPG_MOD 2723>;
> +            power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> +            resets = <&cpg 2723>;
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe23913b1e432..085fedac38ef5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23822,6 +23822,12 @@ S:	Maintained
>  F:	Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
>  F:	drivers/mtd/nand/raw/renesas-nand-controller.c
>  
> +RENESAS R-CAR GEN4 GPTP DRIVER
> +M:	Niklas Söderlund <niklas.soderlund@ragnatech.se>
> +L:	linux-renesas-soc@vger.kernel.org
> +S:	Supported
> +F:	Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml

[Severity: Low]
This is a minor note. At this point the "GPTP DRIVER" section lists only
the binding, and nothing binds renesas,rcar-gen4-gptp yet.

Later in the series this is resolved. "ptp: Add driver for R-Car Gen4"
adds F: drivers/ptp/ptp_rcar_gen4.c to this section, along with a platform
driver that matches renesas,rcar-gen4-gptp. Putting the binding before the
driver looks fine.

> +
>  RENESAS R-CAR GYROADC DRIVER
>  M:	Marek Vasut <marek.vasut+renesas@mailbox.org>
>  L:	linux-iio@vger.kernel.org

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110080727.2377040-1-niklas.soderlund%2Brenesas%40ragnatech.se

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

[Niklas Söderlund]

On 2026-11-14 10:17:48 +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 4
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] The new renesas,rcar-gen4-gptp binding describes the gPTP
>   timer as a standalone device.

That is correct, please read cover letter for reason.

> - [Low] The binding sets additionalProperties: false and has no
>   'interrupts' property, but the Gen4 gPTP IP appears to have status…
> - [Low] The commit message and the binding description (renesas,rcar-
>   gen4-gptp.yaml line 19) say that on R-Car S4 the timer is 'shared…
> - [Low] Not confirmed (baseline decision: false).
> - [Low] Not confirmed (baseline decision: false).
> 
> --
> 
> dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
> 
> This adds a DT binding for the R-Car Gen4 gPTP timer on S4, V4H and V4M.
> The timer is described as a standalone node with reg, clocks,
> power-domains and resets. The patch also adds a MAINTAINERS entry for the
> binding.
> 
> > 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 @@
> 
> [ ... ]
> 
> > +description:
> > +  The R-Car Gen4 gPTP 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.
> > +
> > +    - On R-Car S4 it is shared between RSWITCH and RAVB.
> 
> [Severity: Low]
> Is the S4 part of this accurate? The tree doesn't seem to have an EtherAVB
> on S4:
> 
> - renesas,etheravb.yaml lists only r8a779a0, r8a779g0 and r8a779h0 under
>   renesas,etheravb-rcar-gen4. There is no renesas,etheravb-r8a779f0.
> - ravb_main.c has no S4 match.
> - r8a779f0.dtsi only has the renesas,r8a779f0-ether-switch node and no
>   etheravb node.
> 
> Also, "ptp: Add driver for R-Car Gen4" later in the series only mentions
> RSWITCH for S4.
> 
> The commit message makes the same claim:
> 
>   - On R-Car S4 it is shared between RSWITCH and RAVB.
> 
> > +    - On R-Car V4H it is shared between RTSN and RAVB.
> > +    - On R-Car V4M it is only used by RAVB.
> 
> [ ... ]
> 
> > +  resets:
> > +    maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - clocks
> > +  - power-domains
> > +  - resets
> 
> [Severity: Low]
> This is a minor point. On V4H, the reset (and clock) here is the RTSN
> module reset 2723, which tsn0 also uses. On S4 it would be the RSWITCH
> module.
> 
> In the final series state this does not cause a conflict:
> 
> - ptp_rcar_gen4.c never calls any reset_control API.
> - rtsn and ptp_rcar_gen4 cannot be bound at the same time because of the
>   exclusive MMIO claim described below.
> 
> Once that register overlap is resolved and both drivers can bind,
> rtsn_reset() would pulse the shared line:
> 
> drivers/net/ethernet/renesas/rtsn.c:rtsn_reset() {
>     ...
> 	reset_control_reset(priv->reset);
>     ...
> }
> 
> Would that reset the timer that RAVB relies on?
> 
> "ptp: Add driver for R-Car Gen4" says the gPTP shares its clock and reset
> with RSWITCH or RTSN. Could the binding description say so too?
> 
> > +
> > +additionalProperties: false
> 
> [Severity: Low]
> The binding has additionalProperties: false and no interrupts property.
> How would the timer's interrupt outputs be described on this node?
> 
> On S4, r8a779f0.dtsi routes dedicated SPIs named "gptp0_status" and
> "gptp1_status" in the rswitch node. They might come from the gPTP block,
> though they could also be RSWITCH status aggregation. The tree alone
> doesn't make that clear.
> 
> A binding should describe the hardware fully, even where the driver doesn't
> use a resource. Should an optional interrupts property be added here?
> 
> > +
> > +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: Medium]
> Isn't this the same register window that renesas,ethertsn.yaml already
> requires as the second reg entry of the RTSN node?
> 
> Documentation/devicetree/bindings/net/renesas,ethertsn.yaml:
>   reg-names:
>     items:
>       - const: tsnes
>       - const: gptp
> 
> r8a779g0.dtsi uses this window in tsn0:
> 
> 		tsn0: ethernet@e6460000 {
> 			compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
> 			reg = <0 0xe6460000 0 0x7000>,
> 			      <0 0xe6449000 0 0x500>;
> 			reg-names = "tsnes", "gptp";
> 
> rtsn_probe() maps that region exclusively and registers its own PHC on it:
> 
> drivers/net/ethernet/renesas/rtsn.c:rtsn_probe() {
>     ...
> 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
>     ...
> 	ptpaddr = devm_ioremap_resource(&pdev->dev, res);
>     ...
> 	priv->ptp_priv = rcar_gen4_ptp_alloc(pdev, ptpaddr);
>     ...
> }
> 
> Later in the series, "arm64: dts: renesas: r8a779g0: Add gPTP node" adds a
> ptp@e6449000 node with the same reg, clock and reset. In "ptp: Add driver
> for R-Car Gen4", ptp_rcar_gen4_probe() maps it with
> devm_platform_ioremap_resource(), which is also an exclusive request.
> 
> Take a V4H board with &tsn0 enabled, such as White Hawk Single. If it also
> enables &gptp so that RAVB can use ptp-timer = <&gptp>, won't whichever of
> rtsn and ptp_rcar_gen4 probes second fail with -EBUSY? That would lose
> either the TSN interface or the PTP clock that RAVB needs.
> 
> S4 has a similar overlap. The gPTP block sits at RSWITCH base +
> RSWITCH_GPTP_OFFSET_S4, inside the base region that renesas_eth_sw_probe()
> maps exclusively. A renesas,r8a779f0-gptp node written to this binding
> would overlap that region.
> 
> dtc doesn't check for reg overlap between non-sibling nodes, so this would
> only show up at runtime.
> 
> Is there a transition plan for the gptp reg entry in renesas,ethertsn.yaml
> and for the rswitch mapping, such as deprecating the ethertsn gptp reg?
> The commit message doesn't mention the overlap or the DT ABI impact.
> 
> > +            clocks = <&cpg CPG_MOD 2723>;
> > +            power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +            resets = <&cpg 2723>;
> > +    };
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index fe23913b1e432..085fedac38ef5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -23822,6 +23822,12 @@ S:	Maintained
> >  F:	Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
> >  F:	drivers/mtd/nand/raw/renesas-nand-controller.c
> >  
> > +RENESAS R-CAR GEN4 GPTP DRIVER
> > +M:	Niklas Söderlund <niklas.soderlund@ragnatech.se>
> > +L:	linux-renesas-soc@vger.kernel.org
> > +S:	Supported
> > +F:	Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> 
> [Severity: Low]
> This is a minor note. At this point the "GPTP DRIVER" section lists only
> the binding, and nothing binds renesas,rcar-gen4-gptp yet.
> 
> Later in the series this is resolved. "ptp: Add driver for R-Car Gen4"
> adds F: drivers/ptp/ptp_rcar_gen4.c to this section, along with a platform
> driver that matches renesas,rcar-gen4-gptp. Putting the binding before the
> driver looks fine.
> 
> > +
> >  RENESAS R-CAR GYROADC DRIVER
> >  M:	Marek Vasut <marek.vasut+renesas@mailbox.org>
> >  L:	linux-iio@vger.kernel.org
> 
> -- 
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110080727.2377040-1-niklas.soderlund%2Brenesas%40ragnatech.se

-- 
Kind Regards,
Niklas Söderlund

[PATCH net-next v8 2/3] ptp: Add driver for R-Car Gen4

[Niklas Söderlund]

Add driver for the gPTP timer found on R-Car Gen4 devices. The timer is
system-wide and shared by different Ethernet devices on each Gen4
platform. The operation of the timer is however not completely in
depended of the systems Ethernet devices.

  - On R-Car S4 is gated by the RSWITCH Ethernet module clock.

  - On R-Car V4H is gated by the RTSN Ethernet module clock.

  - On R-Car V4M is gated by its own module clock, the system have
    neither RTSN or RSWITCH device. But the module clock is the same as
    RTSN on V4H and the documentation referees to it as tsn (EtherTSN).

The gPTP device do have its own register space on all three platforms.
But on S4 and V4H it will share its clock and reset property with
RSWITCH or RTSN, respectively.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
---
* Changes since v5
- Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().

* Changes since v4
- Drop mod_devicetable.h include.
- Remove clap of register value as .max_adj prevents any overflow.

* Changes since v3
- Clamp increment calculated to register limitations.
- Check return value of clk_get_rate().
- Disable PM if ptp_clock_register() fails.
---
 MAINTAINERS                 |   1 +
 drivers/ptp/Kconfig         |  12 ++
 drivers/ptp/Makefile        |   1 +
 drivers/ptp/ptp_rcar_gen4.c | 225 ++++++++++++++++++++++++++++++++++++
 4 files changed, 239 insertions(+)
 create mode 100644 drivers/ptp/ptp_rcar_gen4.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 085fedac38ef..d7ad3e1b5295 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23827,6 +23827,7 @@ M:	Niklas Söderlund <niklas.soderlund@ragnatech.se>
 L:	linux-renesas-soc@vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
+F:	drivers/ptp/ptp_rcar_gen4.c
 
 RENESAS R-CAR GYROADC DRIVER
 M:	Marek Vasut <marek.vasut+renesas@mailbox.org>
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index feb50f8cc406..573334a66557 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -264,4 +264,16 @@ config PTP_NETC_V4_TIMER
 	  synchronization. It also supports periodic output signal (e.g. PPS)
 	  and external trigger timestamping.
 
+config PTP_RCAR_GEN4
+	tristate "Renesas R-Car Gen4 PTP Driver"
+	depends on ARCH_RENESAS || COMPILE_TEST
+	depends on PTP_1588_CLOCK
+	help
+	  This driver adds support for using the Renesas R-Car Gen4 gPTP timer
+	  as a PTP clock, the clock can then be used by Gen4 Ethernet drivers
+	  for PTP time synchronization.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called ptp_rcar_gen4.
+
 endmenu
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index bdc47e284f14..0464a586bed2 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_PTP_1588_CLOCK_OCP)	+= ptp_ocp.o
 obj-$(CONFIG_PTP_DFL_TOD)		+= ptp_dfl_tod.o
 obj-$(CONFIG_PTP_S390)			+= ptp_s390.o
 obj-$(CONFIG_PTP_NETC_V4_TIMER)		+= ptp_netc.o
+obj-$(CONFIG_PTP_RCAR_GEN4)		+= ptp_rcar_gen4.o
diff --git a/drivers/ptp/ptp_rcar_gen4.c b/drivers/ptp/ptp_rcar_gen4.c
new file mode 100644
index 000000000000..e82b6c5abc30
--- /dev/null
+++ b/drivers/ptp/ptp_rcar_gen4.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Renesas R-Car Gen4 gPTP device driver
+ *
+ * Copyright (C) 2026 Renesas Electronics Corporation
+ * Copyright (C) 2026 Niklas Söderlund <niklas.soderlund@ragnatech.se>
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/ptp_clock_kernel.h>
+#include <linux/types.h>
+
+#define PTPTMEC_REG		0x0010
+#define PTPTMDC_REG		0x0014
+#define PTPTIVC0_REG		0x0020
+#define PTPTOVC00_REG		0x0030
+#define PTPTOVC10_REG		0x0034
+#define PTPTOVC20_REG		0x0038
+#define PTPGPTPTM00_REG		0x0050
+#define PTPGPTPTM10_REG		0x0054
+#define PTPGPTPTM20_REG		0x0058
+
+struct ptp_rcar_gen4_priv {
+	void __iomem *base;
+	struct clk *clk;
+
+	struct ptp_clock *clock;
+	struct ptp_clock_info info;
+
+	spinlock_t lock;	/* Registers access. */
+	s64 default_addend;
+};
+
+#define ptp_to_priv(ptp) container_of(ptp, struct ptp_rcar_gen4_priv, info)
+
+static int ptp_rcar_gen4_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
+{
+	struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+	s64 addend = priv->default_addend;
+	bool neg_adj = scaled_ppm < 0;
+	unsigned long flags;
+	s64 diff;
+
+	if (neg_adj)
+		scaled_ppm = -scaled_ppm;
+	diff = div_s64(addend * scaled_ppm_to_ppb(scaled_ppm), NSEC_PER_SEC);
+	addend = neg_adj ? addend - diff : addend + diff;
+
+	spin_lock_irqsave(&priv->lock, flags);
+	iowrite32(addend, priv->base + PTPTIVC0_REG);
+	spin_unlock_irqrestore(&priv->lock, flags);
+
+	return 0;
+}
+
+static void _ptp_rcar_gen4_gettime(struct ptp_clock_info *ptp,
+				   struct timespec64 *ts)
+{
+	struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+
+	lockdep_assert_held(&priv->lock);
+
+	ts->tv_nsec = ioread32(priv->base + PTPGPTPTM00_REG);
+	ts->tv_sec = ioread32(priv->base + PTPGPTPTM10_REG) |
+		((s64)ioread32(priv->base + PTPGPTPTM20_REG) << 32);
+}
+
+static int ptp_rcar_gen4_gettime(struct ptp_clock_info *ptp,
+				 struct timespec64 *ts)
+{
+	struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+	unsigned long flags;
+
+	spin_lock_irqsave(&priv->lock, flags);
+	_ptp_rcar_gen4_gettime(ptp, ts);
+	spin_unlock_irqrestore(&priv->lock, flags);
+
+	return 0;
+}
+
+static void _ptp_rcar_gen4_settime(struct ptp_clock_info *ptp,
+				   const struct timespec64 *ts)
+{
+	struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+
+	lockdep_assert_held(&priv->lock);
+
+	iowrite32(1, priv->base + PTPTMDC_REG);
+	iowrite32(0, priv->base + PTPTOVC20_REG);
+	iowrite32(0, priv->base + PTPTOVC10_REG);
+	iowrite32(0, priv->base + PTPTOVC00_REG);
+	iowrite32(1, priv->base + PTPTMEC_REG);
+	iowrite32(ts->tv_sec >> 32, priv->base + PTPTOVC20_REG);
+	iowrite32(ts->tv_sec, priv->base + PTPTOVC10_REG);
+	iowrite32(ts->tv_nsec, priv->base + PTPTOVC00_REG);
+}
+
+static int ptp_rcar_gen4_settime(struct ptp_clock_info *ptp,
+				 const struct timespec64 *ts)
+{
+	struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+	unsigned long flags;
+
+	spin_lock_irqsave(&priv->lock, flags);
+	_ptp_rcar_gen4_settime(ptp, ts);
+	spin_unlock_irqrestore(&priv->lock, flags);
+
+	return 0;
+}
+
+static int ptp_rcar_gen4_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+	struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+	struct timespec64 ts;
+	unsigned long flags;
+	s64 now;
+
+	spin_lock_irqsave(&priv->lock, flags);
+	_ptp_rcar_gen4_gettime(ptp, &ts);
+	now = ktime_to_ns(timespec64_to_ktime(ts));
+	ts = ns_to_timespec64(now + delta);
+	_ptp_rcar_gen4_settime(ptp, &ts);
+	spin_unlock_irqrestore(&priv->lock, flags);
+
+	return 0;
+}
+
+static struct ptp_clock_info ptp_rcar_gen4_info = {
+	.owner = THIS_MODULE,
+	.name = "R-Car Gen4 gPTP",
+	.max_adj = 50000000,
+	.adjfine = ptp_rcar_gen4_adjfine,
+	.adjtime = ptp_rcar_gen4_adjtime,
+	.gettime64 = ptp_rcar_gen4_gettime,
+	.settime64 = ptp_rcar_gen4_settime,
+};
+
+static int ptp_rcar_gen4_probe(struct platform_device *pdev)
+{
+	struct ptp_rcar_gen4_priv *priv;
+	struct device *dev = &pdev->dev;
+	unsigned long rate;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, priv);
+
+	priv->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk))
+		return PTR_ERR(priv->clk);
+
+	rate = clk_get_rate(priv->clk);
+	if (!rate)
+		return -ENODEV;
+
+	spin_lock_init(&priv->lock);
+
+	priv->info = ptp_rcar_gen4_info;
+
+	/* Default timer increment in ns.
+	 * bit[31:27] - integer
+	 * bit[26:0]  - decimal
+	 * increment[ns] = perid[ns] * 2^27 => (1ns * 2^27) / rate[hz]
+	 */
+
+	priv->default_addend = div_s64(1000000000LL << 27, rate);
+
+	pm_runtime_enable(dev);
+	pm_runtime_resume_and_get(dev);
+
+	iowrite32(priv->default_addend, priv->base + PTPTIVC0_REG);
+	iowrite32(1, priv->base + PTPTMEC_REG);
+
+	priv->clock = ptp_clock_register(&priv->info, dev);
+	if (IS_ERR(priv->clock)) {
+		pm_runtime_put_sync(dev);
+		pm_runtime_disable(dev);
+		return PTR_ERR(priv->clock);
+	}
+
+	return 0;
+}
+
+static void ptp_rcar_gen4_remove(struct platform_device *pdev)
+{
+	struct ptp_rcar_gen4_priv *priv = platform_get_drvdata(pdev);
+	struct device *dev = &pdev->dev;
+
+	ptp_clock_unregister(priv->clock);
+
+	iowrite32(1, priv->base + PTPTMDC_REG);
+
+	pm_runtime_put_sync(dev);
+	pm_runtime_disable(dev);
+}
+
+static const struct of_device_id ptp_rcar_gen4_of_match[] = {
+	{ .compatible = "renesas,rcar-gen4-gptp", },
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ptp_rcar_gen4_of_match);
+
+static struct platform_driver ptp_rcar_gen4_driver = {
+	.driver = {
+		.name = "ptp-rcar-gen4",
+		.of_match_table = ptp_rcar_gen4_of_match,
+	},
+	.probe    = ptp_rcar_gen4_probe,
+	.remove   = ptp_rcar_gen4_remove,
+};
+module_platform_driver(ptp_rcar_gen4_driver);
+
+MODULE_AUTHOR("Niklas Söderlund");
+MODULE_DESCRIPTION("Renesas R-Car Gen4 gPTP driver");
+MODULE_LICENSE("GPL");
-- 
2.55.0

Re: [PATCH net-next v8 2/3] ptp: Add driver for R-Car Gen4

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] ptp: rcar_gen4: check pm_runtime_resume_and_get() in
  ptp_rcar_gen4_probe()
- [Low] ptp: rcar_gen4: missing PTPTMDC_REG write on error in
  ptp_rcar_gen4_probe()
--

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

ptp: Add driver for R-Car Gen4

This commit adds a PTP clock driver for the system-wide gPTP timer found
on Renesas R-Car Gen4 SoCs.

> diff --git a/drivers/ptp/ptp_rcar_gen4.c b/drivers/ptp/ptp_rcar_gen4.c
> new file mode 100644
> index 0000000000000..e82b6c5abc306
> --- /dev/null
> +++ b/drivers/ptp/ptp_rcar_gen4.c

[ ... ]

> +static int ptp_rcar_gen4_probe(struct platform_device *pdev)
> +{

[ ... ]

> +	pm_runtime_enable(dev);
> +	pm_runtime_resume_and_get(dev);

[Severity: Medium]
Should ptp_rcar_gen4_probe() check the return value of
pm_runtime_resume_and_get()?  If runtime resume fails, the device remains
suspended and its usage reference is already dropped, so the following
iowrite32() calls access unclocked registers and a later
pm_runtime_put_sync() in the error or remove path will underflow
dev->power.usage_count.

> +
> +	iowrite32(priv->default_addend, priv->base + PTPTIVC0_REG);
> +	iowrite32(1, priv->base + PTPTMEC_REG);
> +
> +	priv->clock = ptp_clock_register(&priv->info, dev);
> +	if (IS_ERR(priv->clock)) {
> +		pm_runtime_put_sync(dev);
> +		pm_runtime_disable(dev);
> +		return PTR_ERR(priv->clock);
> +	}

[Severity: Low]
Should the ptp_clock_register() error path also write 1 to PTPTMDC_REG as
ptp_rcar_gen4_remove() does?  On R-Car S4 and V4H the gPTP block shares
its module clock with the Ethernet controller, so pm_runtime_put_sync()
does not gate the clock while the Ethernet device is active, leaving the
hardware timer running after a failed probe.

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

Re: [PATCH net-next v8 2/3] ptp: Add driver for R-Car Gen4

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 2 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new drivers/ptp/ptp_rcar_gen4.c is a second, standalone
  driver for a gPTP block that rtsn (V4H) and rswitch (S4) already map…
- [Medium] ptp_rcar_gen4_probe() calls pm_runtime_resume_and_get(dev) and
  throws away the result.
- [Low] ptp_rcar_gen4_probe() programs the increment and starts the timer
  (iowrite32(1, PTPTMEC_REG), line 182) before ptp_clock_register().

--

ptp: Add driver for R-Car Gen4

This commit adds a standalone PTP clock driver for the gPTP timer found
on R-Car Gen4 SoCs (S4, V4H and V4M). The timer is described as
system-wide and shared by the Ethernet devices. On S4 and V4H it shares
its clock and reset with RSWITCH or RTSN respectively.

> diff --git a/drivers/ptp/ptp_rcar_gen4.c b/drivers/ptp/ptp_rcar_gen4.c
> new file mode 100644
> index 0000000000000..e82b6c5abc306
> --- /dev/null
> +++ b/drivers/ptp/ptp_rcar_gen4.c
> @@ -0,0 +1,225 @@

[ ... ]

> +static int ptp_rcar_gen4_probe(struct platform_device *pdev)
> +{
> +	struct ptp_rcar_gen4_priv *priv;
> +	struct device *dev = &pdev->dev;
> +	unsigned long rate;
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	priv->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(priv->base))
> +		return PTR_ERR(priv->base);

[Severity: Medium]
How is this driver meant to coexist with the existing users of the same
gPTP block on S4 and V4H?

On V4H, tsn0 in r8a779g0.dtsi already lists this register range as its
"gptp" resource:

arch/arm64/boot/dts/renesas/r8a779g0.dtsi:
	reg = <0 0xe6460000 0 0x7000>,
	      <0 0xe6449000 0 0x500>;
	reg-names = "tsnes", "gptp";

rtsn_probe() requests and maps that range:

drivers/net/ethernet/renesas/rtsn.c:rtsn_probe() {
    ...
	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
    ...
	ptpaddr = devm_ioremap_resource(&pdev->dev, res);
    ...
	priv->ptp_priv = rcar_gen4_ptp_alloc(pdev, ptpaddr);
    ...
}

The binding example for this driver uses the same reg = <0xe6449000
0x500>, and so does the r8a779g0 gptp node added later in this series.
devm_ioremap_resource() and devm_platform_ioremap_resource() both call
request_mem_region().

If a board enables both nodes, wouldn't the second driver to probe fail
with -EBUSY? That would lose either the TSN port or the new PHC. The
later gptp node is added disabled, so no in-tree board hits this yet.

On S4, rswitch_probe() maps its whole register region and reaches the
gPTP inside it:

drivers/net/ethernet/renesas/rswitch_main.c:rswitch_probe() {
    ...
	priv->addr = devm_ioremap_resource(&pdev->dev, res);
    ...
	priv->ptp_priv =
		rcar_gen4_ptp_alloc(pdev, priv->addr + RSWITCH_GPTP_OFFSET_S4);
    ...
}

An S4 gptp node looks like it would collide in the same way.

This driver is also very close to the existing
drivers/net/ethernet/renesas/rcar_gen4_ptp.c, which rtsn and rswitch
already use. Both have the same PTPTMEC, PTPTMDC, PTPTIVC0, PTPTOVC*
and PTPGPTPTM* register map, and the same adjfine, gettime, settime
and adjtime logic. The commit message doesn't mention that code, and
neither consumer is converted.

The Kconfig help says the clock "can then be used by Gen4 Ethernet
drivers". In-tree, only ravb consumes an external timer, through the
"ptp-timer" phandle and ptp_clock_index_by_of_node(). rtsn and rswitch
drive the block privately, so the shared-timer setup described in the
commit message doesn't seem reachable on S4 and V4H.

Could the commit message say how the two implementations relate? Or
should rtsn and rswitch be converted to use this PHC?

[ ... ]

> +	pm_runtime_enable(dev);
> +	pm_runtime_resume_and_get(dev);

[Severity: Medium]
Should the return value of pm_runtime_resume_and_get() be checked here?

pm_runtime_resume_and_get() calls pm_runtime_get_active(dev, 0), which
drops the usage reference itself when the resume fails:

include/linux/pm_runtime.h:pm_runtime_get_active() {
	...
	ret = __pm_runtime_resume(dev, RPM_GET_PUT | rpmflags);
	if (ret < 0) {
		pm_runtime_put_noidle(dev);
		return ret;
	}
	...
}

If the clock enable or power domain power-on fails, probe still writes
PTPTIVC0 and PTPTMEC to a module that isn't clocked. It then registers
a PHC whose gettime64, settime64, adjfine and adjtime callbacks access
the same unpowered registers. Userspace can reach those callbacks
through clock_gettime() and the PTP ioctls.

The ptp_clock_register() error path below and ptp_rcar_gen4_remove()
both call pm_runtime_put_sync() for a reference that was never taken.
That ends in rpm_drop_usage_count(), which warns "Runtime PM usage
count underflow!" and returns -EINVAL.

The v6 changelog says pm_runtime_resume_and_get() was chosen on
purpose. Was the usual check and bail-out after it left out by
accident?

> +
> +	iowrite32(priv->default_addend, priv->base + PTPTIVC0_REG);
> +	iowrite32(1, priv->base + PTPTMEC_REG);
> +
> +	priv->clock = ptp_clock_register(&priv->info, dev);
> +	if (IS_ERR(priv->clock)) {
> +		pm_runtime_put_sync(dev);
> +		pm_runtime_disable(dev);
> +		return PTR_ERR(priv->clock);
> +	}

[Severity: Low]
If ptp_clock_register() fails, does this leave the timer running?

The timer is started with iowrite32(1, priv->base + PTPTMEC_REG) before
registration. This error path never writes PTPTMDC_REG, but
ptp_rcar_gen4_remove() does:

	iowrite32(1, priv->base + PTPTMDC_REG);

On S4 and V4H the module clock is shared with RSWITCH or RTSN.
Dropping this device's runtime PM reference therefore may not gate
the clock. The counter would keep running with this driver's increment
and no software owner.

rcar_gen4_ptp_register() avoids this by setting PTPTMEC only after
ptp_clock_register() succeeds. Could the same ordering be used here,
or could PTPTMDC be written on this error path?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110080727.2377040-1-niklas.soderlund%2Brenesas%40ragnatech.se

Re: [PATCH net-next v8 2/3] ptp: Add driver for R-Car Gen4

[Niklas Söderlund]

On 2026-11-14 10:17:49 +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 2 · Low: 1
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] The new drivers/ptp/ptp_rcar_gen4.c is a second, standalone
>   driver for a gPTP block that rtsn (V4H) and rswitch (S4) already map…

That is correct, please read cover letter.

> - [Medium] ptp_rcar_gen4_probe() calls pm_runtime_resume_and_get(dev) and
>   throws away the result.
> - [Low] ptp_rcar_gen4_probe() programs the increment and starts the timer
>   (iowrite32(1, PTPTMEC_REG), line 182) before ptp_clock_register().
> 
> --
> 
> ptp: Add driver for R-Car Gen4
> 
> This commit adds a standalone PTP clock driver for the gPTP timer found
> on R-Car Gen4 SoCs (S4, V4H and V4M). The timer is described as
> system-wide and shared by the Ethernet devices. On S4 and V4H it shares
> its clock and reset with RSWITCH or RTSN respectively.
> 
> > diff --git a/drivers/ptp/ptp_rcar_gen4.c b/drivers/ptp/ptp_rcar_gen4.c
> > new file mode 100644
> > index 0000000000000..e82b6c5abc306
> > --- /dev/null
> > +++ b/drivers/ptp/ptp_rcar_gen4.c
> > @@ -0,0 +1,225 @@
> 
> [ ... ]
> 
> > +static int ptp_rcar_gen4_probe(struct platform_device *pdev)
> > +{
> > +	struct ptp_rcar_gen4_priv *priv;
> > +	struct device *dev = &pdev->dev;
> > +	unsigned long rate;
> > +
> > +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +	if (!priv)
> > +		return -ENOMEM;
> > +
> > +	platform_set_drvdata(pdev, priv);
> > +
> > +	priv->base = devm_platform_ioremap_resource(pdev, 0);
> > +	if (IS_ERR(priv->base))
> > +		return PTR_ERR(priv->base);
> 
> [Severity: Medium]
> How is this driver meant to coexist with the existing users of the same
> gPTP block on S4 and V4H?
> 
> On V4H, tsn0 in r8a779g0.dtsi already lists this register range as its
> "gptp" resource:
> 
> arch/arm64/boot/dts/renesas/r8a779g0.dtsi:
> 	reg = <0 0xe6460000 0 0x7000>,
> 	      <0 0xe6449000 0 0x500>;
> 	reg-names = "tsnes", "gptp";
> 
> rtsn_probe() requests and maps that range:
> 
> drivers/net/ethernet/renesas/rtsn.c:rtsn_probe() {
>     ...
> 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
>     ...
> 	ptpaddr = devm_ioremap_resource(&pdev->dev, res);
>     ...
> 	priv->ptp_priv = rcar_gen4_ptp_alloc(pdev, ptpaddr);
>     ...
> }
> 
> The binding example for this driver uses the same reg = <0xe6449000
> 0x500>, and so does the r8a779g0 gptp node added later in this series.
> devm_ioremap_resource() and devm_platform_ioremap_resource() both call
> request_mem_region().
> 
> If a board enables both nodes, wouldn't the second driver to probe fail
> with -EBUSY? That would lose either the TSN port or the new PHC. The
> later gptp node is added disabled, so no in-tree board hits this yet.
> 
> On S4, rswitch_probe() maps its whole register region and reaches the
> gPTP inside it:
> 
> drivers/net/ethernet/renesas/rswitch_main.c:rswitch_probe() {
>     ...
> 	priv->addr = devm_ioremap_resource(&pdev->dev, res);
>     ...
> 	priv->ptp_priv =
> 		rcar_gen4_ptp_alloc(pdev, priv->addr + RSWITCH_GPTP_OFFSET_S4);
>     ...
> }
> 
> An S4 gptp node looks like it would collide in the same way.
> 
> This driver is also very close to the existing
> drivers/net/ethernet/renesas/rcar_gen4_ptp.c, which rtsn and rswitch
> already use. Both have the same PTPTMEC, PTPTMDC, PTPTIVC0, PTPTOVC*
> and PTPGPTPTM* register map, and the same adjfine, gettime, settime
> and adjtime logic. The commit message doesn't mention that code, and
> neither consumer is converted.
> 
> The Kconfig help says the clock "can then be used by Gen4 Ethernet
> drivers". In-tree, only ravb consumes an external timer, through the
> "ptp-timer" phandle and ptp_clock_index_by_of_node(). rtsn and rswitch
> drive the block privately, so the shared-timer setup described in the
> commit message doesn't seem reachable on S4 and V4H.
> 
> Could the commit message say how the two implementations relate? Or
> should rtsn and rswitch be converted to use this PHC?
> 
> [ ... ]
> 
> > +	pm_runtime_enable(dev);
> > +	pm_runtime_resume_and_get(dev);
> 
> [Severity: Medium]
> Should the return value of pm_runtime_resume_and_get() be checked here?
> 
> pm_runtime_resume_and_get() calls pm_runtime_get_active(dev, 0), which
> drops the usage reference itself when the resume fails:
> 
> include/linux/pm_runtime.h:pm_runtime_get_active() {
> 	...
> 	ret = __pm_runtime_resume(dev, RPM_GET_PUT | rpmflags);
> 	if (ret < 0) {
> 		pm_runtime_put_noidle(dev);
> 		return ret;
> 	}
> 	...
> }
> 
> If the clock enable or power domain power-on fails, probe still writes
> PTPTIVC0 and PTPTMEC to a module that isn't clocked. It then registers
> a PHC whose gettime64, settime64, adjfine and adjtime callbacks access
> the same unpowered registers. Userspace can reach those callbacks
> through clock_gettime() and the PTP ioctls.
> 
> The ptp_clock_register() error path below and ptp_rcar_gen4_remove()
> both call pm_runtime_put_sync() for a reference that was never taken.
> That ends in rpm_drop_usage_count(), which warns "Runtime PM usage
> count underflow!" and returns -EINVAL.
> 
> The v6 changelog says pm_runtime_resume_and_get() was chosen on
> purpose. Was the usual check and bail-out after it left out by
> accident?
> 
> > +
> > +	iowrite32(priv->default_addend, priv->base + PTPTIVC0_REG);
> > +	iowrite32(1, priv->base + PTPTMEC_REG);
> > +
> > +	priv->clock = ptp_clock_register(&priv->info, dev);
> > +	if (IS_ERR(priv->clock)) {
> > +		pm_runtime_put_sync(dev);
> > +		pm_runtime_disable(dev);
> > +		return PTR_ERR(priv->clock);
> > +	}
> 
> [Severity: Low]
> If ptp_clock_register() fails, does this leave the timer running?
> 
> The timer is started with iowrite32(1, priv->base + PTPTMEC_REG) before
> registration. This error path never writes PTPTMDC_REG, but
> ptp_rcar_gen4_remove() does:
> 
> 	iowrite32(1, priv->base + PTPTMDC_REG);
> 
> On S4 and V4H the module clock is shared with RSWITCH or RTSN.
> Dropping this device's runtime PM reference therefore may not gate
> the clock. The counter would keep running with this driver's increment
> and no software owner.
> 
> rcar_gen4_ptp_register() avoids this by setting PTPTMEC only after
> ptp_clock_register() succeeds. Could the same ordering be used here,
> or could PTPTMDC be written on this error path?
> 
> -- 
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110080727.2377040-1-niklas.soderlund%2Brenesas%40ragnatech.se

-- 
Kind Regards,
Niklas Söderlund

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

[Niklas Söderlund]

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

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
* Changes since v2
- Preserve sort order by unit-address.

* Changes since v1
- Rename node ptp.
---
 arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
index 5284923b6cef..f2d6696680db 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>;
+			clocks = <&cpg CPG_MOD 2723>;
+			power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+			resets = <&cpg 2723>;
+			status = "disabled";
+		};
+
 		tsn0: ethernet@e6460000 {
 			compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
 			reg = <0 0xe6460000 0 0x7000>,
-- 
2.55.0

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

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new `gptp: ptp@e6449000` node in
  arch/arm64/boot/dts/renesas/r8a779g0.dtsi uses `reg = <0 0xe6449000 0…

--

arm64: dts: renesas: r8a779g0: Add gPTP node

This adds a gptp: ptp@e6449000 node to the R-Car V4H SoC dtsi. The commit
message says the gPTP module is shared between the RAVB and RTSN Ethernet
devices.

> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> index 5284923b6cef7..f2d6696680db8 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>;
> +			clocks = <&cpg CPG_MOD 2723>;
> +			power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> +			resets = <&cpg 2723>;
> +			status = "disabled";
> +		};
> +
>  		tsn0: ethernet@e6460000 {
>  			compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
>  			reg = <0 0xe6460000 0 0x7000>,

[Severity: Medium]
Can tsn0 and the new gptp node both be enabled on the same board?

The existing tsn0 node, which this patch does not change, already claims
the same window as its second reg entry:

	tsn0: ethernet@e6460000 {
		reg = <0 0xe6460000 0 0x7000>,
		      <0 0xe6449000 0 0x500>;
		reg-names = "tsnes", "gptp";
		...
		clocks = <&cpg CPG_MOD 2723>;
		resets = <&cpg 2723>;

rtsn_probe() in drivers/net/ethernet/renesas/rtsn.c maps that region
exclusively and runs the timer itself:

	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
	...
	ptpaddr = devm_ioremap_resource(&pdev->dev, res);
	if (IS_ERR(ptpaddr)) {
		ret = PTR_ERR(ptpaddr);
		goto error_free;
	}

	priv->ptp_priv = rcar_gen4_ptp_alloc(pdev, ptpaddr);

ptp_rcar_gen4_probe() in drivers/ptp/ptp_rcar_gen4.c claims the same
range:

	priv->base = devm_platform_ioremap_resource(pdev, 0);
	if (IS_ERR(priv->base))
		return PTR_ERR(priv->base);

If a board sets both &tsn0 and &gptp to okay, the device that probes
second should get -EBUSY from its request on 0xe6449000-0xe64494ff. When
rtsn is the one that fails, the whole TSN Ethernet interface is lost,
because a failed gptp mapping takes the error_free path in rtsn_probe().

The commit message says:

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

The new renesas,rcar-gen4-gptp.yaml binding also says "On R-Car V4H it is
shared between RTSN and RAVB". However, renesas,ethertsn.yaml still
requires the gptp reg entry on the TSN node. rtsn also has no ptp-timer
phandle path. No DTS under arch/arm64/boot/dts/renesas/ references &gptp
yet, so RAVB is not connected to this node either. RAVB uses the timer
only through of_parse_phandle(..., "ptp-timer", 0).

Would it make sense to either move RTSN over to the shared node or
document that the two nodes are mutually exclusive? Moving RTSN would mean
dropping the gptp reg from tsn0 and from the ethertsn binding, and
switching rtsn to a ptp-timer phandle.

A shared-node conversion would also need to handle reset 2723. rtsn takes
it with the exclusive devm_reset_control_get() and pulses it in
rtsn_reset(). That looks like it would wipe the timer setup, which
ptp_rcar_gen4_probe() writes only once.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110080727.2377040-1-niklas.soderlund%2Brenesas%40ragnatech.se

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

[Niklas Söderlund]

On 2026-11-14 10:17:51 +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] The new `gptp: ptp@e6449000` node in
>   arch/arm64/boot/dts/renesas/r8a779g0.dtsi uses `reg = <0 0xe6449000 0…

That is correct, please read cover letter.

> 
> --
> 
> arm64: dts: renesas: r8a779g0: Add gPTP node
> 
> This adds a gptp: ptp@e6449000 node to the R-Car V4H SoC dtsi. The commit
> message says the gPTP module is shared between the RAVB and RTSN Ethernet
> devices.
> 
> > diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > index 5284923b6cef7..f2d6696680db8 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>;
> > +			clocks = <&cpg CPG_MOD 2723>;
> > +			power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +			resets = <&cpg 2723>;
> > +			status = "disabled";
> > +		};
> > +
> >  		tsn0: ethernet@e6460000 {
> >  			compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
> >  			reg = <0 0xe6460000 0 0x7000>,
> 
> [Severity: Medium]
> Can tsn0 and the new gptp node both be enabled on the same board?
> 
> The existing tsn0 node, which this patch does not change, already claims
> the same window as its second reg entry:
> 
> 	tsn0: ethernet@e6460000 {
> 		reg = <0 0xe6460000 0 0x7000>,
> 		      <0 0xe6449000 0 0x500>;
> 		reg-names = "tsnes", "gptp";
> 		...
> 		clocks = <&cpg CPG_MOD 2723>;
> 		resets = <&cpg 2723>;
> 
> rtsn_probe() in drivers/net/ethernet/renesas/rtsn.c maps that region
> exclusively and runs the timer itself:
> 
> 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gptp");
> 	...
> 	ptpaddr = devm_ioremap_resource(&pdev->dev, res);
> 	if (IS_ERR(ptpaddr)) {
> 		ret = PTR_ERR(ptpaddr);
> 		goto error_free;
> 	}
> 
> 	priv->ptp_priv = rcar_gen4_ptp_alloc(pdev, ptpaddr);
> 
> ptp_rcar_gen4_probe() in drivers/ptp/ptp_rcar_gen4.c claims the same
> range:
> 
> 	priv->base = devm_platform_ioremap_resource(pdev, 0);
> 	if (IS_ERR(priv->base))
> 		return PTR_ERR(priv->base);
> 
> If a board sets both &tsn0 and &gptp to okay, the device that probes
> second should get -EBUSY from its request on 0xe6449000-0xe64494ff. When
> rtsn is the one that fails, the whole TSN Ethernet interface is lost,
> because a failed gptp mapping takes the error_free path in rtsn_probe().
> 
> The commit message says:
> 
>     The gPTP module is shared between the RAVB and RTSN Ethernet devices on
>     the SoC.
> 
> The new renesas,rcar-gen4-gptp.yaml binding also says "On R-Car V4H it is
> shared between RTSN and RAVB". However, renesas,ethertsn.yaml still
> requires the gptp reg entry on the TSN node. rtsn also has no ptp-timer
> phandle path. No DTS under arch/arm64/boot/dts/renesas/ references &gptp
> yet, so RAVB is not connected to this node either. RAVB uses the timer
> only through of_parse_phandle(..., "ptp-timer", 0).
> 
> Would it make sense to either move RTSN over to the shared node or
> document that the two nodes are mutually exclusive? Moving RTSN would mean
> dropping the gptp reg from tsn0 and from the ethertsn binding, and
> switching rtsn to a ptp-timer phandle.
> 
> A shared-node conversion would also need to handle reset 2723. rtsn takes
> it with the exclusive devm_reset_control_get() and pulses it in
> rtsn_reset(). That looks like it would wipe the timer setup, which
> ptp_rcar_gen4_probe() writes only once.
> 
> -- 
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110080727.2377040-1-niklas.soderlund%2Brenesas%40ragnatech.se

-- 
Kind Regards,
Niklas Söderlund