From 0523d5c52a450590bf5992bd6925394f3cc403e8 Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin Date: Thu, 3 Sep 2026 12:36:51 +0000 Subject: [PATCH 1/2] net: macb: zero the link settings taprio reads back macb_taprio_setup_replace() calls phylink_ethtool_ksettings_get() with an uninitialised kset, and kset is not only an out-parameter. On a fixed link, or an in-band link with no PHY, phylink writes speed and duplex only if kset->base.rate_matching already reads RATE_MATCH_NONE, a field it never writes itself; in PHY mode before the PHY is attached it writes port and supported and nothing more. Either way the speed read back afterwards can be stack garbage. The ethtool core zeroes the structure on every path into the op, which is why its callers never see this; taprio is the only in-kernel caller passing its own variable. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-2-f@lex.la Signed-off-by: Paolo Abeni --- drivers/net/ethernet/cadence/macb_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 8469df0d89c3..9be28b4fddb8 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -4300,9 +4300,9 @@ static int macb_taprio_setup_replace(struct net_device *netdev, u64 total_on_time = 0, start_time_sec = 0, start_time = conf->base_time; u32 configured_queues = 0, speed = 0, start_time_nsec; struct macb_queue_enst_config *enst_queue; - struct tc_taprio_sched_entry *entry; + struct ethtool_link_ksettings kset = {}; struct macb *bp = netdev_priv(netdev); - struct ethtool_link_ksettings kset; + struct tc_taprio_sched_entry *entry; struct macb_queue *queue; u32 queue_mask; u8 queue_id; From 2b6c0e25a3d713c4032e45f212bdd9e14c50f8a0 Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin Date: Thu, 3 Sep 2026 12:36:52 +0000 Subject: [PATCH 2/2] net: macb: reject an unknown link speed in the taprio setup speed is a u32, so SPEED_UNKNOWN arrives as 0xffffffff and passes the "speed <= 0" check, which only ever catches zero. That is what an autonegotiating link reports while it is down: the limit derived from the speed collapses to a nanosecond at most and the first entry fails with a misleading "exceeds hardware limit". Zero stays covered, it is what an interface that was never opened reports, and enst_max_hw_interval() divides by it. Say which case it was in the error. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-3-f@lex.la Signed-off-by: Paolo Abeni --- drivers/net/ethernet/cadence/macb_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 9be28b4fddb8..0e75339fa206 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -4329,8 +4329,8 @@ static int macb_taprio_setup_replace(struct net_device *netdev, } speed = kset.base.speed; - if (unlikely(speed <= 0)) { - netdev_err(netdev, "Invalid speed: %d\n", speed); + if (unlikely(speed == SPEED_UNKNOWN || !speed)) { + netdev_err(netdev, "Invalid speed %d, link-down?\n", speed); return -EINVAL; }