[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACKFLi=Mpc8GDu=r_HW36hYcGdBDx==O6wc+8vBTPm8MaMrUAQ@mail.gmail.com>
Date: Sun, 4 Feb 2024 19:38:16 -0800
From: Michael Chan <michael.chan@...adcom.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>, Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
David Miller <davem@...emloft.net>, Russell King - ARM Linux <linux@...linux.org.uk>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] bnxt: convert EEE handling to use linkmode bitmaps
On Sat, Feb 3, 2024 at 8:46 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Sat, Feb 03, 2024 at 04:16:51PM -0800, Michael Chan wrote:
> > I think it is correct. EEE advertised must be a subset of the
> > advertised speed.
>
> I don't think that is true. At least, i've not seen any other MAC/PHY
> driver change EEE advertising when they change the general
> advertising. What i expect is that the PHY and link partner first
> resolve the general link speed. They then look at what is being
> advertised in terms of EEE and decide if EEE is being advertised by
> both ends at the resolved speed. So it does not matter if the link
> speed is resolved at 1G, but both ends advertise both 40G and 1G for
> EEE. The 40G is simply ignored because they have resolved to 1G.
I need to check with the FW team to see if it's implemented the way
you described. If it accepts EEE advertisement bits that are not set
for speed advertisements, then we can make the change. Thanks.
> What does however matter is that EEE supported lists only 1G, but user
> space ask for both 1G and 40G to be advertised. I would expect the
> driver to mask the requested advertised with support, see that
> unsupported link modes are being asked for and return -EINVAL.
>
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4209 bytes)
Powered by blists - more mailing lists