quoted

quoted

quoted

Huh? I'm guessing you're referring to some patches you have queued
already and don't want to rebase across? Or some project planning?
Otherwise I don't see a connection :S

In looking around at other implementations, I see where the link_up
and link_down are used to start or clean up the periodic workqueue
used to retrieve and accumulate the mib stats into the driver.  Can't tell
if that's a requirement or only needed when the device interface is
considered too slow.  The device interface is not atomic.

Atomic as in it reads over a bus which requires sleeping?
Yes, the stats ndo can't sleep because of the old procfs interface
which ifconfig uses and which is invoked under the RCU lock.

Jerry, did you respond to this (what do you mean by "device interface is
not atomic")?

Still not clear why transitioning to phylink is a requirement for
standardized statistics. You get your link up/link down events with
adjust_link too (phydev->link).

Some other drivers only perform periodic stats readout for ports that
are up, because those are the only ports where the stats can ever
change. That's about all that there is to know. There's no requirement
one way or another, it's an optimization.

Yes, Jakub's understanding is correct.  The device is accessed over the
mdio bus and as such, will sleep on hardware accesses.  This means that the
get_stats64 will need to respond with the mib info cached by the driver rather
than reading directly from the device.  This adds to the driver.

The phylink up/down DSA hooks will be used in controlling the workqueue
threads that periodically read and cache the stats info.

You are correct - It's not a hard requirement to first migrate to PHYLINK.
It's more of a logical progression of bringing the driver up-to-date. Having
adjust_link API still defined, you get the 
  "Using legacy PHYLIB callbacks. Please migrate to PHYLINK!"
message on board power-up.