netdev - Re: [PATCH net-next 1/2] net: phy: check for aneg disabled and half duplex in phy_ethtool_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 May 2020 14:50:23 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] net: phy: check for aneg disabled and half
 duplex in phy_ethtool_set_eee

On 10.05.2020 16:05, Russell King - ARM Linux admin wrote:
> On Sun, May 10, 2020 at 10:11:33AM +0200, Heiner Kallweit wrote:
>> EEE requires aneg and full duplex, therefore return EPROTONOSUPPORT
>> if aneg is disabled or aneg resulted in a half duplex mode.
> 
> I think this is completely wrong.  This is the ethtool configuration
> interface for EEE that you're making fail.
> 
You mentioned in a parallel response that you are aware of at least
userspace tool / use case that would be broken by this change.
Can you please point me to this tool / use case?

> Why should you not be able to configure EEE parameters if the link
> happens to negotiated a half-duplex?  Why should you not be able to
> adjust the EEE advertisment via ethtool if the link has negotiated
> half-duplex?
> 
> Why should any of this configuration depend on the current state?
> 
If EEE settings change, then phy_ethtool_set_eee() eventually
calls genphy_restart_aneg() which sets bits BMCR_ANENABLE in the
chip. Means if we enter the function with phydev->autoneg being
cleared, then we'll end up with an inconsistent state
(phydev->autoneg not reflecting chip aneg setting).
As alternative to throwing an error we could skip triggering an
aneg, what would you prefer?

> Why should we force people to negotiate a FD link before they can
> then configure EEE, and then have to perform a renegotiation?
> 
If being in a HD mode and setting EEE returns with a success return
code, then users may expect EEE to be active (what it is not).

> Sorry, but to me this patch seems to be a completely wrong approach,
> and I really don't get what problem it is trying to fix.
> 
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>> ---
>>  drivers/net/phy/phy.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index 8c22d02b4..891bb6929 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -1110,6 +1110,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
>>  	if (!phydev->drv)
>>  		return -EIO;
>>  
>> +	if (phydev->autoneg == AUTONEG_DISABLE || phydev->duplex == DUPLEX_HALF)
>> +		return -EPROTONOSUPPORT;
>> +
>>  	/* Get Supported EEE */
>>  	cap = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
>>  	if (cap < 0)
>> -- 
>> 2.26.2
>>
>>
>>
>