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: <464871d9-777c-9edd-40a1-2653aea1e0e3@gmail.com>
Date:   Wed, 20 Feb 2019 19:37:14 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Michal Vokáč <michal.vokac@...ft.com>,
        Andrew Lunn <andrew@...n.ch>, Vinod Koul <vkoul@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: [RFC] net: dsa: qca8k: CPU port broken with commit 5502b218e001
 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")

On 20.02.2019 16:02, Michal Vokáč wrote:
> Hi,
> 
> Another issue in a row with networking on imx6dl-yapp4 platform [1]
> that uses QCA8334 Ethernet switch.
> 
> Very recently, with Vinod and Andrew, we solved an issue with
> RGMII_ID mode by patch[2][3]. I tested those with next-20190215
> and it worked just fine.
> 
> The patch[2] was merged into next-20190220 so I tested the latest version.
> Now the cpu port does not work again. I tracked it down to this commit
> 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") [4]
> 
> If I revert the offending commit, cpu port works fine. I suspect the
> problem is on the qca8k driver side but I am not really sure.
> AFAICT autonegotiation is not available on the QCA833x cpu port (MAC0).
> 
Patch[4] only affects a code path with AUTONEG_ENABLE == phydev->autoneg.
IMO this shouldn't be the case for the cpu port (like you state).
Seems like somewhere a phydev->autoneg = AUTONEG_DISABLE is missing.

Not clear to me is where the difference with this patch comes from.
It would be helpful to know (w/o patch[4]):
- which values the register reads in genphy_read_status() return
- which bits are set in phydev->advertising

> Any ideas what may be the root cause of the problem?
> 
> Thank you,
> Michal
> 
Heiner

> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=87489ec3a77f3e01bcf0d46e353ae7112ec8c4f0
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a968b5e9d5879f9535d6099505f9e14abcafb623
> [3] https://lore.kernel.org/patchwork/patch/1043817/
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5502b218e001
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ