From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1
MIIC binding schema. This property allows configuring the active level
of the PHY-link signals used by the Switch, EtherCAT, and SERCOS III
interfaces.
The signal polarity is controlled by fields in the MIIC_PHYLINK register:
- SWLNK[3:0]: configures the Switch interface link signal level
0 - Active High
1 - Active Low
- CATLNK[6:4]: configures the EtherCAT interface link signal level
0 - Active Low
1 - Active High
- S3LNK[9:8]: configures the SERCOS III interface link signal level
0 - Active Low
1 - Active High
When the `renesas,miic-phylink-active-low` property is present, the
PHY-link signal is configured as active-low. When omitted, the signal
defaults to active-high.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
.../devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml b/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml
index 3adbcf56d2be..825ae8a91e8b 100644
--- a/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml
@@ -86,6 +86,13 @@ patternProperties:
and include/dt-bindings/net/renesas,r9a09g077-pcs-miic.h for RZ/N2H, RZ/T2H SoCs.
$ref: /schemas/types.yaml#/definitions/uint32
+ renesas,miic-phylink-active-low:
+ type: boolean
+ description: Indicates that the PHY-link signal provided by the Ethernet switch,
+ EtherCAT, or SERCOS3 interface is active low. When present, this property
+ sets the corresponding signal polarity to active low. When omitted, the signal
+ defaults to active high.
+
required:
- reg
- renesas,miic-input
--
2.43.0On Wed, Nov 12, 2025 at 08:19:36PM +0000, Prabhakar wrote: > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1 > MIIC binding schema. This property allows configuring the active level > of the PHY-link signals used by the Switch, EtherCAT, and SERCOS III > interfaces. > > The signal polarity is controlled by fields in the MIIC_PHYLINK register: > - SWLNK[3:0]: configures the Switch interface link signal level > 0 - Active High > 1 - Active Low > - CATLNK[6:4]: configures the EtherCAT interface link signal level > 0 - Active Low > 1 - Active High > - S3LNK[9:8]: configures the SERCOS III interface link signal level > 0 - Active Low > 1 - Active High > > When the `renesas,miic-phylink-active-low` property is present, the > PHY-link signal is configured as active-low. When omitted, the signal > defaults to active-high. Sorry, but i asked in a previous version, what is phy-link? You still don't explain what this signal is. phylib/phylink tells you about the link state, if there is a link partner, what link speed has been negotiated, duplex, pause etc. What does this signal indicate? Andrew
Hi Andrew,
On Wed, Nov 12, 2025 at 8:58 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Nov 12, 2025 at 08:19:36PM +0000, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1
> > MIIC binding schema. This property allows configuring the active level
> > of the PHY-link signals used by the Switch, EtherCAT, and SERCOS III
> > interfaces.
> >
> > The signal polarity is controlled by fields in the MIIC_PHYLINK register:
> > - SWLNK[3:0]: configures the Switch interface link signal level
> > 0 - Active High
> > 1 - Active Low
> > - CATLNK[6:4]: configures the EtherCAT interface link signal level
> > 0 - Active Low
> > 1 - Active High
> > - S3LNK[9:8]: configures the SERCOS III interface link signal level
> > 0 - Active Low
> > 1 - Active High
> >
> > When the `renesas,miic-phylink-active-low` property is present, the
> > PHY-link signal is configured as active-low. When omitted, the signal
> > defaults to active-high.
>
> Sorry, but i asked in a previous version, what is phy-link? You still
> don't explain what this signal is. phylib/phylink tells you about the
> link state, if there is a link partner, what link speed has been
> negotiated, duplex, pause etc. What does this signal indicate?
>
+----> Ethernet Switch -------->
GMAC (Synopsys IP)
|
|
MII Converter ----------+
|
+----> EtherCAT Slave Controller
|
|
+----> SERCOS Controller
Each of these IPs has its own link status pin as an input to the SoC:
SWITCH_MII_LINK: Switch PHY link status input
S3_MII_LINKP: SERCOS III link status from PHY
CAT_MII_LINK: EtherCAT link status from PHY
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.
[0] https://www.renesas.com/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-r-engine-and-ethernet-peripherals?r=1054561
Cheers,
Prabhakar
> 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.
Andrew
Hi Andrew, On Thu, Nov 13, 2025 at 9:58 PM Andrew Lunn <andrew@lunn.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. Cheers, Prabhakar
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@lunn.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
Hi Andrew, On Wed, Nov 26, 2025 at 9:28 PM Andrew Lunn <andrew@lunn.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@lunn.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
Hi Prabhakar, > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1 Hmm, we already have "renesas,ether-link-active-low" in renesas,ether.yaml and renesas,etheravb.yaml. Can't we reuse that? Happy hacking, Wolfram
Hi Wolfram,
On Wed, Nov 12, 2025 at 8:40 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> Hi Prabhakar,
>
> > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1
>
> Hmm, we already have "renesas,ether-link-active-low" in
> renesas,ether.yaml and renesas,etheravb.yaml. Can't we reuse that?
>
On the RZ/N1x we have the below architecture
+----> Ethernet Switch
| |
| v
MII Converter ----------------------+ GMAC (Synopsys IP)
|
+----> EtherCAT
Slave Controller
|
+----> SERCOS
Controller
Each of these IPs has its own link status pin as an input to the SoC:
SWITCH_MII_LINK: Switch PHY link status input
S3_MII_LINKP: SERCOS III link status from PHY
CAT_MII_LINK: EtherCAT link status from PHY
The property "renesas,ether-link-active-low" is specific to the AVB
IP. The MII converter enables connections between these IPs, and the
register for controlling the link status signal is part of the MII
converter block, so this property needs to be part of the MII
converter.
If I have misunderstood you, did you mean to rename the property to
"renesas,ether-link-active-low"?
Cheers,
Prabhakar
On Thu, Nov 13, 2025 at 02:45:18PM +0000, Lad, Prabhakar wrote: > Hi Wolfram, > > On Wed, Nov 12, 2025 at 8:40 PM Wolfram Sang > <wsa+renesas@sang-engineering.com> wrote: > > > > Hi Prabhakar, > > > > > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1 > > > > Hmm, we already have "renesas,ether-link-active-low" in > > renesas,ether.yaml and renesas,etheravb.yaml. Can't we reuse that? > > > On the RZ/N1x we have the below architecture > > +----> Ethernet Switch > | | > | v > MII Converter ----------------------+ GMAC (Synopsys IP) > | > +----> EtherCAT > Slave Controller > | > +----> SERCOS > Controller I'm not sure that diagram has come out correctly. If you're going to draw diagrams, make sure you do it using a fixed-width font. To me, it looks like the MII Converter is bolted to GMAC and only has one connection, and the GMAC has what seems to be maybe five connections. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Russell,
On Thu, Nov 13, 2025 at 3:58 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Nov 13, 2025 at 02:45:18PM +0000, Lad, Prabhakar wrote:
> > Hi Wolfram,
> >
> > On Wed, Nov 12, 2025 at 8:40 PM Wolfram Sang
> > <wsa+renesas@sang-engineering.com> wrote:
> > >
> > > Hi Prabhakar,
> > >
> > > > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1
> > >
> > > Hmm, we already have "renesas,ether-link-active-low" in
> > > renesas,ether.yaml and renesas,etheravb.yaml. Can't we reuse that?
> > >
> > On the RZ/N1x we have the below architecture
> >
> > +----> Ethernet Switch
> > | |
> > | v
> > MII Converter ----------------------+ GMAC (Synopsys IP)
> > |
> > +----> EtherCAT
> > Slave Controller
> > |
> > +----> SERCOS
> > Controller
>
> I'm not sure that diagram has come out correctly. If you're going to
> draw diagrams, make sure you do it using a fixed-width font. To me,
> it looks like the MII Converter is bolted to GMAC and only has one
> connection, and the GMAC has what seems to be maybe five connections.
>
Sorry when typing the diagram the mail client showed the diagram OK
but when sent everything was messed up. Ive represented now in a
different way.
+-----------------------+
| MII Converter |
+-----------+-----------+
|
+-----------------------------------------+-------------------------------------------+
| |
|
v v
v
+---------------------+
+---------------------------+
+------------------------------+
| Ethernet Switch | | EtherCAT Slave |
| SERCOS Controller |
+---------+------------+ | Controller
| +------------------------------+
| +---------------------------+
|
v
+-------------------------+
| GMAC (Synopsys |
| IP) |
+--------------------------+
Cheers,
Prabhakar
Hi Russell, On Thu, Nov 13, 2025 at 7:05 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > > Hi Russell, > > On Thu, Nov 13, 2025 at 3:58 PM Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Thu, Nov 13, 2025 at 02:45:18PM +0000, Lad, Prabhakar wrote: > > > Hi Wolfram, > > > > > > On Wed, Nov 12, 2025 at 8:40 PM Wolfram Sang > > > <wsa+renesas@sang-engineering.com> wrote: > > > > > > > > Hi Prabhakar, > > > > > > > > > Add the boolean DT property `renesas,miic-phylink-active-low` to the RZN1 > > > > > > > > Hmm, we already have "renesas,ether-link-active-low" in > > > > renesas,ether.yaml and renesas,etheravb.yaml. Can't we reuse that? > > > > > > > On the RZ/N1x we have the below architecture > > > > > > +----> Ethernet Switch > > > | | > > > | v > > > MII Converter ----------------------+ GMAC (Synopsys IP) > > > | > > > +----> EtherCAT > > > Slave Controller > > > | > > > +----> SERCOS > > > Controller > > > > I'm not sure that diagram has come out correctly. If you're going to > > draw diagrams, make sure you do it using a fixed-width font. To me, > > it looks like the MII Converter is bolted to GMAC and only has one > > connection, and the GMAC has what seems to be maybe five connections. > > > Sorry when typing the diagram the mail client showed the diagram OK > but when sent everything was messed up. Ive represented now in a > different way. > > +-----------------------+ > | MII Converter | > +-----------+-----------+ > | > +-----------------------------------------+-------------------------------------------+ > | | > | > v v > v > +---------------------+ > +---------------------------+ > +------------------------------+ > | Ethernet Switch | | EtherCAT Slave | > | SERCOS Controller | > +---------+------------+ | Controller > | +------------------------------+ > | +---------------------------+ > | > v > +-------------------------+ > | GMAC (Synopsys | > | IP) | > +--------------------------+ > Looks like this was messed up too, Ive pasted the diagram here now https://gist.github.com/prabhakarlad/9549df941eaced5b06efc572ff6c82b5 Sorry for the noise. Cheers, Prabhakar
© 2016 - 2026 Red Hat, Inc.