On Sat, 12 Jul 2025 18:54:38 +0200 Andrew Lunn andrew@lunn.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