Devicetree
 help / color / mirror / Atom feed
From: <JensEmil.SchulzOstergaard@microchip.com>
To: <sashiko-reviews@lists.linux.dev>
Cc: <robh@kernel.org>, <conor+dt@kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH net-next v11 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
Date: Fri, 7 Aug 2026 14:15:08 +0000	[thread overview]
Message-ID: <44fcdb0ca68c9f7bc09737240412ff904ff74652.camel@microchip.com> (raw)
In-Reply-To: <20260806143836.F095A1F00A3A@smtp.kernel.org>

On Thu, 2026-08-06 at 14:38 +0000, sashiko-bot@kernel.org wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] The schema lacks an `mdio` node definition while setting `unevaluatedProperties: false` at the root, which inadvertently prevents instantiation of the integrated PHYs referenced in the example.
> - [Medium] Invalid constraint and usage of RGMII internal delay properties in combination with `phy-mode = "rgmii"`.
> --
> 
> --- Patch [2]: [PATCH net-next v11 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings ---
> commit 36eb3256c1e8bdeb280de04a105905650e50438f
> Author: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> 
> dt-bindings: net: lan9645x: add LAN9645X switch bindings
> 
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
> 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > new file mode 100644
> > index 0000000000000..043fb48922b41
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > @@ -0,0 +1,111 @@
> [ ... ]
> > +        properties:
> > +          rx-internal-delay-ps:
> > +            const: 2000
> > +
> > +          tx-internal-delay-ps:
> > +            const: 2000
> 
> [Severity: Medium]
> Is it intended to restrict the rx-internal-delay-ps and tx-internal-delay-ps
> properties to exactly 2000?

Yes, these are the only delay values supported by the mac.

> 
> [ ... ]
> > +required:
> > +  - compatible
> > +  - reg
> > +  - ethernet-ports
> > +
> > +unevaluatedProperties: false
> 
> [Severity: Medium]
> Since the switch has integrated PHYs, will users need to define them in an
> mdio node to correctly resolve the phy-handle references?
> 
> If so, won't this unevaluatedProperties: false at the root level reject the
> device tree, as the mdio node is not defined in the properties block or
> inherited from dsa.yaml?

No, any peripherals such as MDIO controllers are meant to be child nodes of
an MFD device, as siblings of this switch node. The MDIO bus devices will
not be subnodes of this switch node, so they are not meant to be accomodated
by this schema.

> 
> [ ... ]
> > +            ethernet-port@7 {
> > +                reg = <7>;
> > +                phy-mode = "rgmii";
> > +                ethernet = <&cpu_host_port>;
> > +                rx-internal-delay-ps = <2000>;
> > +                tx-internal-delay-ps = <2000>;
> 
> [Severity: Medium]
> Can this combination of phy-mode = "rgmii" and a 2000ps internal delay be used
> here?
> 
> According to the ethernet controller bindings, phy-mode = "rgmii" implies
> the delay is implemented on the PCB. Adding a 2000ps internal MAC delay on
> top of this might result in a double delay.
> 
> If the hardware has fixed internal delays, should this use
> phy-mode = "rgmii-id" instead?

No, the intention here is to describe the situation where the CPU port and the
conduit are connected mac-to-mac. Documentation/networking/phy.rst:


* PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
  internal delay by itself, it assumes that either the Ethernet MAC (if capable)
  or the PCB traces insert the correct 1.5-2ns delay

RGMII_ID means the PHY should insert delays on both rx and tx, which would be
incorrect here.

> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260805-dsa_lan9645x_switch_driver_base-v11-0-007ebc983a0a@microchip.com?part=2


  reply	other threads:[~2026-08-07 14:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 14:34 [PATCH net-next v11 0/9] net: dsa: add DSA support for the LAN9645x switch chip family Jens Emil Schulz Østergaard
2026-08-05 14:34 ` [PATCH net-next v11 1/9] net: dsa: add tag driver for LAN9645X Jens Emil Schulz Østergaard
2026-08-06 14:38   ` sashiko-bot
2026-08-07 14:41     ` JensEmil.SchulzOstergaard
2026-08-05 14:34 ` [PATCH net-next v11 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings Jens Emil Schulz Østergaard
2026-08-06 14:38   ` sashiko-bot
2026-08-07 14:15     ` JensEmil.SchulzOstergaard [this message]
2026-08-05 14:34 ` [PATCH net-next v11 3/9] net: dsa: lan9645x: add autogenerated register macros Jens Emil Schulz Østergaard
2026-08-05 14:34 ` [PATCH net-next v11 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X Jens Emil Schulz Østergaard
2026-08-06 14:38   ` sashiko-bot
2026-08-07 14:07     ` JensEmil.SchulzOstergaard
2026-08-05 14:34 ` [PATCH net-next v11 5/9] net: dsa: lan9645x: add bridge support Jens Emil Schulz Østergaard
2026-08-06 14:38   ` sashiko-bot
2026-08-07 13:44     ` JensEmil.SchulzOstergaard
2026-08-05 14:34 ` [PATCH net-next v11 6/9] net: dsa: lan9645x: add vlan support Jens Emil Schulz Østergaard
2026-08-06 14:38   ` sashiko-bot
2026-08-07 13:40     ` JensEmil.SchulzOstergaard
2026-08-05 14:34 ` [PATCH net-next v11 7/9] net: dsa: lan9645x: add mac table integration Jens Emil Schulz Østergaard
2026-08-05 14:34 ` [PATCH net-next v11 8/9] net: dsa: lan9645x: add mdb management Jens Emil Schulz Østergaard
2026-08-06 14:38   ` sashiko-bot
2026-08-07 13:22     ` JensEmil.SchulzOstergaard
2026-08-05 14:34 ` [PATCH net-next v11 9/9] net: dsa: lan9645x: add port statistics Jens Emil Schulz Østergaard

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=44fcdb0ca68c9f7bc09737240412ff904ff74652.camel@microchip.com \
    --to=jensemil.schulzostergaard@microchip.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.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