[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230830180437.583e6383@kernel.org>
Date: Wed, 30 Aug 2023 18:04:37 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Nicolò Veronese <nicveronese@...il.com>,
netdev@...r.kernel.org, simonebortolin@...k-gpon.org,
nanomad@...k-gpon.org, Federico Cappon <dududede371@...il.com>,
daniel@...rotopia.org, lorenzo@...nel.org, ftp21@...21.eu,
pierto88@...k-gpon.org, hitech95@...k-gpon.org, davem@...emloft.net,
andrew@...n.ch, edumazet@...gle.com, hkallweit1@...il.com,
pabeni@...hat.com, nbd@....name
Subject: Re: [RFC] RJ45 to SFP auto-sensing and switching in mux-ed
single-mac devices (XOR RJ/SFP)
On Tue, 29 Aug 2023 16:38:42 +0100 Russell King (Oracle) wrote:
> So technically it's possible. However, there is no notification to
> userspace when such a change may occur. There's also the issue that
> userspace may be in the process of issuing ethtool commands that are
> affecting one of the PHYs. While holding the rtnl lock will block
> those calls, a change between the PHY and e.g. a PHY on the SFP
> would cause the ethtool command to target a different PHY from what
> was the original target.
>
> To solve that sanely, every PHY-based ethtool probably needs a way
> to specify which PHY the command is intended for, but then there's
> the question of how userspace users react to that - because it's
> likely more than just modifying the ethtool utility, ethtool
> commands are probably used from many programs.
Would it simplify anything if we only did the selection from ndo_open?
We can send a notification to user space that the SFP got plugged in,
but its up to user space to down / up the interface to use it?
Powered by blists - more mailing lists