[PATCH net-next 0/15] Add and use helper for PCS negotiation modes

[Vladimir Oltean]

On Fri, Jun 16, 2023 at 04:46:39PM +0100, Russell King (Oracle) wrote:
> So, no, the Microchip driver code is not the reason why these
> definitions were chosen. They were chosen because it's the logical
> set that gives PCS drivers what they need to know.
> 
> Start from inband + autoneg. Then inband + !autoneg. Then inband
> possible but not being used. Then "there's no inband possible for this
> mode". That's the four states.
> 
> I think having this level of detail is important if we want to think
> about those pesky inband-AN bypass modes, which make sense for only
> really the PHYLINK_PCS_NEG_INBAND_DISABLED state and not OUTBAND nor
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

don't you mean PHYLINK_PCS_NEG_INBAND_ENABLED? I fail to see why would
the bypass make any difference for INBAND_DISABLED, where presumably the
fiber BMCR of the attached PHY would have BMCR_ANENABLE unset.

And in that case, I still don't understand the need for distinguishing
between INBAND_DISABLED, OUTBAND, NONE. Sorry, slow-witted :)

> NONE state. Bypass mode doesn't make sense for e.g. SGMII because
> one needs to know the speed for the link to come up, and if you're
> getting that through an out-of-band mechanism, you're into forcing
> the configuration at the PCS end.
> 
> Makes sense?

I refreshed my memory with this thread
https://patchwork.kernel.org/project/netdevbpf/patch/20221118000124.2754581-4-vladimir.oltean@nxp.com/
regarding in-band AN bypass on m88e1011, and the fact that enabling
in-band AN bypass with SGMII forces an advertisement of only
1000baseT/Half and 1000baseT/Full on the media side.

So.. correct, but I still don't get the overall answer to the question
I have, which is "why would drivers want to make any legitimate
distinction between INBAND_DISABLED and OUTBAND, when for all intents
and purposes, those 2 modes are nothing but the same physical state,
reached from 2 different phylink configuration path"?