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
| ||
|
Message-ID: <6cf7a03e-dba4-1830-68a3-7232de969d38@ysoft.com> Date: Thu, 28 Feb 2019 17:32:03 +0100 From: Michal Vokáč <michal.vokac@...ft.com> To: Heiner Kallweit <hkallweit1@...il.com> Cc: "David S. Miller" <davem@...emloft.net>, Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org, Christian Lamparter <chunkeey@...il.com>, Andrew Lunn <andrew@...n.ch>, Vinod Koul <vkoul@...nel.org> Subject: Re: [RFC] net: dsa: qca8k: CPU port broken with commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status") Added Christian to the CC list. I see you also work with the QCA833x switch. Your comments are welcome! On 20. 02. 19 19:37, Heiner Kallweit wrote: > 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 Hello Heiner, just for the record, this is what I noted when debugging the issue and planned to send before the weekend.. next-20190228 does not work because of different issue. I will create another thread for that. next-20190222 works fine even without 0f3b1cf23f0e ("net: phy: fix reading fixed phy status")! next-20190220 does not work. It seems there is some problem with fixed-link handling and/or with how the switch indicates its autonegotiation capability. To make the CPU port work with next-20190220, I can either do: - force genphy_read_status() to go the AUTONEG_ENABLE != phydev->autoneg path, or - prevent the qca8k_adjust_link() from writing into the switch registers. More details below. 1) Linux version next-20190220, with patch[4] - genphy_config_init() reads CPU port MII_BMSR register, value: 0x12c - The bit BMSR_ANEGCAPABLE is set (!?) and so the genphy_read_status() takes the AUTONEG_ENABLE == phydev->autoneg path. - genphy_read_status() returns with phydev->advertising = 0x0 - qca8k_adjust_link() function is called. - I can bring up the cpu port but it DOES NOT work. - genphy_read_status() returns with phydev->advertising = 0x22e0 (bit 13,9,7,6,5 set) - If I remove the qca8k_write() in qca8k_adjust_link(), or remove the qca8k_adjust_link() totaly, the CPU port DOES work. 2) Linux version next-20190220, without patch[4] - genphy_config_init() reads CPU port MII_BMSR register, value: 0x12c - The bit BMSR_ANEGCAPABLE is set (!?) and so the genphy_read_status() takes the AUTONEG_ENABLE path. - genphy_read_status() returns with phydev->advertising = 0x0 - The qca8k_adjust_link() function is called. - I can bring up the cpu port and it DOES work. - genphy_read_status() returns with phydev->advertising = 0x22e0 (bit 13,9,7,6,5 set) Not sure if this will be helpful in any way as it is related to the now outdated versions next-20190220 and next-20190222. Best regards, Michal >> Any ideas what may be the root cause of the problem? >> >> Thank you, >> Michal >> >> [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