linux-kernel - Re: [PATCH net-next v3 1/3] net: netdevsim: Add PHY support in netdevsim

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: <9c30b1ab-95fe-4238-950e-23bbd1bb1632@lunn.ch>
Date: Tue, 15 Jul 2025 15:23:10 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
	Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>,
	Florian Fainelli <f.fainelli@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Köry Maincent <kory.maincent@...tlin.com>,
	Oleksij Rempel <o.rempel@...gutronix.de>,
	Simon Horman <horms@...nel.org>, Shuah Khan <shuah@...nel.org>,
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v3 1/3] net: netdevsim: Add PHY support in
 netdevsim

On Tue, Jul 15, 2025 at 08:05:32AM +0200, Maxime Chevallier wrote:
> On Sat, 12 Jul 2025 18:54:38 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
> > > +static int nsim_mdio_read(struct mii_bus *bus, int phy_addr, int reg_num)
> > > +{
> > > +	return 0;
> > > +}
> > > +
> > > +static int nsim_mdio_write(struct mii_bus *bus, int phy_addr, int reg_num,
> > > +			   u16 val)
> > > +{
> > > +	return 0;
> > > +}  
> > 
> > If i'm reading the code correctly, each PHY has its own MDIO bus? And
> > the PHY is always at address 0?
> 
> Yes indeed. 
> 
> > Maybe for address != 0, these should return -ENODEV?
> 
> That could be done yes, but I don't think this will ever happen as this
> is only ever going to be used in netdevsim, which also controls the PHY
> instantiation. I'm OK to add the ENODEV though :)

It makes the simulation more realistic. The other option is to return
0xffff on read, which is what a real MDIO bus would do when you access
an address without a device.

It currently should not happen, but this is the sort of framework
which will get expanded with time. So this low hanging fruit could
avoid issues later.

> For the record, the first draft implementation I had locally used a
> single MDIO bus on which we could register up to 32 netdevsim PHYs, but
> that wasn't enough. At some point Jakub pointed me to the case of
> netlink DUMP requests that would be too large to fit in a single
> netlink message (default threshold for that is > 4K messages), so to
> test that with the phy_link_topology stuff, I had to add around 150
> PHYs...

I'm happy with an MDIO bus per PHY, for the reasons you give.

> > I'm guessing the PHY core is going to perform reads/writes for things
> > like EEE? And if the MAC driver has an IOCTL handler, it could also do
> > reads/writes. So something is needed here, but i do wounder if hard
> > coded 0 is going to work out O.K? Have you looked at what accesses the
> > core actually does?
> 
> I don't see that driver being useful outside of netdevsim, so at
> least we have a good idea of what the MAC driver will do.
>
> There'e no ioctl, but we can be on the safe side and stub it a bit more.
> 
> From the tests I've been running, I didn't encounter any side-effect
> but I only tested very simple cases (set link up, run ethtool, etc.)

It is hard to say where this will lead. We have seen bugs with EEE, so
being able to test that might be interesting to someone. Given that is
all in the core, that would require implementing the C45 over C22 and
the EEE registers.

> I've considered re-using swphy for example, and using an emulated MDIO
> bus for netdevsim PHY, but my fear was that this would in the end get
> too complex.

Yes, i thought about that too. But i agree, that is the wrong way to
go. We would end up adding a lot of features to swphy which never get
used in real system, and potentially had bugs to real systems. An
emulated PHY for netdevsim might start as a copy/paste of swphy, but i
would then expect it to quickly diverge.

	Andrew