Netdev List
 help / color / mirror / Atom feed
From: Aleksei Sviridkin <f@lex.la>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Aleksei Sviridkin <f@lex.la>
Subject: Re: [PATCH net-next 3/3] net: dsa: connect a late-arriving PHY at ifup
Date: Mon, 24 Aug 2026 05:40:15 +0300	[thread overview]
Message-ID: <20260824024015.39701-1-f@lex.la> (raw)
In-Reply-To: <c712cd5d-d4bd-413f-82a8-6303ff3e6526@lunn.ch>

> Another option is move the firmware download into the bootloader.

I went and looked at what that would take, and it does not help here,
for a reason that also corrects something in my own commit message.

The firmware is not what makes this PHY late. air_en8811h is a module
in the rootfs, and on this board it probes at 6.25 s, while the port is
already dropped at 1.878 s. Moving the blobs earlier changes nothing
while the driver itself arrives that late.

Even with the firmware preloaded, en8811h_probe() calls
en8811h_load_firmware() unconditionally, and that starts with
request_firmware_direct(). Nothing reads the version register or the
ready bit first, so a preloaded PHY is reloaded, and a PHY with no
blobs available still fails probe. A bootloader preload would need a
kernel-side early-out to have any effect at all.

And it would be gone before then anyway: the failed bringup ends in
phy_detach(), which asserts the reset line, and this PHY has
reset-gpios. So whatever the bootloader put in the MD32 is wiped at
1.88 s.

U-Boot does already carry the whole loader, in v2026.07, which is what
we build. What it cannot do here is read the blobs out of a squashfs
inside UBI, and mtk_eth_probe() takes the switch branch and never
connects a PHY on this board, so it would be new code either way.

None of that argues against your main point. I am dropping this patch
and sending the phylink and phylib fixes on their own, since they stand
without it. If the phylink hotplug direction ends up wanting someone to
test it on hardware that reproduces this, I have the board.

  parent reply	other threads:[~2026-08-24  2:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-22 15:52 [PATCH net-next 0/3] net: survive a PHY whose driver arrives after the switch probes Aleksei Sviridkin
2026-08-22 15:52 ` [PATCH net-next 1/3] net: phylink: unwind the PHY binding when bringup fails late Aleksei Sviridkin
2026-08-22 17:30   ` Andrew Lunn
2026-08-22 15:52 ` [PATCH net-next 2/3] net: phy: restore the interrupt after a generic-driver bind cycle Aleksei Sviridkin
2026-08-22 19:28   ` Andrew Lunn
     [not found] ` <20260822155259.87146-4-f@lex.la>
2026-08-22 19:38   ` [PATCH net-next 3/3] net: dsa: connect a late-arriving PHY at ifup Andrew Lunn
2026-08-23  0:05     ` Aleksei Sviridkin
2026-08-23  1:24       ` Andrew Lunn
2026-08-23 12:37         ` Aleksei Sviridkin
2026-08-23 15:20           ` Andrew Lunn
2026-08-24  2:40         ` Aleksei Sviridkin [this message]
2026-08-24 16:25 ` [PATCH net-next 0/3] net: survive a PHY whose driver arrives after the switch probes Andrew Lunn
2026-08-25  8:25   ` Aleksei Sviridkin
2026-08-28 13:30     ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260824024015.39701-1-f@lex.la \
    --to=f@lex.la \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox