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

[Nicolai Buchwitz <nb@tipi-net.de>]

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