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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, Jun 16, 2023 at 04:46:39PM +0100, Russell King (Oracle) wrote:
> On Fri, Jun 16, 2023 at 06:00:55PM +0300, Vladimir Oltean wrote:
> > Do you know for sure what this bit does and whether it makes sense for
> > drivers to even distinguish between OUTBAND and INBAND_DISABLED in the
> > way that this series is proposing?
> 
> I have no idea, and I didn't bother investigating - I don't want to go
> around trying to disect drivers to figure out whether they're buggy or
> not.
> 
> However, what I would say is that this is not where these modes came
> from. They came from me asking myself the question "what would be the
> logical set of information to give a PCS driver about the negotiation
> state of the link?" and that's what I came up with _without_ reference
> to this driver. The states are all documented in the first patch and
> what they mean.
> 
> 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
> 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.

I should also add... yes, I did _then_ subsequently use the microchip
driver as a justification for it. I probably should've explained it
without using that as justification.

I could also have used the sja1105 driver as well, since:

	MLO_AN_INBAND => PHYLINK_PCS_NEG_INBAND_ENABLED
	MLO_AN_FIXED || MLO_AN_PHY => PHYLINK_PCS_NEG_OUTBAND

are the conversions done there, which fits with:

-               if (!phylink_autoneg_inband(mode)) {
+               if (neg_mode == PHYLINK_PCS_NEG_OUTBAND) {

since the opposite of !inband is outband.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!