[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/OB9oeEn98y0u4o@shell.armlinux.org.uk>
Date: Mon, 20 Feb 2023 14:21:42 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 3/4] net: phy: do not force EEE support
On Mon, Feb 20, 2023 at 02:56:04PM +0100, Oleksij Rempel wrote:
> if (data->eee_enabled) {
> + phydev->eee_enabled = true;
> if (data->advertised)
> - adv[0] = data->advertised;
> - else
> - linkmode_copy(adv, phydev->supported_eee);
> + phydev->advertising_eee[0] = data->advertised;
There is a behavioural change here that isn't mentioned in the patch
description - if data->advertised was zero, you were setting the
link modes to the full EEE supported set. After this patch, you
appear to leave advertising_eee untouched (so whatever it was.)
Which is the correct behaviour for this interface?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists