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