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

[Andrew Lunn]

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.

	Andrew