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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 04 Jun 2017 19:34:06 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     timur@...eaurora.org
Cc:     linux-arm-kernel@...ts.infradead.org, f.fainelli@...il.com,
        manoj.iyer@...onical.com, netdev@...r.kernel.org,
        stable@...r.kernel.org, zefir.kurtisi@...atec.com, andrew@...n.ch,
        matthias.may@...atec.com
Subject: Re: [for 4.12] net: qcom/emac: do not use hardware mdio automatic
 polling

From: Timur Tabi <timur@...eaurora.org>
Date: Thu,  1 Jun 2017 16:08:13 -0500

> Use software polling (PHY_POLL) to check for link state changes instead
> of relying on the EMAC's hardware polling feature.  Some PHY drivers
> are unable to get a functioning link because the HW polling is not
> robust enough.
> 
> The EMAC is able to poll the PHY on the MDIO bus looking for link state
> changes (via the Link Status bit in the Status Register at address 0x1).
> When the link state changes, the EMAC triggers an interrupt and tells the
> driver what the new state is.  The feature eliminates the need for
> software to poll the MDIO bus.
> 
> Unfortunately, this feature is incompatible with phylib, because it
> ignores everything that the PHY core and PHY drivers are trying to do.
> In particular:
> 
> 1. It assumes a compatible register set, so PHYs with different registers
>    may not work.
> 
> 2. It doesn't allow for hardware errata that have work-arounds implemented
>    in the PHY driver.
> 
> 3. It doesn't support multiple register pages. If the PHY core switches
>    the register set to another page, the EMAC won't know the page has
>    changed and will still attempt to read the same PHY register.
> 
> 4. It only checks the copper side of the link, not the SGMII side.  Some
>    PHY drivers (e.g. at803x) may also check the SGMII side, and
>    report the link as not ready during autonegotiation if the SGMII link
>    is still down.  Phylib then waits for another interrupt to query
>    the PHY again, but the EMAC won't send another interrupt because it
>    thinks the link is up.
> 
> Cc: stable@...r.kernel.org # 4.11.x
> Tested-by: Manoj Iyer <manoj.iyer@...onical.com>
> Signed-off-by: Timur Tabi <timur@...eaurora.org>

Applied, thanks.

Powered by blists - more mailing lists