Re: [net-next 0/3] ptp: Add driver for R-Car Gen4 gPTP timer

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

Hi Michael,

Thanks for your feedback.

On 2026-06-10 05:02:48 +0000, Michael Dege wrote:
> Hello Niklas,
> 
> Thank you for your effort to clean this driver up.
> 
> > -----Original Message-----
> > From: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > Sent: Tuesday, June 9, 2026 11:57 PM
> > To: Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> > <conor+dt@kernel.org>; Geert Uytterhoeven <geert+renesas@glider.be>; magnus.damm
> > <magnus.damm@gmail.com>; Richard Cochran <richardcochran@gmail.com>; Andrew Lunn
> > <andrew+netdev@lunn.ch>; DavidS. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>;
> > Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; linux-renesas-soc@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org
> > Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > Subject: [net-next 0/3] ptp: Add driver for R-Car Gen4 gPTP timer
> > 
> > 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 then be followed by work to add proper PTP support to the R-Car RAVB Gen4 driver,
> > which currently advertises to user-space it supports PTP but which implementation is broken and does
> > not work.
> > 
> > This will in turn 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.
> > 
> > While having both this driver and the "direct accessing of registers by the user driver" in operation
> > at the same time works, but it is not recommended. It works by chance due to how both the RTSN and
> > RSWITCH drivers internal workings.
> > 
> > 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.
> > 
> > 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.
> > 
> > As the RAVB patches depends on this series the device tree node for the gPTP clock is added in this
> > series but will be enabled and linked to consumers in the RAVB gPTP series for platforms where it will
> > not conflict with RTSN and RSWITCH. And further enabled as more of this is cleaned up.
> > 
> > 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 binding for 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                   | 219 ++++++++++++++++++
> >  6 files changed, 312 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> >  create mode 100644 drivers/ptp/ptp_rcar_gen4.c
> > 
> > --
> > 2.54.0
> > 
> Are you aware, that Gen5 is on the horizon? The first patches for X5H have been up-streamed. X5H will
> be using the same gPTP driver. I think it would be a good idea to make this driver generic, meaning
> leave out the references to Gen4. What do you think?

Ideally we should have a module name or such from the gPTP module itself 
we could use as the kernel module name, unfortunately we don't. All we 
know is this is the gPTP module first used on Gen4.

I don't want to name the module ptp_rcar as that is too generic IMHO and 
risk confusion when Gen N will be released which will have a completely 
new PTP hardware module.

Having a name with gen4 do in no way make it impossible to also use on 
Gen5 devices. We just add more compatible values. There is some 
precedence to this behavior, see the R-Car thermal drivers for example.

  $ find drivers/thermal/renesas -name \*rcar\* -exec grep \.compatible {} +
  .../rcar_thermal.c:		.compatible = "renesas,rcar-thermal",
  .../rcar_thermal.c:		.compatible = "renesas,rcar-gen2-thermal",
  .../rcar_thermal.c:		.compatible = "renesas,thermal-r8a774c0",
  .../rcar_thermal.c:		.compatible = "renesas,thermal-r8a77970",
  .../rcar_thermal.c:		.compatible = "renesas,thermal-r8a77990",
  .../rcar_thermal.c:		.compatible = "renesas,thermal-r8a77995",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a774a1-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a774b1-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a774e1-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a7795-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a7796-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a77961-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a77965-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a77980-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a779a0-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a779f0-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a779g0-thermal",
  .../rcar_gen3_thermal.c:		.compatible = "renesas,r8a779h0-thermal",

Here rcar_thermal started as the first thermal driver covering Gen1 
(ish) and later Gen2 devices. When Gen3 was released with a completely 
new thermal hardware module a new rcar_gen3_thermal driver was created 
to support it.

The thermal module supported by the rcar_gen3_thermal driver was later 
extended to also support Gen4, as the thermal hardware was used on all 
Gen4 devices too.

tl;dr, I like to give the driver a "version" designation so in future if 
more R-Car PTP hardware emerges we can distinguish them. We don't have a 
version/name of the gPTP module itself so all we know and can use is
that it was first used on Gen4 devices. So I use that like we have done 
for other R-Car hardware modules.

> 
> Best regards,
> 
> Michael

-- 
Kind Regards,
Niklas Söderlund