Hi Andrew

I am sorry, I have a bit of sidetracking...

quoted

State Persistence and Toggling When toggling autoneg (e.g., autoneg on -> off
-> on), should the kernel or driver cache the previous advertisement?

This has been discussed in the past, and i _think_ phylink does.

But before we go too far into edge causes, my review experience is
that MAC drivers get the basics wrong. What we really want to do here
is:

1) Push driver developers towards phylink

Is it something we should insist on in the review process ? Can we make
it a hard requirement that _new_ MAC drivers need to use phylink, if the
driver plans to interact with a PHY ?

phylink has long outgrown the original use-case of supporting SFPs by
abstracting away the MAc to [PHY/SFP] interactions, it's now used as a
an abstraction layer that avoids MAC drivers making the same mistakes
over and over again on a lot of cases that don't have anything to do
with SFP.

I think we can no longer really say "If your driver is simple enough,
you can stick to using phylib directly", at least not for new drivers,
as phylink now simplifies EEE, WoL, Pause, etc.

2) For those who don't use phylink give clear documentation of the
   basics.

We can look at edge cases, but i would only do it in the context of
phylink. Its one central implementation means we can add complexity
there and not overload developers who get the basics wrong.

	Andrew

Maxime