Re: [PATCH 3/5] net: cadence: macb: implement EEE TX LPI support

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

On 25.2.2026 18:32, Sai Krishna Gajula wrote:
>> -----Original Message-----
>> From: Nicolai Buchwitz <nb@tipi-net.de>
>> Sent: Wednesday, February 25, 2026 2:46 PM
>> To: netdev@vger.kernel.org
>> Cc: andrew+netdev@lunn.ch; claudiu.beznea@tuxon.dev;
>> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
>> nicolas.ferre@microchip.com; pabeni@redhat.com; linux@armlinux.org.uk;
>> phil@raspberrypi.com; Nicolai Buchwitz <nb@tipi-net.de>
>> Subject: [PATCH 3/5] net: cadence: macb: implement EEE TX LPI
>> support
>> 

[...]

>> +
>> +static void macb_tx_lpi_schedule(struct macb *bp) {
>> +	if (bp->eee_active)
>> +		mod_delayed_work(system_wq, &bp->tx_lpi_work,
>> +				 usecs_to_jiffies(bp->tx_lpi_timer));
>> +}
>> +
>> +/* Wake from LPI before transmitting. The MAC must deassert TXLPIEN
>> + * and wait for the PHY to exit LPI before any frame can be sent.
>> + * IEEE 802.3az Tw_sys is ~17us for 1000BASE-T, ~30us for 100BASE-TX;
>> + * we use a conservative 50us.
>> + */
>> +static void macb_tx_lpi_wake(struct macb *bp) {
>> +	if (!macb_tx_lpi_set(bp, false))
>> +		return;
>> +
>> +	cancel_delayed_work(&bp->tx_lpi_work);
>> +	udelay(50);
> Any reason the 50µs busy-wait in xmit path? Can it be avoided?
> 

The 50us delay is required by IEEE 802.3az. After clearing TXLPIEN the
PHY needs time to exit LPI and re-establish normal operation before the
MAC can transmit. This is defined as Tw_sys_tx - approximately 16.5us
for 1000BASE-T and 30us for 100BASE-TX. We use a conservative 50us to
cover both speeds without needing to track the current link rate.

Testing without the delay confirmed packet loss on the first frame after
waking from LPI, as the PHY had not yet fully transitioned back to
normal mode.

This delay is specific to the GEM MAC because TXLPIEN directly and
immediately controls LPI with no hardware enforcement of Tw_sys_tx - the
software must enforce it. Other phylink-managed EEE drivers (mvneta,
stmmac, lan743x, mtk) don't need an explicit delay because their
hardware handles the wake timing automatically.

The cost is also bounded: the delay only fires when TXLPIEN was
actually asserted, i.e. on the first transmit after an idle period.

[...]

Nicolai