Received-SPF: pass (google.com: domain of linux-kernel+bounces-83573-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 27 Feb 2024 17:12:22 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	netdev@vger.kernel.org, Clark Wang <xiaoning.wang@nxp.com>,
	linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Shenwei Wang <shenwei.wang@nxp.com>, Wei Fang <wei.fang@nxp.com>,
	NXP Linux Team <linux-imx@nxp.com>, kernel@pengutronix.de,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH net-next v6 5/8] net: phy: Immediately call adjust_link
 if only tx_lpi_enabled changes
Message-ID: <8d48af5b-e92b-431c-9bc0-ce6ef0e0ab2e@lunn.ch>
References: <Zdh1nMWZDynP/AMc@shell.armlinux.org.uk>
 <84e1368d-ec6a-48af-945b-509528c45dff@lunn.ch>
 <Zdic+ua5LnWxjLPn@shell.armlinux.org.uk>
 <6af3406a-7968-41e5-bf6e-71d020d8b28a@broadcom.com>
 <Zdot-Mqw1z4ZEo8v@pengutronix.de>
 <c6b0716d-f093-4aba-8453-c89a562ab581@lunn.ch>
 <e679f467-d4cd-4a1e-9bfc-92e2c9bf35d4@broadcom.com>
 <ZdzQG6t2slqEyH0m@shell.armlinux.org.uk>
 <fe071598-64eb-4dd2-8926-d4d0954e7e7e@lunn.ch>
 <Zd10qUJzq-2nG7b7@pengutronix.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zd10qUJzq-2nG7b7@pengutronix.de>

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:
> > On Mon, Feb 26, 2024 at 05:53:31PM +0000, Russell King (Oracle) wrote:
> > > On Mon, Feb 26, 2024 at 09:50:02AM -0800, Florian Fainelli wrote:
> > > > 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