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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+V-a8tJp8bNNPAFmRN3WMmo1e+QPARCOkkoUdwsaiv1oDfG_A@mail.gmail.com>
Date: Fri, 9 Jan 2026 09:18:58 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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

Hi Andrew,

On Wed, Nov 26, 2025 at 9:28 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> 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.
>
Sure, I will add this in the commit message.

> 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?
>
Sorry for the delay, Ive now got the answer from the HW team:

When a link-up is reported by this pin, the hardware starts using the
port. If a 1Gbps connection is lost and then re-established at 1Gbps,
the ETHSW will transmit the buffered data. In general cases, there is
a possibility that a link that was previously at 1Gbps/Full-duplex
could, for some reason, change to 10Mbps/Half-duplex, but this is
usually unlikely. At least when using DLR, it is common to set
auto-negotiation so that both speed and duplex are fixed. If the link
comes back up at 10Mbps (a different speed than before), the EthPHY
will likely follow at 10Mbps if auto-negotiation is enabled, but the
ETHSW will continue operating at 1Gbps and start sending out the
buffered data.

If you are happy with this, I will send a v2 series updating the commit message.

Cheers.
Prabhakar