Re: [PATCH v2 0/3] fix macb phy probe failure if phy-reset is not handled

[Palmer Dabbelt]

On Thu, 04 Feb 2021 02:16:54 PST (-0800), schwab@xxxxxxxxxxxxxx wrote:
> On Jan 13 2021, Palmer Dabbelt wrote:
>
> > On Tue, 10 Nov 2020 07:22:09 PST (-0800), sagar.kadam@xxxxxxxxxx wrote:
> > > HiFive Unleashed is having VSC8541-01 ethernet phy device and requires a
> > > specific reset sequence of 0-1-0-1 in order to use it in unmanaged mode.
> > > This series addresses a corner case where phy reset is not handled by boot
> > > stages prior to linux.
> > > Somewhat similar unreliable phy probe failure was reported and discussed
> > > here [1].
> > > The macb driver fails to detect the ethernet phy device if the bootloader
> > > doesn't provide a proper reset sequence to the phy device or the phy itself
> > > is in some invalid state. Currently, the FSBL or u-boot-spl is resetting
> > > the phy device, and so there is no issue observed in the linux network
> > > setup.
> > >
> > > The series is based on linux-5.10-rc5.
> > > Patch 1: Add the OUI to the phy dt node to fix issue of missing mdio device
> > > Patch 2 and 3:
> > > 	Resetting phy needs GPIO support so add to dt and defconfig.
> > >
> > > [1] https://lkml.org/lkml/2018/11/29/154
> > >
> > > To reproduce the issue:
> > > Using FSBL:
> > > 1. Comment out VSC8541 reset sequence in fsbl/main.c
> > >    from within the freedom-u540-c000-bootloader.
> > > 2. Build and flash fsbl.bin to micro sdcard.
> > >
> > > Using u-boot:
> > > 1. Comment out VSC8541 reset sequence in board/sifive/fu540/spl.c
> > >    from mainline u-boot source code.
> > > 2. Build and flash u-boot binaries to micro sdcard.
> > >
> > > Boot the board and bootlog will show network setup failure messages as:
> > >
> > > [  1.069474] libphy: MACB_mii_bus: probed
> > > [  1.073092] mdio_bus 10090000.ethernet-ffffffff: MDIO device at address 0
> > > 	       is missing
> > > .....
> > > [  1.979252] macb 10090000.ethernet eth0: Could not attach PHY (-19)
> > >
> > > 3. Now apply the series build, and boot kernel.
> > > 4. MACB and VSC8541 driver get successfully probed and the network is set
> > >    without any failure.
> > >
> > >
> > > So irrespective of whether the prior stages handle the phy reset sequence,
> > > the probing is successful in both the cases of cold boot and warm boot.
> > >
> > > Change History:
> > > ===============================
> > > V2:
> > > -Rebased v1 on linux kernel v5.10-rc3.
> > >
> > > V1:
> > > -Ignore 4th patch as suggested and so removed it from the series.
> > > -Verified this series on 5.7-rc5.
> > >
> > > V0: Base RFC patch. Verified on 5.7-rc2
> > >
> > > Sagar Shrikant Kadam (3):
> > >   dts: phy: fix missing mdio device and probe failure of vsc8541-01
> > >     device
> > >   dts: phy: add GPIO number and active state used for phy reset
> > >   riscv: defconfig: enable gpio support for HiFive Unleashed
> > >
> > >  arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 2 ++
> > >  arch/riscv/configs/defconfig                        | 2 ++
> > >  2 files changed, 4 insertions(+)
> >
> > David pointed out I missed these, they're on fixes.  Thanks!
>
> This is now on 5.10.12, and breaks ethernet on the Hifive Unleashed:
>
> [   12.777976] macb 10090000.ethernet: Registered clk switch 'sifive-gemgxl-mgmt'
> [   12.784559] macb 10090000.ethernet: GEM doesn't support hardware ptp.
> [   12.791629] libphy: MACB_mii_bus: probed
> [   12.919728] MACsec IEEE 802.1AE
> [   12.984676] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 16 (70:b3:d5:92:f1:07)
> [   14.030319] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: phy_poll_reset failed: -110
> [   14.038986] macb 10090000.ethernet eth0: Could not attach PHY (-110)

Sorry about that.  Looks like we forgot to add the special reset sequence to
the VSC8541, which the driver doesn't yet support (there's a thread about it,
but I guess I forgot to clean up the patch).  IIUC this should manifest on
master as well, so my guess is that nobody is testing the HiFive Unleashed any
more (probably a bad sign).

I'll send out a revert.  I looked at the GPIO driver and can't tell if it's
twiddling GPIO lines when probed, in which case just enabling the GPIO would
break the ethernet.  Hopefully we're OK with the GPIO driver enabled.

Thanks for testing this.