[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dcb34edd-a7ca-429a-896d-0f056ce02056@lunn.ch>
Date: Mon, 4 Sep 2023 00:51:05 +0200
From: Andrew Lunn <andrew@...n.ch>
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,
edumazet@...gle.com, hkallweit1@...il.com, kuba@...nel.org,
pabeni@...hat.com, nbd@....name, maxime.chevallier@...tlin.com
Subject: Re: [RFC] RJ45 to SFP auto-sensing and switching in mux-ed
single-mac devices (XOR RJ/SFP)
> 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.
This idea of extending ethtool with a PHY ID has discussed last
year. It helps solve some of the problems discussed here. You can then
enumerate all the PHYs connected to a MAC, and operate on each PHY
independently.
https://lore.kernel.org/netdev/20221017105100.0cb33490@pc-8.home/
Andrew
Powered by blists - more mailing lists