[PATCH net-next v2 0/2] net: lan743x: add RMII support for PCI11x1x

[PATCH net-next v2 0/2] net: lan743x: add RMII support for PCI11x1x

[Thangaraj Samynathan]

This series adds RMII interface support for the Microchip PCI11x1x
Ethernet controller.

The PCI11x1x device supports RMII as an alternative MAC-PHY interface,
selected via the STRAP_READ software strap register. Patch 1 reads the
RMII strap bits from this register and sets the is_rmii_en flag. Patch 2
uses this flag to configure the PHY interface mode, phylink supported
interfaces, and enables RMII in hardware via the RMII_CTL register.

Change Log:
===========
v1 -> v2:
  - Remove redundant mac_capabilities &= ~MAC_1000FD; phylink already
    handles capability reduction for RMII via phy_caps_from_interface()
    [patch 2/2]

Thangaraj Samynathan (2):
  net: lan743x: add RMII strap status detection for PCI11x1x
  net: lan743x: add support for RMII interface

 drivers/net/ethernet/microchip/lan743x_main.c | 24 +++++++++++++++++++
 drivers/net/ethernet/microchip/lan743x_main.h |  6 +++++
 2 files changed, 30 insertions(+)

-- 
2.34.1

[PATCH net-next v2 1/2] net: lan743x: add RMII strap status detection for PCI11x1x

[Thangaraj Samynathan]

Extend pci11x1x_strap_get_status() to read the RMII strap bits from
the STRAP_READ register. The is_rmii_en flag is initialized to
false and updated based on the hardware strap only if SGMII is not
already enabled. This ensures correct interface identification during
adapter initialization.

Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
---
 drivers/net/ethernet/microchip/lan743x_main.c | 7 +++++++
 drivers/net/ethernet/microchip/lan743x_main.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index f3332417162e..7d6ffaf13b5e 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -42,6 +42,7 @@ static void pci11x1x_strap_get_status(struct lan743x_adapter *adapter)
 	u32 strap;
 	int ret;
 
+	adapter->is_rmii_en = false;
 	/* Timeout = 100 (i.e. 1 sec (10 msce * 100)) */
 	ret = lan743x_hs_syslock_acquire(adapter, 100);
 	if (ret < 0) {
@@ -73,6 +74,12 @@ static void pci11x1x_strap_get_status(struct lan743x_adapter *adapter)
 			adapter->is_sgmii_en = false;
 		}
 	}
+
+	if (!adapter->is_sgmii_en && strap & STRAP_READ_USE_RMII_EN_) {
+		if (strap & STRAP_READ_RMII_EN_)
+			adapter->is_rmii_en = true;
+	}
+
 	netif_dbg(adapter, drv, adapter->netdev,
 		  "SGMII I/F %sable\n", adapter->is_sgmii_en ? "En" : "Dis");
 }
diff --git a/drivers/net/ethernet/microchip/lan743x_main.h b/drivers/net/ethernet/microchip/lan743x_main.h
index 160d94a7cee6..1d7d37456553 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.h
+++ b/drivers/net/ethernet/microchip/lan743x_main.h
@@ -36,7 +36,9 @@
 #define FPGA_SGMII_OP			BIT(24)
 
 #define STRAP_READ			(0x0C)
+#define STRAP_READ_USE_RMII_EN_		BIT(23)
 #define STRAP_READ_USE_SGMII_EN_	BIT(22)
+#define STRAP_READ_RMII_EN_		BIT(7)
 #define STRAP_READ_SGMII_EN_		BIT(6)
 #define STRAP_READ_SGMII_REFCLK_	BIT(5)
 #define STRAP_READ_SGMII_2_5G_		BIT(4)
@@ -1071,6 +1073,7 @@ struct lan743x_adapter {
 	struct lan743x_rx       rx[LAN743X_USED_RX_CHANNELS];
 	bool			is_pci11x1x;
 	bool			is_sgmii_en;
+	bool			is_rmii_en;
 	/* protect ethernet syslock */
 	spinlock_t		eth_syslock_spinlock;
 	bool			eth_syslock_en;
-- 
2.34.1

[PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Thangaraj Samynathan]

Enable RMII interface in the lan743x driver for PHY and MAC
configuration.

- Select RMII interface in lan743x_phy_interface_select().
- Update phylink supported_interfaces and MAC capabilities.
- Enable RMII via RMII_CTL in lan743x_hardware_init().
- Define RMII_CTL register and enable bit in lan743x_main.h.

Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
---
 drivers/net/ethernet/microchip/lan743x_main.c | 17 +++++++++++++++++
 drivers/net/ethernet/microchip/lan743x_main.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 7d6ffaf13b5e..1c0484c4705d 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1370,6 +1370,8 @@ static void lan743x_phy_interface_select(struct lan743x_adapter *adapter)
 
 	if (adapter->is_pci11x1x && adapter->is_sgmii_en)
 		adapter->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	else if (adapter->is_pci11x1x && adapter->is_rmii_en)
+		adapter->phy_interface = PHY_INTERFACE_MODE_RMII;
 	else if (id_rev == ID_REV_ID_LAN7430_)
 		adapter->phy_interface = PHY_INTERFACE_MODE_GMII;
 	else if ((id_rev == ID_REV_ID_LAN7431_) && (data & MAC_CR_MII_EN_))
@@ -3158,6 +3160,12 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
 		__set_bit(PHY_INTERFACE_MODE_MII,
 			  adapter->phylink_config.supported_interfaces);
 		break;
+	case PHY_INTERFACE_MODE_RMII:
+		__set_bit(PHY_INTERFACE_MODE_RMII,
+			  adapter->phylink_config.supported_interfaces);
+		adapter->phylink_config.lpi_capabilities = 0;
+		break;
+
 	default:
 		phy_interface_set_rgmii(adapter->phylink_config.supported_interfaces);
 	}
@@ -3165,6 +3173,9 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
 	memcpy(adapter->phylink_config.lpi_interfaces,
 	       adapter->phylink_config.supported_interfaces,
 	       sizeof(adapter->phylink_config.lpi_interfaces));
+	if (adapter->phy_interface == PHY_INTERFACE_MODE_RMII)
+		__clear_bit(PHY_INTERFACE_MODE_RMII,
+			    adapter->phylink_config.lpi_interfaces);
 
 	pl = phylink_create(&adapter->phylink_config, NULL,
 			    adapter->phy_interface, &lan743x_phylink_mac_ops);
@@ -3509,6 +3520,7 @@ static int lan743x_hardware_init(struct lan743x_adapter *adapter,
 {
 	struct lan743x_tx *tx;
 	u32 sgmii_ctl;
+	u32 rmii_ctl;
 	int index;
 	int ret;
 
@@ -3530,6 +3542,11 @@ static int lan743x_hardware_init(struct lan743x_adapter *adapter,
 			sgmii_ctl |= SGMII_CTL_SGMII_POWER_DN_;
 		}
 		lan743x_csr_write(adapter, SGMII_CTL, sgmii_ctl);
+		if (adapter->is_rmii_en) {
+			rmii_ctl = lan743x_csr_read(adapter, RMII_CTL);
+			rmii_ctl |= RMII_CTL_RMII_ENABLE_;
+			lan743x_csr_write(adapter, RMII_CTL, rmii_ctl);
+		}
 	} else {
 		adapter->max_tx_channels = LAN743X_MAX_TX_CHANNELS;
 		adapter->used_tx_channels = LAN743X_USED_TX_CHANNELS;
diff --git a/drivers/net/ethernet/microchip/lan743x_main.h b/drivers/net/ethernet/microchip/lan743x_main.h
index 1d7d37456553..03f3727ed8f7 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.h
+++ b/drivers/net/ethernet/microchip/lan743x_main.h
@@ -324,6 +324,9 @@
 #define MAC_WUCSR2_IPV6_TCPSYN_RCD_	BIT(5)
 #define MAC_WUCSR2_IPV4_TCPSYN_RCD_	BIT(4)
 
+#define RMII_CTL			(0x710)
+#define RMII_CTL_RMII_ENABLE_		BIT(0)
+
 #define SGMII_ACC			(0x720)
 #define SGMII_ACC_SGMII_BZY_		BIT(31)
 #define SGMII_ACC_SGMII_WR_		BIT(30)
-- 
2.34.1

Re: [PATCH net-next v2 1/2] net: lan743x: add RMII strap status detection for PCI11x1x

[Andrew Lunn]

> +	if (!adapter->is_sgmii_en && strap & STRAP_READ_USE_RMII_EN_) {
> +		if (strap & STRAP_READ_RMII_EN_)
> +			adapter->is_rmii_en = true;
> +	}

What does it mean when both SGMII and RMII is strapped? What if
neither is strapped?

> +
>  	netif_dbg(adapter, drv, adapter->netdev,
>  		  "SGMII I/F %sable\n", adapter->is_sgmii_en ? "En" : "Dis");

Since there is a netif_dbg() for sgmii, maybe add one for rmii, so the
code is somewhat symmetrical?

>  	struct lan743x_rx       rx[LAN743X_USED_RX_CHANNELS];
>  	bool			is_pci11x1x;
>  	bool			is_sgmii_en;
> +	bool			is_rmii_en;

Are there other strapping bits? Are we going to get is_gmii_en, and
is_rgmii_en?

Does a collection of bools make sense, when the interface modes are
typically mutually exclusive at the hardware level? Would an enum be
better? Or why not phy_interface_t ?

	Andrew

Re: [PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Andrew Lunn]

On Tue, May 26, 2026 at 09:10:54PM +0530, Thangaraj Samynathan wrote:
> Enable RMII interface in the lan743x driver for PHY and MAC
> configuration.
> 
> - Select RMII interface in lan743x_phy_interface_select().
> - Update phylink supported_interfaces and MAC capabilities.
> - Enable RMII via RMII_CTL in lan743x_hardware_init().
> - Define RMII_CTL register and enable bit in lan743x_main.h.

> +	case PHY_INTERFACE_MODE_RMII:
> +		__set_bit(PHY_INTERFACE_MODE_RMII,
> +			  adapter->phylink_config.supported_interfaces);
> +		adapter->phylink_config.lpi_capabilities = 0;

So EEE is not supporting with RMII? This is not mentioned in the
commit message.

Humm, is this an 802.3 limitation, or a limitation of this hardware?
If this is 802.3, then this should be in phylink, not drivers.

	Andrew

Re: [PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Nicolai Buchwitz]

Hi Andrew

On 26.5.2026 18:49, Andrew Lunn wrote:
> On Tue, May 26, 2026 at 09:10:54PM +0530, Thangaraj Samynathan wrote:
>> Enable RMII interface in the lan743x driver for PHY and MAC
>> configuration.
>> 
>> - Select RMII interface in lan743x_phy_interface_select().
>> - Update phylink supported_interfaces and MAC capabilities.
>> - Enable RMII via RMII_CTL in lan743x_hardware_init().
>> - Define RMII_CTL register and enable bit in lan743x_main.h.
> 
>> +	case PHY_INTERFACE_MODE_RMII:
>> +		__set_bit(PHY_INTERFACE_MODE_RMII,
>> +			  adapter->phylink_config.supported_interfaces);
>> +		adapter->phylink_config.lpi_capabilities = 0;
> 
> So EEE is not supporting with RMII? This is not mentioned in the
> commit message.
> 
> Humm, is this an 802.3 limitation, or a limitation of this hardware?

I do not think this is specific to the lan743x. Linux drives EEE from
the MAC side, so mac_enable_tx_lpi() has to signal "assert LPI" to the
PHY across the xMII. On MII and GMII the MAC signals LPI using TX_ER,
and AFAICT RMII has a reduced pin set with no TX_ER, so the MAC has no
standard way to request LPI over RMII. So IMHO EEE does not really
apply to RMII in general, not only on this controller. Please correct
me if I am missing something here.

Today drivers seem to express this themselves through lpi_interfaces.
stmmac is the clearest example I found, in stmmac_phy_setup():

	/* The GMAC 3.74a databook states that EEE is only supported
	 * in MII, GMII, and RGMII interfaces.
	 */
	__set_bit(PHY_INTERFACE_MODE_MII, config->lpi_interfaces);
	__set_bit(PHY_INTERFACE_MODE_GMII, config->lpi_interfaces);
	phy_interface_set_rgmii(config->lpi_interfaces);

It deliberately leaves RMII out, and phylink_activate_lpi() then
refuses LPI when cur_interface is not in lpi_interfaces.

> If this is 802.3, then this should be in phylink, not drivers.

Since this seems generic, I agree it belongs in phylink rather than
each driver. I can send a patch excluding RMII (and probably REVRMII)
from EEE centrally, so drivers do not need to special-case it.

> 
> 	Andrew

Nicolai

RE: [PATCH net-next v2 1/2] net: lan743x: add RMII strap status detection for PCI11x1x

[Thangaraj.S]

Hi Andrew,
Thanks for the comments.

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, May 26, 2026 10:10 PM
> To: Thangaraj Samynathan - I53494 <Thangaraj.S@microchip.com>
> Cc: netdev@vger.kernel.org; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; Bryan Whitehead - C21958
> <Bryan.Whitehead@microchip.com>; UNGLinuxDriver
> <UNGLinuxDriver@microchip.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next v2 1/2] net: lan743x: add RMII strap status
> detection for PCI11x1x
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the content is safe
> 
> > +     if (!adapter->is_sgmii_en && strap & STRAP_READ_USE_RMII_EN_) {
> > +             if (strap & STRAP_READ_RMII_EN_)
> > +                     adapter->is_rmii_en = true;
> > +     }
> 
> What does it mean when both SGMII and RMII is strapped? What if neither
> is strapped?
[Thangaraj Samynathan] When both are enabled, Interface will SGMII. When
Both are disabled interface will be RGMII.
> 
> > +
> >       netif_dbg(adapter, drv, adapter->netdev,
> >                 "SGMII I/F %sable\n", adapter->is_sgmii_en ? "En" :
> > "Dis");
> 
> Since there is a netif_dbg() for sgmii, maybe add one for rmii, so the code is
> somewhat symmetrical?
[Thangaraj Samynathan] Sure. Will add it in the next revision. 
> 
> >       struct lan743x_rx       rx[LAN743X_USED_RX_CHANNELS];
> >       bool                    is_pci11x1x;
> >       bool                    is_sgmii_en;
> > +     bool                    is_rmii_en;
> 
> Are there other strapping bits? Are we going to get is_gmii_en, and
> is_rgmii_en?
> 
> Does a collection of bools make sense, when the interface modes are
> typically mutually exclusive at the hardware level? Would an enum be
> better? Or why not phy_interface_t ?
[Thangaraj Samynathan] No, we have only three strap bits for SGMII and RMII interfaces. 
> 
>         Andrew

RE: [PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Thangaraj.S]

Hi Andrew,
Thanks for the comments.

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, May 26, 2026 10:20 PM
> To: Thangaraj Samynathan - I53494 <Thangaraj.S@microchip.com>
> Cc: netdev@vger.kernel.org; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; Bryan Whitehead - C21958
> <Bryan.Whitehead@microchip.com>; UNGLinuxDriver
> <UNGLinuxDriver@microchip.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next v2 2/2] net: lan743x: add support for RMII
> interface
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the content is safe
> 
> On Tue, May 26, 2026 at 09:10:54PM +0530, Thangaraj Samynathan wrote:
> > Enable RMII interface in the lan743x driver for PHY and MAC
> > configuration.
> >
> > - Select RMII interface in lan743x_phy_interface_select().
> > - Update phylink supported_interfaces and MAC capabilities.
> > - Enable RMII via RMII_CTL in lan743x_hardware_init().
> > - Define RMII_CTL register and enable bit in lan743x_main.h.
> 
> > +     case PHY_INTERFACE_MODE_RMII:
> > +             __set_bit(PHY_INTERFACE_MODE_RMII,
> > +                       adapter->phylink_config.supported_interfaces);
> > +             adapter->phylink_config.lpi_capabilities = 0;
> 
> So EEE is not supporting with RMII? This is not mentioned in the commit
> message.
> 
> Humm, is this an 802.3 limitation, or a limitation of this hardware?
> If this is 802.3, then this should be in phylink, not drivers.
> 
[Thangaraj Samynathan] No. This is the limitation of hardware. Will update
The commit message in next revision. 
>         Andrew

Re: [PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Nicolai Buchwitz]

Hi Andrew

On 26.5.2026 21:59, Nicolai Buchwitz wrote:
> [...]
>> 
>> Humm, is this an 802.3 limitation, or a limitation of this hardware?
> 
> I do not think this is specific to the lan743x. Linux drives EEE from
> the MAC side, so mac_enable_tx_lpi() has to signal "assert LPI" to the
> PHY across the xMII. On MII and GMII the MAC signals LPI using TX_ER,
> and AFAICT RMII has a reduced pin set with no TX_ER, so the MAC has no
> standard way to request LPI over RMII. So IMHO EEE does not really
> apply to RMII in general, not only on this controller. Please correct
> me if I am missing something here.

> [...]

>> If this is 802.3, then this should be in phylink, not drivers.
> 
> Since this seems generic, I agree it belongs in phylink rather than
> each driver. I can send a patch excluding RMII (and probably REVRMII)
> from EEE centrally, so drivers do not need to special-case it.

I looked into this some more and I don't think it belongs in phylink
after all.

The "no TX_ER, no in-band LPI" bit is generic and holds for any
MAC-driven EEE over RMII (IEEE 802.3 22.2.2 / Table 22-1: LPI is
asserted via TX_ER, which RMII doesn't have). But EEE still works over
RMII when the PHY or switch does LPI autonomously (PHY-managed EEE...
yikes), since that needs no in-band signaling.

ksz_common is exactly that: it puts RMII in lpi_interfaces on purpose
and uses a dummy mac_enable_tx_lpi() (the comment there explains the HW
handles LPI itself once EEE is negotiated):

	 /* ksz_phylink_mac_enable_tx_lpi() - Callback to signal LPI support 
(Dummy)
	 * [...]
	 * the actual EEE / Low Power Idle (LPI) state transitions are managed
	 * autonomously by the hardware based on the auto-negotiation results.
	 * [...]
	 * Therefore, this callback performs no action and serves primarily to
	 * inform phylink of LPI awareness [...]
	 */
	int ksz_phylink_mac_enable_tx_lpi(struct phylink_config *config,
					  u32 timer, bool tx_clock_stop)
	{
		return 0;
	}

So clearing RMII in phylink would break EEE there.

lpi_interfaces is opt-in already, RMII is only affected when a driver
memcpy()s supported_interfaces into it. So it seems that this is really
per-driver, and keeping the exclusion in lan743x looks right to me.
Unless we want to continue handling EEE differently depending on if MAC
or PHY-managed EEE ...

> [...]

Nicolai

Re: [PATCH net-next v2 1/2] net: lan743x: add RMII strap status detection for PCI11x1x

[Andrew Lunn]

> > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > the content is safe
> > 
> > > +     if (!adapter->is_sgmii_en && strap & STRAP_READ_USE_RMII_EN_) {
> > > +             if (strap & STRAP_READ_RMII_EN_)
> > > +                     adapter->is_rmii_en = true;
> > > +     }
> > 
> > What does it mean when both SGMII and RMII is strapped? What if neither
> > is strapped?
> [Thangaraj Samynathan] When both are enabled, Interface will SGMII. When
> Both are disabled interface will be RGMII.

So both enabled is not an error, we don't need to give a warning that
the board design is broken?

> > >       netif_dbg(adapter, drv, adapter->netdev,
> > >                 "SGMII I/F %sable\n", adapter->is_sgmii_en ? "En" :
> > > "Dis");
> > 
> > Since there is a netif_dbg() for sgmii, maybe add one for rmii, so the code is
> > somewhat symmetrical?
> [Thangaraj Samynathan] Sure. Will add it in the next revision. 

and maybe also add RGMII. Looking at this code, it is not obvious that
RGMII can be indicated by strapping.

	Andrew

Re: [PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Andrew Lunn]

> I looked into this some more and I don't think it belongs in phylink
> after all.
> 
> The "no TX_ER, no in-band LPI" bit is generic and holds for any
> MAC-driven EEE over RMII (IEEE 802.3 22.2.2 / Table 22-1: LPI is
> asserted via TX_ER, which RMII doesn't have). But EEE still works over
> RMII when the PHY or switch does LPI autonomously (PHY-managed EEE...
> yikes), since that needs no in-band signaling.

But that is a different thing. The API here is the MAC enumerating to
phylink what it is capable of. We don't have PHY-managed EEE yet in
phylink, but the basic idea would be the PHY would also enumerate its
capabilities, and then phylink would pick which to us.

> ksz_common is exactly that: it puts RMII in lpi_interfaces on purpose
> and uses a dummy mac_enable_tx_lpi() (the comment there explains the HW
> handles LPI itself once EEE is negotiated):
> 
> 	 /* ksz_phylink_mac_enable_tx_lpi() - Callback to signal LPI support
> (Dummy)
> 	 * [...]
> 	 * the actual EEE / Low Power Idle (LPI) state transitions are managed
> 	 * autonomously by the hardware based on the auto-negotiation results.
> 	 * [...]
> 	 * Therefore, this callback performs no action and serves primarily to
> 	 * inform phylink of LPI awareness [...]
> 	 */
> 	int ksz_phylink_mac_enable_tx_lpi(struct phylink_config *config,
> 					  u32 timer, bool tx_clock_stop)
> 	{
> 		return 0;
> 	}

and this is a 3rd variant, were you have an MAC/PHY pair which is
tightly integrated. I doubt that RMII is actually being used, and the
phy_interface_t should actually by "internal".

> So clearing RMII in phylink would break EEE there.

Agreed. So maybe it is too late to do this in the core, at least not
without having to change some drivers.

	Andrew

Re: [PATCH net-next v2 2/2] net: lan743x: add support for RMII interface

[Nicolai Buchwitz]

On 27.5.2026 14:20, Andrew Lunn wrote:
> [...]

>> ksz_common is exactly that: it puts RMII in lpi_interfaces on purpose
>> and uses a dummy mac_enable_tx_lpi() (the comment there explains the 
>> HW
>> handles LPI itself once EEE is negotiated):

> [...]

> 
> and this is a 3rd variant, were you have an MAC/PHY pair which is
> tightly integrated. I doubt that RMII is actually being used, and the
> phy_interface_t should actually by "internal".

So, if we treat this as a special case, patch it and track LPI
internally ...

> 
>> So clearing RMII in phylink would break EEE there.
> 
> Agreed. So maybe it is too late to do this in the core, at least not
> without having to change some drivers.

... we could clear the bits in phylink when RMII is used? Arguably this
patch is the first occurrence of such a construct, but who knows what
the future will bring... Better be explicit in the framework than
rework it later?

> 	Andrew

Nicolai