From: <markus.stockhausen@gmx.de>
To: "'Andrew Lunn'" <andrew@lunn.ch>
Cc: <linux@armlinux.org.uk>, <hkallweit1@gmail.com>,
<netdev@vger.kernel.org>,
"'Jonas Jelonek'" <jelonek.jonas@gmail.com>, <jan@3e8.eu>,
<nbd@nbd.name>, "'Daniel Golle'" <daniel@makrotopia.org>
Subject: AW: pre-boot plugged SFP autoneg advertisement
Date: Mon, 20 Apr 2026 21:10:32 +0200 [thread overview]
Message-ID: <007401dcd0f9$5cc990a0$165cb1e0$@gmx.de> (raw)
In-Reply-To: <664e6e24-4a94-43fa-8769-773a37a01c66@lunn.ch>
> Von: Andrew Lunn <andrew@lunn.ch>
> Gesendet: Montag, 20. April 2026 19:58
> An: markus.stockhausen@gmx.de
>
> > Sequence of events during boot is as follows:
> >
> > - SFP module is already inserted (in my case 1G)
> > - phylink_sfp_config_phy() runs long before any network config starts
> > - OpenWrt netifd daemon starts and wants to configure the network
interfaces
> > - It reads current settings via ethtool ioctl and gets autoneg=off
> > - It writes basic config values via ethtool ioctl including autneg=off
> > - Later on it starts the interface and phylink_start() is issued
>
> I would say netifd is not optimal. I'm not sure we every agree to
> return the full ksetting on an interface which is admin down. Many
> driver don't even connect to the PHY until open is called, and so are
> likely to return -ENODEV. See phy_ethtool_set_link_ksettings().
>
> Could you look into the behaviour of netifd, especially if it gets
> -ENODEV during the first read. Does it try again after setting the
> interface up?
Netifd has no issues with linksettings reading/writing in admin state.
Getting a rc=0 it assumes that all values are filled, changes the needed
attributes and writes them back. I retested and think there might be a
solution to avoid unneeded Ioctl access (see [1])
> If we know phylink is going to return a subset of the correct
> information when the interface is admin down, maybe it should return
> -ENODEV?
Or (stupid idea) phylink_ethtool_ksettings_set() should not accept all
settings in this state.
Thanks for your valuable input.
Markus
[1] https://github.com/openwrt/netifd/issues/76#issuecomment-4283478081
prev parent reply other threads:[~2026-04-20 19:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-18 9:27 pre-boot plugged SFP autoneg advertisement markus.stockhausen
2026-04-18 15:25 ` Andrew Lunn
2026-04-19 8:49 ` AW: " markus.stockhausen
2026-04-20 16:16 ` markus.stockhausen
2026-04-20 17:57 ` Andrew Lunn
2026-04-20 19:10 ` markus.stockhausen [this message]
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='007401dcd0f9$5cc990a0$165cb1e0$@gmx.de' \
--to=markus.stockhausen@gmx.de \
--cc=andrew@lunn.ch \
--cc=daniel@makrotopia.org \
--cc=hkallweit1@gmail.com \
--cc=jan@3e8.eu \
--cc=jelonek.jonas@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.