linux-kernel - Re: PROBLEM: Broken or delayed ethernet on Xilinx ZCU104 since 5.18 (regression)

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: <CADyTPEyqG7D-_iuo+5WFGhhidK7p_fmvDhbgz05xogSU042Uag@mail.gmail.com>
Date:   Sat, 5 Aug 2023 02:57:12 -0400
From:   Nick Bowler <nbowler@...conx.ca>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Rob Herring <robh@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        netdev@...r.kernel.org, regressions@...ts.linux.dev
Subject: Re: PROBLEM: Broken or delayed ethernet on Xilinx ZCU104 since 5.18 (regression)

On 2023-08-04, Russell King (Oracle) <linux@...linux.org.uk> wrote:
> I think we need to rewind a tad.
>
> My understanding is that this uses the Cadence macb driver.

Correct.

> In your original message, you said that the ethernet driver wasn't
> being bound to the driver.
[...]
> So, I think that the deferred probing has nothing to do with PHYs, and
> that's just a wild goose chase.
>
> I think instead we need to be concentrating on what's going on with
> the ethernet driver, and why the ethernet driver is deferring its
> probe. Is macb_probe() getting called at all?

I added some prints to the driver.  The macb_probe is called five times
on this one device initially at boot, then ten seconds later it is
called one last time, returning -EPROBE_DEFER each time.

> How far through macb_probe() do we get before we defer?

The result is the same for all six calls.  The macb_mdiobus_register
function returns -EPROBE_DEFER, which comes from the topmost call
to of_mdiobus_register within that function.  That is, this is the
part that returns -EPROBE_DEFER:

	child = of_get_child_by_name(np, "mdio");
	if (child) {
		int ret = of_mdiobus_register(bp->mii_bus, child);

		of_node_put(child);
		return ret;
	}

> I think those are the key questions that need answering.
>
> Maybe, if you can get access to the machine while the driver is
> deferring, /sys/kernel/debug/devices_deferred might give some
> useful information, but that's just a hope.

This just contains one line:

  ff0e0000.ethernet

which is the name of the ethernet device that is not working.

Thanks,
  Nick