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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZIyFNSnwahdL0A8s@shell.armlinux.org.uk>
Date: Fri, 16 Jun 2023 16:52:21 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Alexander Couzens <lynxis@...0.eu>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Cc@....codeaurora.org:Claudiu Beznea <claudiu.beznea@...rochip.com>,
	Daniel Golle <daniel@...rotopia.org>,
	Daniel Machon <daniel.machon@...rochip.com>,
	"David S. Miller" <davem@...emloft.net>,
	DENG Qingfang <dqfext@...il.com>, Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	Ioana Ciornei <ioana.ciornei@....com>,
	Jakub Kicinski <kuba@...nel.org>,
	Jose Abreu <Jose.Abreu@...opsys.com>,
	Landen Chao <Landen.Chao@...iatek.com>,
	Lars Povlsen <lars.povlsen@...rochip.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org,
	Madalin Bucur <madalin.bucur@....com>,
	Marcin Wojtas <mw@...ihalf.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Michal Simek <michal.simek@....com>, netdev@...r.kernel.org,
	Nicolas Ferre <nicolas.ferre@...rochip.com>,
	Paolo Abeni <pabeni@...hat.com>,
	Radhey Shyam Pandey <radhey.shyam.pandey@...inx.com>,
	Sean Anderson <sean.anderson@...o.com>,
	Sean Wang <sean.wang@...iatek.com>,
	Steen Hegelund <Steen.Hegelund@...rochip.com>,
	Taras Chornyi <taras.chornyi@...ision.eu>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next 0/15] Add and use helper for PCS negotiation
 modes

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!