[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <654EAEA9-052C-43C6-AA8E-16A30721A916@gmail.com>
Date: Wed, 03 Jan 2024 09:51:06 +0100
From: Eric Woudstra <ericwouds@...il.com>
To: Daniel Golle <daniel@...rotopia.org>
CC: "Russell King (Oracle)" <linux@...linux.org.uk>,
Alexander Couzens <lynxis@...0.eu>, Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Frank Wunderlich <frank-w@...lic-files.de>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH RFC net-next] net: pcs: pcs-mtk-lynxi fix mtk_pcs_lynxi_get_state() for 2500base-x
>Surely, having phylink take care whether SGMII_SPEED_DUPLEX_AN should be
>set would be even nicer.
>
>I believe that source of confusion here is simply that
>
>in-band-status != SGMII_SPEED_DUPLEX_AN
>
>We *do* have in-band-status even without having SGMII_SPEED_DUPLEX_AN set
>with 2500Base-X link mode (as in: link being up or down and link, duplex
>and speed is fixed anyway for 2500Base-X).
All clear, and even with autoneg disabled, one way or another, we now
have a non-functional 2500base-x. Cannot manipulate anything in
userland to get the connection functional. We need a fix in kernel.
Powered by blists - more mailing lists