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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260110143018.56a19502@kernel.org>
Date: Sat, 10 Jan 2026 14:30:18 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Heiner Kallweit <hkallweit1@...il.com>, Andrew Lunn <andrew@...n.ch>,
 Andrew Lunn <andrew+netdev@...n.ch>, Russell King - ARM Linux
 <linux@...linux.org.uk>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
 <edumazet@...gle.com>, David Miller <davem@...emloft.net>, Vladimir Oltean
 <vladimir.oltean@....com>, Michael Klein <michael@...sekall.de>, Realtek
 linux nic maintainers <nic_swsd@...ltek.com>, Aleksander Jan Bajkowski
 <olek2@...pl>, Fabio Baltieri <fabio.baltieri@...il.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 0/2] r8169: add support for RTL8127ATF (10G
 Fiber SFP)

On Sat, 10 Jan 2026 20:08:12 +0000 Daniel Golle wrote:
> > > 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).

SG! Thanks for breaking the tie.