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:   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


Powered by blists - more mailing lists