netdev - RE: [PATCH net] at803x: insure minimum delay for SGMII link AN completion ckeck

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: <AM5PR0401MB2561EFE479E6B2FCC508C9BD96580@AM5PR0401MB2561.eurprd04.prod.outlook.com>
Date:   Tue, 14 Feb 2017 14:31:53 +0000
From:   Claudiu Manoil <claudiu.manoil@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Zefir Kurtisi <zefir.kurtisi@...atec.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "Florian Fainelli" <f.fainelli@...il.com>
Subject: RE: [PATCH net] at803x: insure minimum delay for SGMII link AN
 completion ckeck

>-----Original Message-----
>From: Andrew Lunn [mailto:andrew@...n.ch]
>Sent: Monday, February 13, 2017 7:31 PM
>Subject: Re: [PATCH net] at803x: insure minimum delay for SGMII link AN
>completion ckeck
>

[...]

>>
>> I can confirm that link status changes are signaled via interrupts ("phy_interrupt")
>> in this case.
>
>Is there a way to enable an interrupt when SGMII signalled link
>changes has happened? Maybe another interrupt enable bit somewhere?
>That would avoid having to sleep().
>

No, except for the interrupt lines coming from the external AR8033 PHYs there's 
nothing else (documentation on the SoC and board is available on nxp.com).
I think this question hints to the actual problem, that the internal SGMII link 
should have a separate state (and state machine) apart from the external link's
state.  PHYLIB currently handles the state of the external link of a PHY, hence 
the aneg_done() hook should reflect the status of the external link. So, I think 
there'll always be issues if the external PHY device's aneg_done() returns the AN 
status of the internal SGMII link. Actually, the internal link is owned by an internal 
(SoC) PHY device, TBI in this case (or something similar for other SoCs I'd expect), 
so, by a different phy device.  Moreover, the auto-negotiation on the external link 
is different from the AN on the internal SGMII link (different IEEE clauses: clause 27 vs 
clause 37).
So, I think the way to go would be to drop the SGMII link state check from AR803x's
aneg_done() for now and try to address SGMII internal link potential issues at SoC/MAC 
level, on a case by case basis.

Claudiu