[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98e6266f-805c-4da2-b2dc-b25297c53742@lunn.ch>
Date: Wed, 29 May 2024 02:57:27 +0200
From: Andrew Lunn <andrew@...n.ch>
To: xiaolei wang <xiaolei.wang@...driver.com>
Cc: alexandre.torgue@...s.st.com, joabreu@...opsys.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
mcoquelin.stm32@...il.com, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [net PATCH] net: stmmac: update priv->speed to SPEED_UNKNOWN
when link down
On Wed, May 29, 2024 at 08:22:01AM +0800, xiaolei wang wrote:
>
> On 5/28/24 21:20, Andrew Lunn wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> > On Tue, May 28, 2024 at 05:20:10PM +0800, Xiaolei Wang wrote:
> > > The CBS parameter can still be configured when the port is
> > > currently disconnected and link down. This is unreasonable.
> > This sounds like a generic problem. Can the core check the carrier
> > status and error out there? Maybe return a useful extack message.
> >
> > If you do need to return an error code, ENETDOWN seems more
>
> Currently cbs does not check link status. If ops->ndo_setup_tc() returns
> failure, there will only be an output of "Specified device failed to setup
> cbs hardware offload".
So it sounds like we should catch this in the core then, not the
driver. And cbs_enable_offload() takes an extack, so you can report a
user friendly reason for failing, the at the carrier is off.
Andrew
---
pw-bot: cr
Powered by blists - more mailing lists