From: "Théo Lebrun" <theo.lebrun@bootlin.com>
To: "Aleksei Sviridkin" <f@lex.la>
Cc: "Conor Dooley" <conor.dooley@microchip.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Russell King" <linux@armlinux.org.uk>,
"Vineeth Karumanchi" <vineeth.karumanchi@amd.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net 2/2] net: macb: reject an unknown link speed in the taprio setup
Date: Wed, 02 Sep 2026 10:57:16 +0200 [thread overview]
Message-ID: <DL4PF7CMPTLQ.7BII0H280PHE@bootlin.com> (raw)
In-Reply-To: <20260902080528.2211468-3-f@lex.la>
Hello Aleksei,
On Wed Sep 2, 2026 at 10:05 AM CEST, Aleksei Sviridkin wrote:
> speed is a u32, so SPEED_UNKNOWN arrives as 0xffffffff and passes the
> "speed <= 0" check. A taprio schedule installed while the link is down
> then has its hardware interval limit derived from that value, a limit
> that rounds to 1 ns, and the first entry fails with a misleading
> "exceeds hardware limit". Name the case instead of relying on the
> sign.
I don't understand the
Name the case instead of relying on the sign.
sentence, it seems to contradict what really happens which is
SPEED_UNKNOWN [...] passes the "speed <= 0" check
> Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support")
> Assisted-by: LLM
> Signed-off-by: Aleksei Sviridkin <f@lex.la>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index a43855db1e45..81530b9257b2 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -4324,7 +4324,7 @@ static int macb_taprio_setup_replace(struct net_device *netdev,
> }
>
> speed = kset.base.speed;
> - if (unlikely(speed <= 0)) {
> + if (unlikely(speed == SPEED_UNKNOWN || !speed)) {
> netdev_err(netdev, "Invalid speed: %d\n", speed);
> return -EINVAL;
> }
The zero case shouldn't happen, it's SPEED_UNKNOWN that can occur often
(on link down). It's basically the same as checking netif_running().
Doesn't the netdev_err() call deserve a fix in the SPEED_UNKNOWN case?
We might be printing "Invalid speed: 4294967295". I don't think we want
two format strings (0 or SPEED_UNKNOWN).
We could do "Invalid speed %d, link-down?\n".
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2026-09-02 8:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 8:05 [PATCH net 0/2] net: macb: fix the link speed the taprio setup reads Aleksei Sviridkin
2026-09-02 8:05 ` [PATCH net 1/2] net: macb: zero the link settings taprio reads back Aleksei Sviridkin
2026-09-02 8:32 ` Théo Lebrun
2026-09-02 8:05 ` [PATCH net 2/2] net: macb: reject an unknown link speed in the taprio setup Aleksei Sviridkin
2026-09-02 8:57 ` Théo Lebrun [this message]
2026-09-02 16:37 ` Andrew Lunn
2026-09-03 12:36 ` Aleksei Sviridkin
2026-09-04 23:45 ` Aleksei Sviridkin
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=DL4PF7CMPTLQ.7BII0H280PHE@bootlin.com \
--to=theo.lebrun@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor.dooley@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f@lex.la \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vineeth.karumanchi@amd.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.