netdev - Re: Beaglebone Ethernet Probe Failure In 6.8+

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: <53a70554-61e5-414a-96a0-e6edd3b6c077@lunn.ch>
Date: Wed, 17 Apr 2024 21:30:58 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Colin Foster <colin.foster@...advantage.com>
Cc: netdev@...r.kernel.org
Subject: Re: Beaglebone Ethernet Probe Failure In 6.8+

On Wed, Apr 17, 2024 at 10:42:02AM -0500, Colin Foster wrote:
> Hello,
> 
> I'm chasing down an issue in recent kernels. My setup is slightly
> unconventional: a BBB with ETH0 as a CPU port to a DSA switch that is
> controlled by SPI. I'll have hardware next week, but think it is worth
> getting a discussion going.
> 
> The commit in question is commit df16c1c51d81 ("net: phy: mdio_device:
> Reset device only when necessary"). This seems to cause a probe error of
> the MDIO device. A dump_stack was added where the reset is skipped.
> 
> SMSC LAN8710/LAN8720: probe of 4a101000.mdio:00 failed with error -5

Can you confirm this EIO is this one:

https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/ti/davinci_mdio.c#L440

It would be good to check the value of USERACCESS_ACK, and what the
datasheet says about it.

The MDIO bus itself has no real way of telling if there is a device on
the bus at a given address, and so if the devices actually transfers
anything on a read. So if the resets are wrong, the device is still in
reset, or coming out of reset but not yet ready, you should just read
0xffff. Returning EIO would indicate some other issue.

> Because this failure happens much earlier than DSA, I suspect is isn't
> isolated to me and my setup - but I'm not positive at the moment.
> 
> I suspect one of the following:
> 
> 1. There's an issue with my setup / configuration.
> 
> 2. This is an issue for every BBB device, but probe failures don't
> actually break functionality.
> 
> 
> Depending on which of those is the case, I'll either need to:
> 
> A. revert the patch because it is causing probe failures
> 
> B. determine why the probe is failing in the MDIO driver and try to fix
> that
> 
> C. Introduce an API to force resets, regardless of the previous state,
> and apply that to the failure cases.
> 
> 
> I assume the path forward is option B... but if the issue is more
> widespread, options A or C might be the correct path.

I would prefer B, at least lets try to understand the
problem. Depending on what we find, we might need A, but lets decided
that later.

> [    1.553623] SMSC LAN8710/LAN8720: probe of 4a101000.mdio:00 failed with error -5
> [    1.553762] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
> [    1.554978] cpsw-switch 4a100000.switch: initialized cpsw ale version 1.4
> [    1.555011] cpsw-switch 4a100000.switch: ALE Table size 1024
> [    1.555210] cpsw-switch 4a100000.switch: cpts: overflow check period 500 (jiffies)
> [    1.555234] cpsw-switch 4a100000.switch: CPTS: ref_clk_freq:250000000 calc_mult:2147483648 calc_shift:29 error:0 nsec/sec
> [    1.555343] cpsw-switch 4a100000.switch: Detected MACID = 24:76:25:76:35:37
> [    1.558098] cpsw-switch 4a100000.switch: initialized (regs 0x4a100000, pool size 256) hw_ver:0019010C 1.12 (0)

So despite the -EIO, it finds the PHY, and the switch seems to probe
O.K?

	Andrew