All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Qingtao Cao <qingtao.cao.au@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] net: phy: marvell: avoid bringing down fibre link when autoneg is bypassed
Date: Fri, 4 Oct 2024 14:42:23 +0100	[thread overview]
Message-ID: <Zv_wv67TGIUz5IZy@shell.armlinux.org.uk> (raw)
In-Reply-To: <927d5266-503c-499f-877c-5350108334dc@lunn.ch>

On Fri, Oct 04, 2024 at 03:26:33PM +0200, Andrew Lunn wrote:
> 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@lunn.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?

The paragraph about it is couched in terms of "if the MAC or the PHY
implements the auto-negotiation function and the other end does not".

That seems to point towards a MAC <-> PHY link rather than across a
media. So I tend to agree with you that we should not be enabling
bypass mode on a media side link.

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

  reply	other threads:[~2024-10-04 13:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-03  2:25 [PATCH 1/1] net: phy: marvell: avoid bringing down fibre link when autoneg is bypassed Qingtao Cao
2024-10-03  4:39 ` Parthiban.Veerasooran
2024-10-03 14:30 ` Andrew Lunn
2024-10-03 15:13   ` Russell King (Oracle)
     [not found]   ` <CAPcThSHa82QDT6sSrqcGMf7Zx4J15P7KpgfnD-LjJQi0DFh7FA@mail.gmail.com>
2024-10-04 13:26     ` Andrew Lunn
2024-10-04 13:42       ` Russell King (Oracle) [this message]
     [not found]         ` <CAPcThSHA3bfvwbHWtL2HrDtv=d9z9vGape94J7Pucq65csHN3A@mail.gmail.com>
2024-10-05 16:42           ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zv_wv67TGIUz5IZy@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=qingtao.cao.au@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.