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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230620105403.bkwwigh77wrkxbjr@skbuf>
Date: Tue, 20 Jun 2023 13:54:03 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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:
> 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"?