linux-kernel - Re: [PATCH net-next 1/2] dt-bindings: net: pcs: renesas,rzn1-miic: Add renesas,miic-phylink-active-low property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <116b3a93-2b65-4464-821a-cbc7aa1b3dc1@lunn.ch>
Date: Wed, 26 Nov 2025 22:28:37 +0100
From: Andrew Lunn <andrew@...n.ch>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc: Clément Léger <clement.leger@...tlin.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Magnus Damm <magnus.damm@...il.com>,
	linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Biju Das <biju.das.jz@...renesas.com>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH net-next 1/2] dt-bindings: net: pcs: renesas,rzn1-miic:
 Add renesas,miic-phylink-active-low property

On Wed, Nov 26, 2025 at 08:55:53PM +0000, Lad, Prabhakar wrote:
> Hi Andrew,
> 
> On Thu, Nov 13, 2025 at 9:58 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > Each of these IPs has its own link status pin as an input to the SoC:
> >
> > > The above architecture is for the RZ/N1 SoC. For RZ/T2H SoC we dont
> > > have a SERCOS Controller. So in the case of RZ/T2H EVK the
> > > SWITCH_MII_LINK status pin is connected to the LED1 of VSC8541 PHY.
> > >
> > > The PHYLNK register [0] (section 10.2.5 page 763) allows control of
> > > the active level of the link.
> > > 0: High active (Default)
> > > 1: Active Low
> > >
> > > For example the SWITCH requires link-up to be reported to the switch
> > > via the SWITCH_MII_LINK input pin.
> >
> > Why does the switch require this? The switch also needs to know the
> > duplex, speed etc. Link on its own is of not enough. So when phylink
> > mac_link_up is called, you tell it the speed, duplex and also that the
> > link is up. When the link goes down, mac_link_down callback will be
> > called and you tell it the link is down.
> >
> Sorry for the delayed response. I was awaiting more info from the HW
> team on this. Below is the info I got from the HW info.
> 
> EtherPHY link-up and link-down status is required as a hardware IP
> feature, regardless of whether GMAC or ETHSW is used.
> In the case of GMAC, the software retrieves this information from
> EtherPHY via MDC/MDIO and then configures GMAC accordingly. In
> contrast, ETHSW provides dedicated pins for this purpose.
> For ETHSW, this information is also necessary for communication
> between two external nodes (e.g., Node A to Node B) that does not
> involve the host CPU, as the switching occurs entirely within ETHSW.
> This is particularly important for DLR (Device Level Ring: a
> redundancy protocol used in EtherNet/IP). DLR relies on detecting
> link-down events caused by cable issues as quickly as possible to
> enable fast switchover to a redundant path. Handling such path
> switching in software introduces performance impacts, which is why
> ETHSW includes dedicated pins.
> As for Active Level configuration, it is designed to provide
> flexibility to accommodate the specifications of external EtherPHY
> devices.
> 
> Please share your thoughts.

Please add this to the commit, to make it clear what these pins are
for.

It actually seems like it is mostly relevant for link down, not up.
If the link goes down, it does not matter if it is 10Half, or 1G Full.
All you want to do is swap to a redundant path as soon as possible.

It would however be interesting it know more about link up. Does the
hardware start using the port as soon as link up is reported by this
pin? So it could be blasting frames out at 1G, until software catches
up and tells the MAC to slow down and do 10Half? So all those frames
are corrupted, causing your nice redundant network to break for a
while?

	Andrew