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: <20250715155623.59fbc2c9@fedora.home>
Date: Tue, 15 Jul 2025 15:56:23 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
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 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.

True, I'm fine with the 0xffff return on address != 0

> > 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.

So should we instead move to a netdevsim PHY model where we would
emulate an mdio bus and use a pure genphy driver instead ?

If you see some future for nsim PHY as a testing ground for phylib (and
not only for ethnl), that would make sense :)

Maxime