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

On 20/07/2026 19:12, Andrew Lunn wrote:

On Mon, Jul 20, 2026 at 04:17:32PM +0100, Vadim Fedorenko wrote:

quoted

On 19.07.2026 17:13, Andrew Lunn wrote:

quoted

quoted

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.

Richard,

is it still a case? do you have a HW to test patches that I'm going to
write to restore the functionality?