netdev - Re: [PATCH 2/2] at803x: double check SGMII side autoneg

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: <8cf4ca6d-3e1e-3c9c-605f-5d6baf3c7588@codeaurora.org>
Date:   Wed, 24 May 2017 08:48:04 -0500
From:   Timur Tabi <timur@...eaurora.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Matthias May <matthias.may@...atec.com>,
        Zefir Kurtisi <zefir.kurtisi@...atec.com>,
        netdev@...r.kernel.org, f.fainelli@...il.com,
        David Miller <davem@...emloft.net>,
        Manoj Iyer <manoj.iyer@...onical.com>, jhugo@...eaurora.org
Subject: Re: [PATCH 2/2] at803x: double check SGMII side autoneg

On 5/24/17 8:40 AM, Andrew Lunn wrote:

> You need to prove this, that the link is not up. Any by link, we mean
> both the copper and the SGMII link.

I can post the log of my iperf run showing that the, when 
at803x_aneg_done() returns zero, no packets can go through.  And then 
after I change at803x_aneg_done() so that it returns BMSR_ANEGCOMPLETE, 
then packets do go through.  Is that the proof you're looking for?

The current work-around that we're using internally is to blacklist the 
at803x driver.  This forces the kernel to use the genphy driver instead. 
  Everything works when we do this.

>> at803x_aneg_done() is never called again, and so I think
>> the kernel is disabling the interface is some secret way.
> 
> Well, the driver has told the core that the link is not up. So the
> kernel is waiting for another interrupt indicating the link has gone
> up. And probably, this second interrupt never happens.

Exxactly.  That's because the link IS up, and so there is no opportunity 
to receive another interrupt.

> And it is not disabling the interface. Since the PHY is still down,
> the core has not called netif_carrier_on().

Ok, I should have said "not enabled" instead of "disabled".  Thanks.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.