From: Jakub Kicinski <kuba@kernel.org>
To: niklas.soderlund+renesas@ragnatech.se
Cc: Jakub Kicinski <kuba@kernel.org>,
paul@pbarker.dev, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, geert+renesas@glider.be,
magnus.damm@gmail.com, richardcochran@gmail.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, vadim.fedorenko@linux.dev,
sergei.shtylyov@gmail.com, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next v4 09/10] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
Date: Mon, 14 Sep 2026 18:54:42 -0700 [thread overview]
Message-ID: <20260915015442.881311-1-kuba@kernel.org> (raw)
In-Reply-To: <20260909173027.2201560-10-niklas.soderlund+renesas@ragnatech.se>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4
This adds an optional ptp-timer phandle property to the EtherAVB binding
and restricts it to the renesas,etheravb-rcar-gen4 compatible, so that a
Gen4 RAVB node can reference the external system-wide gPTP clock shared
with RTSN on V4H and RSWITCH on S4.
> diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> index 1e00ef5b3acda..fad002492421a 100644
> --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
> @@ -97,6 +97,8 @@ properties:
>
> phy-handle: true
>
> + ptp-timer: true
> +
[Severity: High]
Is there an in-tree node that this phandle can point at on Gen4?
The property is re-enabled bare here, so it inherits the contract from
Documentation/devicetree/bindings/net/ethernet-controller.yaml:
ptp-timer:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Specifies a reference to a node representing an IEEE 1588 PTP device.
On Gen4 there is no standalone PTP device node. On R-Car V4H the gPTP
block only exists as a register window of the RTSN controller node in
arch/arm64/boot/dts/renesas/r8a779g0.dtsi:
tsn0: ethernet@e6460000 {
...
reg-names = "tsnes", "gptp";
and on S4 it lives inside the RSWITCH node.
The consumer added by the closing patch of this series ("net: ethernet:
ravb: Add gPTP support for Gen4") resolves the phandle in
ravb_gen4_ptp_clock_index() with ptp_clock_index_by_of_node(), which
matches through ptp_clock_of_node_match() in drivers/ptp/ptp_clock.c:
return (dev->parent && dev_of_node(dev->parent) == parent_np);
But the only Gen4 gPTP providers, rtsn.c and rswitch_main.c, both go
through rcar_gen4_ptp_register() in
drivers/net/ethernet/renesas/rcar_gen4_ptp.c:
ptp_priv->clock = ptp_clock_register(&ptp_priv->info, NULL);
With a NULL parent, ptp->dev.parent is NULL and the of_node match cannot
succeed, so ravb_gen4_ptp_clock_index() returns -1.
Does that mean a Gen4 DTS writing ptp-timer = <&tsn0> validates and is
parsed but still ends up without PTP support? If so, would it make sense
to also pass the RTSN/RSWITCH device as the ptp_clock_register() parent,
and to add a local description plus an example here so DTS authors and
reviewers have a criterion for which node is a valid target?
> '#address-cells':
> description: Number of address cells for the MDIO bus.
> const: 1
[ ... ]
> @@ -305,6 +307,15 @@ allOf:
> items:
> - const: fck
> - const: refclk
> + - if:
> + not:
> + properties:
> + compatible:
> + contains:
> + const: renesas,etheravb-rcar-gen4
> + then:
> + properties:
> + ptp-timer: false
[Severity: Low]
This isn't a bug, but one note on the ordering within the series, for the
record: at this patch alone the gated ptp-timer property has no reader,
and ravb_gen4_hw_info in drivers/net/ethernet/renesas/ravb_main.c still
sets
.ptp = &ravb_gen3_ptp_info,
which describes the internal CCC_GAC gPTP with GTI derived from fck, i.e.
the opposite hardware model from the external gPTP this binding
describes.
The following patch, "net: ethernet: ravb: Add gPTP support for Gen4",
resolves that by adding ravb_gen4_ptp_probe() with
priv->of_gptp = of_parse_phandle(priv->pdev->dev.of_node, "ptp-timer", 0);
and switching ravb_gen4_hw_info to
.ptp = &ravb_gen4_ptp_info,
so the binding change here is inert documentation on its own and nothing
needs changing for this reason alone.
next prev parent reply other threads:[~2026-09-15 1:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 17:30 [PATCH net-next v4 00/10] ravb: Add gPTP support " Niklas Söderlund
2026-09-09 17:30 ` [PATCH net-next v4 01/10] net: ethernet: ravb: Remove gPTP control from WoL setup and restore Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
2026-09-09 17:30 ` [PATCH net-next v4 02/10] net: ethernet: ravb: Move programming of gPTP timer interval Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
2026-09-09 17:30 ` [PATCH net-next v4 03/10] net: ethernet: ravb: Simplify gPTP start and stop Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
2026-09-09 17:30 ` [PATCH net-next v4 04/10] net: ethernet: ravb: Remove redundant argument to ravb_ptp_init() Niklas Söderlund
2026-09-09 17:30 ` [PATCH net-next v4 05/10] net: ethernet: ravb: Propagate error from ptp_clock_register() Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
2026-09-09 17:30 ` [PATCH net-next v4 06/10] net: ethernet: ravb: Replace gPTP flags with callbacks Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
2026-09-09 17:30 ` [PATCH net-next v4 07/10] net: ethernet: ravb: Add callback for gPTP probe Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
2026-09-09 17:30 ` [PATCH net-next v4 08/10] net: ethernet: ravb: Add callback for gPTP clock index Niklas Söderlund
2026-09-09 17:30 ` [PATCH net-next v4 09/10] dt-bindings: net: renesas,etheravb: Add optional gPTP phandle for Gen4 Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski [this message]
2026-09-09 17:30 ` [PATCH net-next v4 10/10] net: ethernet: ravb: Add gPTP support " Niklas Söderlund
2026-09-15 1:54 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260915015442.881311-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=geert+renesas@glider.be \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=pabeni@redhat.com \
--cc=paul@pbarker.dev \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=sergei.shtylyov@gmail.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®