[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250226172754.1c3b054b@kmaincent-XPS-13-7390>
Date: Wed, 26 Feb 2025 17:27:54 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Martin Schiller <ms@....tdt.de>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, andrew@...n.ch,
hkallweit1@...il.com, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: sfp: add quirk for FS SFP-10GM-T copper
SFP+ module
On Wed, 26 Feb 2025 16:55:38 +0100
Martin Schiller <ms@....tdt.de> wrote:
> On 2025-02-26 16:26, Kory Maincent wrote:
> > On Wed, 26 Feb 2025 15:50:46 +0100
> > Martin Schiller <ms@....tdt.de> wrote:
> >
> >> On 2025-02-26 15:38, Russell King (Oracle) wrote:
> [...]
> [...]
> [...]
> >>
> >> OK, I'll rename it to sfp_fixup_rollball_wait.
> >
> > I would prefer sfp_fixup_fs_rollball_wait to keep the name of the
> > manufacturer.
> > It can't be a generic fixup as other FSP could have other waiting time
> > values
> > like the Turris RTSFP-10G which needs 25s.
>
> I think you're getting two things mixed up.
> The phy still has 25 seconds to wake up. With sfp_fixup_rollball_wait
> there simply is an additional 4s wait at the beginning before we start
> searching for a phy.
Indeed you are right, I was looking in older Linux sources, sorry.
Still, the additional 4s wait seems relevant only for FS SFP, so it should
be included in the function naming to avoid confusion.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists