> > On Sat, 12 Jul 2025 18:54:38 +0200 > > Andrew Lunn <[email protected]> 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
