Re: [PATCH net-next v1 2/2] net: dsa: realtek: rtl8365mb: add EEE support

[Oleksij Rempel]

On Mon, Aug 17, 2026 at 04:53:52PM +0200, Andrew Lunn wrote:
> > +static int rtl8365mb_phylink_mac_enable_tx_lpi(struct phylink_config *config,
> > +					       u32 timer, bool tx_clock_stop)
> > +{
> > +	/* The hardware manages LPI itself; there is no MAC-level LPI control.
> > +	 * This callback only signals LPI awareness to phylink.
> > +	 */
> > +	return 0;
> > +}
> > +
> > +static void rtl8365mb_phylink_mac_disable_tx_lpi(struct phylink_config *config)
> > +{
> > +}
> > +
> 
> So what happens when i do:
> 
> ethtool --set-eee eth42 off
> 
> or
> 
> ethtool --set-eee eth42 tx-lpi on

In current implementation, with "tx-lpi off", the driver will return
-EINVAL, "tx-lpi on" will be passed. It is aligned with KSZ driver.
rtl8365mb_set_mac_eee() is used as filter.

> I don't now what phylib does with advertise in these cases, but maybe
> you need to go behind phylink/phylib back and set advertise to 0, so
> that the MAC does the right thing?

If I see it correctly, We wont be able to emulate "eee on tx-lpi off"
case on this HW. On proper HW, this configuration will be link speed
dependent:

- 100 Mbit/s - TX line will be active, RX can be idle if link partner is
  in LPI.

- 1000 Mbit/s - this configuration will make EEE/LPI non functional, almost
  equal to "eee off" (EEE is advertised but not activated)

I decided not to emulate "tx-lpi off" by disabling EEE advertisement.

> Or you need to return -EOPNOTSUPP for these?

Currently it is -EINVAL as in KSZ driver. If we will go with -EOPNOTSUPP
then probably both drivers should follow it.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |