[RFC] Inconsistency in MDIO ioctl behaviour

[RFC] Inconsistency in MDIO ioctl behaviour

[Ben Hutchings]

While comparing the various implementations of SIOC{G,S}MIIREG and
SIOCGMIIPHY, I found some differences in behaviour that could make some
applications unreliable across different drivers.

1. Implementations of SIOCGMIIPHY must set phy_id to the PHY's MDIO
address (PRTAD) or to a dummy address if there is no real MDIO bus.
Many implementations, including the generic ones (mii, phylib,
pci-skeleton and now mdio) then proceed as for SIOCGMIIPHY.  Others
return without accessing any registers.  Which behaviour is right?

2. Implementations of SIOC{G,S}MIIREG that do not support access to
arbitary MDIO addresses handle non-matching values of phy_id in at least
three different ways:
(a) ignore it and always use the expected PHY address
(b) ignore writes and return a dummy value for reads
(c) fail
I favour behaviour (c) but I'm not sure what the error code should be.
ENODEV, EINVAL or EIO?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [RFC] Inconsistency in MDIO ioctl behaviour

[Ben Hutchings]

On Thu, 2009-09-03 at 22:04 +0100, Ben Hutchings wrote:
> While comparing the various implementations of SIOC{G,S}MIIREG and
> SIOCGMIIPHY, I found some differences in behaviour that could make some
> applications unreliable across different drivers.

...and I just got round to looking at this again.

> 1. Implementations of SIOCGMIIPHY must set phy_id to the PHY's MDIO
> address (PRTAD) or to a dummy address if there is no real MDIO bus.
> Many implementations, including the generic ones (mii, phylib,
> pci-skeleton and now mdio) then proceed as for SIOCGMIIPHY.  Others
> return without accessing any registers.  Which behaviour is right?

With a Google Code Search for SIOCGMIIPHY I found only one program that
assumes SIOCGMIIPHY reads a register.  That is mii-diag, which in
verbose mode prints val_out as the BMCR value, and since reg_num is
statically zero-initialised this works for many implementations.  For
all subsequent register reads, it uses SIOCGMIIREG.

In these 8 drivers, SIOCGMIIPHY doesn't read a register:

atl1c, atl1e, atl2, e1000, e1000e, igb, r8169, via-velocity

and in about 90 other drivers (including users of mii, mdio and phylib)
it does.  But the chips covered by the first 7 of those 8 drivers are
extremely widely used, and I expect that if anyone cared about
'mii-diag -v' or another utility with the same assumption then this
would have been reported to netdev repeatedly.

I'm inclined to say we should drop the register read from SIOCGMIIPHY
from the common implementations and pci-skeleton.c.

> 2. Implementations of SIOC{G,S}MIIREG that do not support access to
> arbitary MDIO addresses handle non-matching values of phy_id in at least
> three different ways:
> (a) ignore it and always use the expected PHY address
> (b) ignore writes and return a dummy value for reads
> (c) fail
> I favour behaviour (c) but I'm not sure what the error code should be.
> ENODEV, EINVAL or EIO?

I think ENODEV should be reserved for 'network device does not exist',
and EIO for a failure in I/O to hardware that we actually expect to be
there.  So EINVAL it is.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.