On Tue, Feb 27, 2024 at 06:35:38AM +0100, Oleksij Rempel wrote:

On Mon, Feb 26, 2024 at 07:59:28PM +0100, Andrew Lunn wrote:

quoted

On Mon, Feb 26, 2024 at 05:53:31PM +0000, Russell King (Oracle) wrote:

quoted

On Mon, Feb 26, 2024 at 09:50:02AM -0800, Florian Fainelli wrote:

quoted

This is the source of the concern, we don't know which MAC drivers we might
end-up breaking by calling adjust_link(link == 1) twice in a row, hopefully
none, because they should be well written to only update the parameters that
need updating, but who knows?

Just quickly... There are some (I went through a bunch.) They don't
support EEE. I haven't been through all though, so there could be
some which support EEE and where adjust_link() with phydev->link=true
twice in a row could result in badness.

So i think we all agree the MAC needs to see a down/up, even if the
link itself never went down. Anything else is too risky and will
probably break something somewhere.

Means, this patch should be dropped.

No.

This patch handles the case that EEE is changed, but does not require
an auto-neg cycle. If you drop this patch, that use case breaks.

You need to extend this patch to signal to the MAC a down followed by
an up. It is a fake down, the media side never goes down, but the MAC
needs to think it has in order to keep with the usual convention that
we never call adjust_link() twice with phydev->link not changing.

   Andrew