netdev - Re: [PATCH] net: phy: micrel: ksz9031: reconfigure autoneg after phy autoneg workaround

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2955148a-71bb-6923-4c90-d05146e063de@ti.com>
Date:   Thu, 21 Dec 2017 14:18:09 -0600
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Florian Fainelli <f.fainelli@...il.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Sekhar Nori <nsekhar@...com>
Subject: Re: [PATCH] net: phy: micrel: ksz9031: reconfigure autoneg after phy
 autoneg workaround



On 12/21/2017 03:21 AM, Andrew Lunn wrote:
> On Wed, Dec 20, 2017 at 06:45:10PM -0600, Grygorii Strashko wrote:
>> Under some circumstances driver will perform PHY reset in
>> ksz9031_read_status() to fix autoneg failure case (idle error count =
>> 0xFF). When this happens ksz9031 will not detect link status change any
>> more when connecting to Netgear 1G switch (link can be recovered sometimes by
>> restarting netdevice "ifconfig down up"). Reproduced with TI am572x board
>> equipped with ksz9031 PHY while connecting to Netgear 1G switch.
>>
>> Fix the issue by reconfiguring autonegotiation after PHY reset in
>> ksz9031_read_status().
> 
> Hi Grygorii
> 
> I can understand the fix.
> 
> But i'm wondering if there is a better way to do this. Can you call
> phy_stop() and phy_start(). You then get the core phy code doing the
> same initialisation as what happened the first time. However, i know
> this is not easy. _read_status() is being called from the middle of
> the state machine, and trying to change the state of the state machine
> at this point is problematic.

It will not work. 
phy_state_machine()->mutex_lock(&phydev->lock);->phy_read_status()->phy_stop()->mutex_lock(&phydev->lock);
at least as is.

This is error recovery, which is, per my understanding, signalizing about hw or
configuration issue. What i'm thinking about is - may be it'll be reasonable
to add err message here:
         if ((regval & 0xFF) == 0xFF) {
+               dev_err_once(&phydev->mdio.dev,
+                            "PHY reset due idle error count maxed out");


-- 
regards,
-grygorii