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: <Zicyc0pj3g7/MemK@euler>
Date: Mon, 22 Apr 2024 23:00:51 -0500
From: Colin Foster <colin.foster@...advantage.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Andrew Halaney <ahalaney@...hat.com>
Subject: Re: Beaglebone Ethernet Probe Failure In 6.8+

Hi Andrew L,

(I CC'd Andrew Hanley, original author, for visibility)

On Wed, Apr 17, 2024 at 09:30:58PM +0200, Andrew Lunn wrote:
> 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

Yes, I can confirm this is the EIO.

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

The register value is 0x0020ffff

The datasheet is https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf and if
you search for 14-260 you'll find the bit definition table, but there
isn't much there for that bit...

The patch I threw in:

--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -437,7 +437,10 @@ static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
                        break;

                reg = readl(&data->regs->user[0].access);
+               printk("davinci mdio reg is 0x%08x\n", reg);
                ret = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -EIO;
+               if (ret == -EIO)
+                   printk("ret is this EIO\n");
                break;
        }


The print:

[    1.537767] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    1.538111] davinci mdio reg is 0x20400007
[    1.538372] davinci mdio reg is 0x2060c0f1
[    1.549523] davinci mdio reg is 0x03a0ffff
[    1.549551] ret is this EIO
[    1.549806] davinci mdio reg is 0x0020ffff
[    1.549821] ret is this EIO
[    1.550471] SMSC LAN8710/LAN8720: probe of 4a101000.mdio:00 failed with error -5
[    1.550592] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720

Without the mdiodev->reset_state patch, I see the following:

[    1.537817] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    1.538165] davinci mdio reg is 0x20400007
[    1.538426] davinci mdio reg is 0x2060c0f1
[    1.558442] davinci mdio reg is 0x23a00090
[    1.558717] davinci mdio reg is 0x20207809
[    1.559681] davinci mdio reg is 0x21c0ffff
[    1.559996] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720


For sanity, I went back and confirmed it still fails in 6.9-rc5.

Since I'm just using a Beaglebone, I was hoping to find an online CI
test report similar to this:
https://qa-reports.linaro.org/lkft/linux-next-master/
just to confirm that I'm not the only one seeing this. My search was
unsuccessful so far.

I think I'm getting a better understanding of the problem... maybe what
is going on is obvious to someone else's eyes at this point. I'll have
to call it a day for now.

Colin Foster