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

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

[Maxime Chevallier]

Now that timestamping is controlled through an NDO, we can simply
call phylink_mii_ioctl() to handle ioctls.

The only functional difference is that phylink_mii_ioctl() ->
phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
as this ioctl is not longer dispatched to the ndo_eth_ioctl().

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---

Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
handling in phy_mii_ioctl(). Looks like we can ?

 .../net/ethernet/stmicro/stmmac/stmmac_main.c   | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..562d20830b94 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6371,28 +6371,17 @@ static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
  *  @rq: An IOCTL specific structure, that can contain a pointer to
  *  a proprietary structure used to pass information to the driver.
  *  @cmd: IOCTL command
- *  Description:
- *  Currently it supports the phy_mii_ioctl(...) and HW time stamping.
+ *  Description: Forward the PHY ioctls to phylink
+ *  Return: Zero on success or negative error code.
  */
 static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 {
 	struct stmmac_priv *priv = netdev_priv (dev);
-	int ret = -EOPNOTSUPP;
 
 	if (!netif_running(dev))
 		return -EINVAL;
 
-	switch (cmd) {
-	case SIOCGMIIPHY:
-	case SIOCGMIIREG:
-	case SIOCSMIIREG:
-		ret = phylink_mii_ioctl(priv->phylink, rq, cmd);
-		break;
-	default:
-		break;
-	}
-
-	return ret;
+	return phylink_mii_ioctl(priv->phylink, rq, cmd);
 }
 
 static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
-- 
2.55.0

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

[Vadim Fedorenko]

On 18.07.2026 15:38, Maxime Chevallier wrote:
> Now that timestamping is controlled through an NDO, we can simply
> call phylink_mii_ioctl() to handle ioctls.
> 
> The only functional difference is that phylink_mii_ioctl() ->
> phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
> as this ioctl is not longer dispatched to the ndo_eth_ioctl().
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
> 
> Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
> handling in phy_mii_ioctl(). Looks like we can ?
> 
>   .../net/ethernet/stmicro/stmmac/stmmac_main.c   | 17 +++--------------
>   1 file changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 2a0d7eff88d3..562d20830b94 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6371,28 +6371,17 @@ static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
>    *  @rq: An IOCTL specific structure, that can contain a pointer to
>    *  a proprietary structure used to pass information to the driver.
>    *  @cmd: IOCTL command
> - *  Description:
> - *  Currently it supports the phy_mii_ioctl(...) and HW time stamping.
> + *  Description: Forward the PHY ioctls to phylink
> + *  Return: Zero on success or negative error code.
>    */
>   static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>   {
>   	struct stmmac_priv *priv = netdev_priv (dev);
> -	int ret = -EOPNOTSUPP;
>   
>   	if (!netif_running(dev))
>   		return -EINVAL;
>   
> -	switch (cmd) {
> -	case SIOCGMIIPHY:
> -	case SIOCGMIIREG:
> -	case SIOCSMIIREG:
> -		ret = phylink_mii_ioctl(priv->phylink, rq, cmd);
> -		break;
> -	default:
> -		break;
> -	}
> -
> -	return ret;
> +	return phylink_mii_ioctl(priv->phylink, rq, cmd);
>   }
>   
>   static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

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

[Andrew Lunn]

> 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()?

	Andrew

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

[Vadim Fedorenko]

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.

Is it possible to have ioctl on phy device directly without involving netdev?

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

[Maxime Chevallier]

On 7/20/26 17:17, 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?

Indeed, but even then the SIOCxHWTSTAMP aren't reaching the ndo_ioctl.

Maybe the thing to change (unrelated to the icotl though) is in
dev_set_hwtstamp :

	if (!ops->ndo_hwtstamp_set)
		return -EOPNOTSUPP;

	if (!netif_device_present(dev))
		return -ENODEV;

	netdev_lock_ops(dev);
	err = dev_set_hwtstamp_phylib(dev, &kernel_cfg, &extack);
	netdev_unlock_ops(dev);

We don't try to configure the PHY timestamping if the MAC doesn't support the
.ndo, maybe we should allow that ?

>>
>> 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.

That was also my understanding indeed.
> Is it possible to have ioctl on phy device directly without involving netdev?

Unless there's an obscure mechanism I don't know about, there shouldn't be a way.

SIOCSHWTSTAMP/SIOCGHWTSTAMP don't seem to reach netdev anymore with the (great !) work
you've done, so they won't reach the PHY either indeed.

The SIOC ioctls can't reach PHYs without a netdev, neither can the ethnl ones.
Even when we have multiple PHYs and we use netlink, we can only reach the ones
behind a netdevice.

There is still sysfs entries for standalone PHYs, but I don't think we can use
any of that for ioctl.

Maxime

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

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