linux-kernel - Re: [PATCH net-next 1/4] net: dsa: move up phy enabling in core

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:   Fri, 22 Sep 2017 09:58:00 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...oirfairelinux.com,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 1/4] net: dsa: move up phy enabling in core

On 09/22/2017 09:32 AM, Andrew Lunn wrote:
> On Fri, Sep 22, 2017 at 12:17:50PM -0400, Vivien Didelot wrote:
>> bcm_sf2 is currently the only driver using the phy argument passed to
>> .port_enable. It resets the state machine if the phy has been hard
>> reset. This check is generic and can be moved to DSA core.
>>  
>>  	dsa_port_set_state_now(p->dp, stp_state);
>>  
>> -	if (p->phy)
>> -		phy_start(p->phy);
>> +	if (phy) {
>> +		/* If phy_stop() has been called before, phy will be in
>> +		 * halted state, and phy_start() will call resume.
>> +		 *
>> +		 * The resume path does not configure back autoneg
>> +		 * settings, and since the internal phy may have been
>> +		 * hard reset, we need to reset the state machine also.
>> +		 */
>> +		phy->state = PHY_READY;
>> +		phy_init_hw(phy);
>> +		phy_start(phy);
>> +	}
> 
> Hi Vivien
> 
> If this is generic, why is it needed at all here? Shouldn't this
> actually by in phylib?

This does not belong in the core logic within net/dsa/slave.c. The
reason why this is necessary here is because we are doing a HW-based
reset of the PHY, as the comment explains this is specific to how the HW
works. There may be a cleaner solution to this problem, but in any case,
I don't think other drivers should inherit that logic.
-- 
Florian