linux-kernel - Re: [PATCH 1/1] net: phy: marvell: avoid bringing down fibre link when autoneg is bypassed

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-next>] [day] [month] [year] [list]

Message-ID: <927d5266-503c-499f-877c-5350108334dc@lunn.ch>
Date: Fri, 4 Oct 2024 15:26:33 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Qingtao Cao <qingtao.cao.au@...il.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] net: phy: marvell: avoid bringing down fibre link
 when autoneg is bypassed

On Fri, Oct 04, 2024 at 11:35:30AM +1000, Qingtao Cao wrote:
> Hi Andrew,
> 
> Please see my inline replies.
> 
> On Fri, Oct 4, 2024 at 12:30 AM Andrew Lunn <andrew@...n.ch> wrote:
> 
>     On Thu, Oct 03, 2024 at 12:25:12PM +1000, Qingtao Cao wrote:
>     > On 88E151x the SGMII autoneg bypass mode defaults to be enabled. When it
>     is
>     > activated, the device assumes a link-up status with existing
>     configuration
>     > in BMCR, avoid bringing down the fibre link in this case
>     >
>     > Test case:
>     > 1. Two 88E151x connected with SFP, both enable autoneg, link is up with
>     speed
>     >    1000M
>     > 2. Disable autoneg on one device and explicitly set its speed to 1000M
>     > 3. The fibre link can still up with this change, otherwise not.
> 
>     What is actually wrong here?
> 
>     If both ends are performing auto-neg, i would expect a link at the
>     highest speeds both link peers support.
> 
>     If one peer is doing autoneg, the other not, i expect link down, this
>     is not a valid configuration, since one peer is going to fail to
>     auto-neg.
> 
> 
> Well, technically speaking, thanks to the 88E151X's bypass mode, in such case
> with one end using autoneg but the other is using 1000M explicitly, the link
> could still be up, but not with the current code.

So we can make an invalid configuration work. Question is, should we?

Are we teaching users they can wrongly configure their system and
expect it to work? They then think it is actually a valid
configuration and try the same on some other board with other PHYs,
and find it does not work?

Does Marvell document why this bypass mode exists? When it should be
used? What do they see as its use cases?

	Andrew