Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Wozniak <petr.wozniak@gmail.com>
To: maxime.chevallier@bootlin.com, netdev@vger.kernel.org
Cc: kuba@kernel.org, andrew@lunn.ch, hkallweit1@gmail.com,
	linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, linux-phy@lists.infradead.org,
	linux-kernel@vger.kernel.org, bjorn@mork.no, olek2@wp.pl,
	Petr Wozniak <petr.wozniak@gmail.com>
Subject: Re: [PATCH net-next] net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery
Date: Fri,  5 Jun 2026 07:34:05 +0200	[thread overview]
Message-ID: <20260605053405.2019-1-petr.wozniak@gmail.com> (raw)
In-Reply-To: <19e947e08e51987b@gmail.com>

Hi Maxime,

Thank you for the question — it revealed a gap in the commit message.

The regression turns out to affect both boot-inserted and hotplugged
genuine RollBall modules. Aleksander Bajkowski confirmed that his FLYPRO
SFP-10GT-CS-30M (with Aquantia AQR113C) is broken even when hotplugged —
the PHY is no longer detected after 8fe125892f40.

So the root cause is not boot vs. hotplug specifically: sfp_sm_add_mdio_bus()
in SFP_S_INIT gives the bridge only a 200 ms window, which is insufficient on
hardware where bridge initialization takes longer, regardless of insertion
timing.

Jan Hoffmann also correctly pointed out that the commit message was wrong
about the state: the probe runs in SFP_S_INIT (which follows SFP_S_WAIT),
not "before initialization delays."

v2 with both corrections is at:
https://lore.kernel.org/netdev/20260605053056.1977-1-petr.wozniak@gmail.com/

Thanks,
Petr

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

       reply	other threads:[~2026-06-05  5:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19e947e08e51987b@gmail.com>
2026-06-05  5:34 ` Petr Wozniak [this message]
2026-06-04 18:12 [PATCH net-next] net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery Petr Wozniak
2026-06-04 21:15 ` Maxime Chevallier

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=20260605053405.2019-1-petr.wozniak@gmail.com \
    --to=petr.wozniak@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=olek2@wp.pl \
    --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