linux-kernel - Re: [PATCH] r8169: add support for RTL8127ATF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aR2baZuFBuA7Mx_x@google.com>
Date: Wed, 19 Nov 2025 10:26:49 +0000
From: Fabio Baltieri <fabio.baltieri@...il.com>
To: Michael Zimmermann <sigmaepsilon92@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, nic_swsd@...ltek.com,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] r8169: add support for RTL8127ATF

On Wed, Nov 19, 2025 at 08:00:01AM +0100, Michael Zimmermann wrote:
> I've also done some testing with the out-of-tree driver:
> - (my normal setup) a DAC between the rt8127 and a 10G switch works just fine.
> - RJ45 10G modules on both sides works fine, but HwFiberModeVer stays
> at 1 even after reloading the driver.
> - RJ45 1G modules on both sides works after "ethtool -s enp1s0 speed
> 1000 duplex full autoneg on", but you have to do that while connected
> via 10G because that driver is buggy and returns EINVAL otherwise.
> HwFiberModeVer was 1 as well after reloading the driver.

You are right, did some more extensive testing and it seems like
switching speed is somewhat unreliable.

I've also bumped into
https://lore.kernel.org/netdev/cc1c8d30-fda0-4d3d-ad61-3ff932ef0222@gmail.com/
and sure enough this is affected too, it also does not survive suspend
without the wol flag, but more importantly I've found that the serdes
has to be reconfigured on resume, so I need to send a v2 moving some
code around.

> What this means is that the fiber mode is always enabled on these
> cards, which makes sense given that the out-of-tree driver only reads
> it once when loading the driver. I guess it's either a hardware
> variant, configured in the factory or detected using a pin of the
> chip.
> It also means that it doesn't matter to the linux driver what's
> actually connected beyond the speed you want to use since - as others
> have said before - this seems to be fully handled on the NIC.

Yeah but that make sense, it does not really mean *fiber* mode, it
controls the serdes configuration which is used both by fiber
transceiver and DACs or anything else you plug in the SFP port. It's a
good point though I think it may be a good idea to rename it to
something like "sfp_mode" so it's not ambiguous.

Heiner: if I'm reading the room right you are more keen to have a more
minimal initial support patch: I'm sending a v2 anyway to fix up the
standby support, would you like me to rip off the 1g code and keep it
10g only while at it? Then we can have at least that hopefully working
reliably, as you pointed out that's probably what the vast majority of
users of this nic needs anyway.