From: Daniel Golle <daniel@makrotopia.org>
To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Edward Cree <ecree.xilinx@gmail.com>,
Andrew Lunn <andrew@lunn.ch>, Paolo Abeni <pabeni@redhat.com>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>
Cc: John Crispin <john@phrozen.org>
Subject: ethtool settings and SFP modules with PHYs
Date: Mon, 16 Sep 2024 16:36:47 +0100 [thread overview]
Message-ID: <ZuhQjx2137ZC_DCz@makrotopia.org> (raw)
Hi,
I'm wondering how (or rahter: when?) one is supposed to apply ethtool
settings, such as modifying advertisement of speed, duplex, ..., with
SFP modules containing a PHY.
My first approach was to try catching the event of the PHY being
attached and then re-applying ethtool settings[1]. As there isn't a
dedicated event for that, I found that IFF_UP && !IFF_LOWER_UP is as
close as it gets.
However, that doesn't go well with some PHY drivers and the result seems
to depend on a race condition.
Simply ignoring the supported link modes and assuming the kernel would
filter them also doesn't work as also the advertised modes get reset
every time the SFP module is removed or inserted.
Do you think it would make sense to keep the user selection of
advertised modes for each networking device accross removal or insertion
of an SFP module?
The user selection would by default select all known link modes, using
ethtool (ioctl or nl) would modify it, while the actually advertised
modes would always be the intersection of user-selected modes and
supported modes.
Alternatively we could of course also introduce a dedicated NETLINK_ROUTE
event which fires exactly one time once a new is PHY attached.
If there is any way to automically apply user-configured ethtool
settings without any of the above, please be so kind and let me know how
that would work also for PHYs on SFP modules.
Thank you!
With Best Regards
Daniel
[1]: https://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=68c8a4f94cd3cfd654a52cbc8b57c5c9d99640dd
next reply other threads:[~2024-09-16 16:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 15:36 Daniel Golle [this message]
2024-09-16 16:02 ` ethtool settings and SFP modules with PHYs Maxime Chevallier
2024-09-16 16:12 ` Andrew Lunn
2024-09-16 16:29 ` Maxime Chevallier
2024-09-16 16:03 ` Andrew Lunn
2024-09-16 17:34 ` Russell King (Oracle)
2024-09-17 15:53 ` Maxime Chevallier
2024-09-17 16:38 ` Russell King (Oracle)
2024-09-17 17:16 ` Daniel Golle
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=ZuhQjx2137ZC_DCz@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=john@phrozen.org \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).