Re: [PATCH net-next v2 0/2] r8169: add support for RTL8127ATF (10G Fiber SFP)

[Daniel Golle <daniel@makrotopia.org>]

On Sat, Jan 10, 2026 at 09:03:05PM +0100, Heiner Kallweit wrote:
> On 1/10/2026 7:48 PM, Jakub Kicinski wrote:
> > On Sat, 10 Jan 2026 16:12:30 +0100 Heiner Kallweit wrote:
> >> RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
> >> DAC). The list of supported modes was provided by Realtek. According to the
> >> r8127 vendor driver also 1G modules are supported, but this needs some more
> >> complexity in the driver, and only 10G mode has been tested so far.
> >> Therefore mainline support will be limited to 10G for now.
> >> The SFP port signals are hidden in the chip IP and driven by firmware.
> >> Therefore mainline SFP support can't be used here.
> >> The PHY driver is used by the RTL8127ATF support in r8169.
> >> RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
> >> PHY ID.
> > 
> > Hi Heiner!
> > 
> > This series silently conflicts with Daniel's changes. I wasn't clear
> > whether the conclusion here:
> > https://lore.kernel.org/all/1261b3d5-3e09-4dd6-8645-fd546cbdce62@gmail.com/
> > is that we shouldn't remove the define or Daniel's changes are good 
> > to go in.. Could y'all spell out for me what you expect?
> 
> I'm fine with replacing RTL_VND2_PHYSR with RTL_PHYSR, as proposed by Daniel.
> However, as this isn't a fully trivial change, I'd like to avoid this change
> in my series, and leave it to Daniel's series. Means he would have to add
> the conversion of the call I just add.
> Which series to apply first depends on whether Daniel has to send a new version,
> or whether it's fine as-is. There was a number of comments, therefore I'm not
> 100% sure.

Imho it makes sense to merge RTL8127ATF first and I'll resend my current
series. There was a typo in one of the commit messages, but more than that
I think it does make sense to merge the non-controveral hardware addition
before applying any potentially disruptive stuff which affects practically
all PHYs supported by the driver (doesn't mean that I expect any disruption
what-so-ever, but as a matter of principle it just seems right to do it
that way around).