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: <aWwj0AaWPOOMb5oX@makrotopia.org>
Date: Sun, 18 Jan 2026 00:05:36 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: hkallweit1@...il.com, linux-kernel@...r.kernel.org,
	michael@...sekall.de, linux@...linux.org.uk, edumazet@...gle.com,
	andrew@...n.ch, olek2@...pl, davem@...emloft.net,
	vladimir.oltean@....com, netdev@...r.kernel.org, pabeni@...hat.com,
	clm@...a.com
Subject: Re: [v2,2/5] net: phy: realtek: simplify C22 reg access via
 MDIO_MMD_VEND2

On Sat, Jan 17, 2026 at 03:55:15PM -0800, Jakub Kicinski wrote:
> On Sat, 17 Jan 2026 23:40:36 +0000 Daniel Golle wrote:
> > > > @@ -1156,7 +1156,8 @@ static int rtlgen_read_status(struct phy_device *phydev)
> > > >  	if (!phydev->link)
> > > >  		return 0;
> > > >
> > > > -	val = phy_read(phydev, RTL_PHYSR);
> > > > +	val = phy_read_paged(phydev, RTL822X_VND2_TO_PAGE(RTL_VND2_PHYSR),
> > > > +			     RTL822X_VND2_TO_PAGE_REG(RTL_VND2_PHYSR));  
> > > 
> > > This changes rtlgen_read_status() from reading C22 register MII_RESV2
> > > (0x1a) directly to using paged access at page 0xa43, register 18.  
> > 
> > Yeah. Just that this is not part of the series submitted.
> > It's rather a (halucinated) partial revert of
> > [v2,4/5] net: phy: realtek: demystify PHYSR register location
> 
> Oh wow, that's a first. No idea how this happened. Is the chunk if
> hallucinated from another WIP patch set?

No, it's a partial revert of a later patch in the same series.

> 
> Chris, FWIW this is before we added lore indexing so I don't think 
> it got it from the list. Is it possible that semcode index is polluted
> by previous submissions? Still, even if, it's weird that it'd
> hallucinate a chunk of a patch.

I don't think that as it is literally the revert of a later patch
in the same series. I don't think this has ever been submitted as
forward-patch, because it wouldn't ever apply throughout the history
of the driver. But it somehow superficially resembles

https://lore.kernel.org/netdev/a53d4577335fdda4d363db9bc4bf614fd3a56c9b.1767630451.git.daniel@makrotopia.org/

(which is pretty recent and was applied)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ