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-next>] [day] [month] [year] [list]
Message-ID: <9f4b057d-1985-5fd3-65c0-f944161c7792@microchip.com>
Date:   Tue, 5 Apr 2022 13:05:12 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <palmer@...osinc.com>, <apatel@...tanamicro.com>
CC:     <netdev@...r.kernel.org>, <Nicolas.Ferre@...rochip.com>,
        <Claudiu.Beznea@...rochip.com>, <linux@...linux.org.uk>,
        <andrew@...n.ch>, <hkallweit1@...il.com>,
        <linux-riscv@...ts.infradead.org>
Subject: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

Hey,
I seem to have come across a regression in the default riscv defconfig
between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
machine") which causes the ethernet phy to not come up on my Icicle kit:
[ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)

I did try to bisect normally, but unfortunately it was not trivial for
me to do, because the following two commits from Linus' tree that
arrived after riscv-for-linus-5.18-mw0 are required actually bring up
the icicle kit & its ethernet:
37f7860602b5 net: macb: Align the dma and coherent dma masks
635e5e73370e clk: microchip: Add driver for Microchip PolarFire SoC

I went down a rabbit hole of checking the net side of things & found
that the failing check is in the call to phylink_validate in
phylink_bringup_phy. Some digging points to v5.18-rc1's
drivers/net/phy/phylink.c:L457 as the culprit, with the
phylink_is_empty_linkmode check failing.

At riscv-for-linus-5.18-mw0, cherry-picking those two commits brings it
up fine:
[ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

At riscv-for-linus-5.18-mw1 (1464d00b27b2) with those two commits
applied, I get the same validation failure as with v5.18-rc1.

I did some manual reversions of everything in
drivers/net/ethernet/cadence/ & drivers/net/phy/phylink.c that was
added since 5.17 to no avail.
Turns out the problem was exposed by riscv-for-linus-5.18-mw1 and
reverting c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver
for QEMU virt machine") avoided the problem for me.

Is this some sort of lack of support for CONFIG_PM=y in my clock driver,
that's leading to the PHY getting stuck in reset?
Or an interaction between CONFIG_PM=y & the macb/generic phy drivers?

I am kinda lost at this point & would appreciate any help investigating
further. I have attached the full log in case that helps.
Thanks,
Conor.

View attachment "failure.log" of type "text/x-log" (10541 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ