netdev - Re: [PATCH 0/2] at803x: don't power-down SGMII link

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]

Message-ID: <2bf6fe19-5d18-ba96-5bf9-5030ace0ee89@neratec.com>
Date:   Thu, 27 Oct 2016 10:05:22 +0200
From:   Zefir Kurtisi <zefir.kurtisi@...atec.com>
To:     Timur Tabi <timur@...eaurora.org>, netdev@...r.kernel.org
Cc:     andrew@...n.ch, f.fainelli@...il.com
Subject: Re: [PATCH 0/2] at803x: don't power-down SGMII link

On 10/25/2016 07:31 PM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> In a device where the ar8031 operates in SGMII mode, we
>> observed that after a suspend-resume cycle in very rare
>> cases the copper side autonegotiation secceeds but the
>> SGMII side fails to come up.
>>
>> As a work-around, a patch was provided that on suspend and
>> resume powers the SGMII link down and up along with the
>> copper side. This fixed the observed failure, but
>> introduced a regression Timur Tabi observed: once the SGMII
>> is powered down, the PHY is inaccessible by the CPU and
>> with that e.g. can't be re-initialized after suspend.
>>
>> Since the original issue could not be reproduced by others,
>> this series provides an alternative handling:
>> * the first patch reverts the prvious fix that powers down
>>    SGMII
>> * the second patch adds double-checking for the observed
>>    failure condition
>>
>> Zefir Kurtisi (2):
>>    Revert "at803x: fix suspend/resume for SGMII link"
>>    at803x: double check SGMII side autoneg
> 
> Tested-by: Timur Tabi <timur@...eaurora.org>
> 
> With these patches, the problem I was seeing no longer occurs, and the new code
> does not appear to break anything.  As before, I still have never seen the
> original problem, but this patchset seems to work for both of us.
> 
Thanks for testing.

I could make the double checking configurable and disabled by default, but this
would render it useless to detect the potential issue in the field.