Re: [PATCH net-next] net: stmmac: Simplify ioctl handling

[Vadim Fedorenko]

On 20.07.2026 19:12, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 04:17:32PM +0100, Vadim Fedorenko wrote:
> > On 19.07.2026 17:13, Andrew Lunn wrote:
> > > > Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
> > > > handling in phy_mii_ioctl(). Looks like we can ?
> > >
> > > I'm not sure about that. We need Richards input.
> > >
> > > The code in phy_mii_ioctl() allows the MAC to be bypassed, it goes
> > > straight to a PHY based stamper. It could be the MAC has no idea the
> > > PHY has this capability, so it has not implemented the .ndo?
> > >
> > > It might be we need to hoist the code from phy_mii_ioctl() into
> > > dev_{sg}et_hwtstamp()?
> >
> > Hi Andrew!
> >
> > I think I've converted all phy drivers while removing support for
> > SIOCSHWTSTAMP/SIOCGHWTSTAMP from netdev ioctl. I believe it's impossible right
> > now to reach SIOCSHWTSTAMP path of phy_mii_ioctl via ioctl on net device.
>
> Lets look at this, using a random example:
>
> drivers/net/ethernet/marvell/mv643xx_eth.c
>
> mv643xx_eth_netdev_ops has nothing about time stamping. However it
> does have a mv643xx_eth_ioctl. Which calls phy_mii_ioctl().
>
> Lets say this Marvell MAC driver was paired with a
> nxp-c45-tja11xx. nxp_c45_probe() does:
>
>                  priv->mii_ts.rxtstamp = nxp_c45_rxtstamp;
>                  priv->mii_ts.txtstamp = nxp_c45_txtstamp;
>                  priv->mii_ts.hwtstamp_set = nxp_c45_hwtstamp_set;
>                  priv->mii_ts.hwtstamp_get = nxp_c45_hwtstamp_get;
>                  priv->mii_ts.ts_info = nxp_c45_ts_info;
>                  phydev->mii_ts = &priv->mii_ts;
>
> So it looks like in phy_mii_ioctl(), the conditions:
>
>         case SIOCSHWTSTAMP:
>                  if (phydev->mii_ts && phydev->mii_ts->hwtstamp_set) {
>
> are fulfilled, and
>
>                          ret = phydev->mii_ts->hwtstamp_set(phydev->mii_ts,
>                                                             &kernel_cfg,
>                                                             &extack);
>
> will happen.
>
> Now, this combination of MAC and PHY is very unlikely but it proves
> the point. As far as i remember, Richard added this code for the
> dp83640 PHY device, but i don't remember what MAC driver it was paired
> with. He wanted to make PHY support just work without the MAC driver
> even caring.

looks like it won't work now. we have to create helpers in phy to fix it.
I can work on it, but I don't have such HW combination to test. Do you have some 
HW to test this combination?


> 	Andrew