From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DECD73E1225 for ; Fri, 12 Jun 2026 12:48:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781268496; cv=none; b=CDYt356A6398UQERa8cjk0sxn+cySWmikW73GJcAtXIJgbeOv98Fq8OItYAfaRABdzq5/2cTbG0yIOVXfd6EveQ/viNynbLZISS+EYfMmMwD2etJY7jNwF3+oQc4luuw91XIp/4bAS4HZnlBHD3kAw+ag1oOaN2PeywH1o1vzGQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781268496; c=relaxed/simple; bh=dgrH4tibqRVzcaGG9HYebar2uYlaqeZqMgjLUv7K3Nc=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YtW2DyzEjjXAMY25YlUGHTqMsmkl0iRNTJexfqQAc2yl/japJmbWljMXj1jkA4e6vQb8QRMr2MbHO8gVP8UCJZh3TXNsXXf5F84q2600zj3yTIj3PDdqBtAZU+YwIxr0Wg3IEM7nMVQNKg1etWmcZx0q3MQI0r6kRjskDaEMN/k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Nszp83T/; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Nszp83T/" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4908b92904fso9637955e9.0 for ; Fri, 12 Jun 2026 05:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1781268492; x=1781873292; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=X07QRTXhx7twtU7TUj4+VDEon2lHZrzRNetg8L7gZYk=; b=Nszp83T/JFptBIT/pJYa7yE64kCuWUYyJ279vGA2M54E/7ySA8GeJN3587SRuV7yeF 4zYpPKIsdfGNny3HuIoMZCf8RbEVSZqcpo164kNAqqpnjNPAsCXR/AjsQlOTw++M7VJj H/mUGq0M5U+6WlaovVaBZT+2i5ye6Y/QPVMrDVWbZXEtjo4Pk1JocRgrC80iRND93iTJ VtdOMTlMW/wozTCjdGBnR5iEUrlQJ5bamEFqeb+u6rBe+x/bd+wgxlJRHuxsGB5k1xBn CIwwngJu69og3dBbYnDh9cStSmU3p69Tgf8Q1dUcTU5bAIXJM/ZHRqMztTfVYbH6eGJ+ h5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781268492; x=1781873292; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X07QRTXhx7twtU7TUj4+VDEon2lHZrzRNetg8L7gZYk=; b=VYnwNqBQL5x2Z5s92121uOfSbTqGcLexAfEP+TwEsM4BV0KQbwTjntnlWXR2d32vH0 gvVVtEo6uRsxDOJsiZFQqnk4b98gGVQIiMPDbwH6xPqIamOyb/12JzFtGjHSDyxSrHwh 2B0irRNm5ay1fNMSvvfSTLZumljEF4/g07Qrb6bRxlqS+oXJwxx4BZEQFFF7Qu8ofyi2 3kT7SLWOmDaAdykUrW4pIlTIvfzyUIE/G7w86tRpHNdpH9LRnCJKvH/RKw7j1kv62XaI jrr2J69ZOTwmyT0trgNSkp+1pQGibrk2GlB89DyQ2phlXIUSvZhYXsCy2k2WhEoXfm5N SMuw== X-Forwarded-Encrypted: i=1; AFNElJ+LWvP4EktR1cXw4ASo/dC7CzRXtLi90LR8uDa1spJ7yfVnhymf3kd7ky5KuCnJEqP1AG+RgSpzswHaJqU=@vger.kernel.org X-Gm-Message-State: AOJu0YySUJLMLu+2jqX33CQrprd3X9sQZFTo1V4330kgJdLuMRMwDyiY 1kQq+4X1E/nineC8JG+L+vu9j6dfa7cK+7Ty1t3B2/cHIwjEedfeGMZIjM0V0t9NQkk= X-Gm-Gg: Acq92OE2rL7vEjEp494xZxq46ETvpPio/JpzOMsG5fRy07HYhUGjJ0enUytDhsZDikE QAN8V8X1yEXUnP4tkp8U1KpBjdau4xOVoz+Jj4JfaT9RmWUFg+RX7duOxpNLhIVplunOvo79vzX thyCKDjg1ffrkQyECUI2W4q1bPxonBFydjNCnNU38nj5ruvG3eT5/y5Z5aMQhnmrHePIsxZAFkD p6E4MgOA5BiGEtdjRst3cgUN2m0KTEoucPEPUFgPrHfvNRKq1gSTsIZ/xmPZVe/zdDu7MdMougU 88y5U0dUG4m+8NLOP1wK0MmNSqVsbgvRVaDs9K2NfFVahRC9eks4JhdNuw6X8Ka2dE8dTJ0b3y4 Ekh+C+nACZyJ2/J+etCbr0rqGGSWaVzJzxYXCdIODIHb5wtkT80gRf1YoLfW09mxIECNcTU+EBb T1WP9YHRbRz25J+f5dGGcr X-Received: by 2002:a05:600c:e547:20b0:490:b58b:a8ca with SMTP id 5b1f17b1804b1-490ec50c366mr24147355e9.27.1781268492311; Fri, 12 Jun 2026 05:48:12 -0700 (PDT) Received: from localhost ([195.94.146.6]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f2c4240sm5705651f8f.27.2026.06.12.05.48.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2026 05:48:11 -0700 (PDT) From: Andrea della Porta X-Google-Original-From: Andrea della Porta Date: Fri, 12 Jun 2026 14:51:33 +0200 To: Nicolai Buchwitz Cc: Andrea della Porta , netdev@vger.kernel.org, Theo Lebrun , Nicolas Ferre , Claudiu Beznea , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, Lukasz Raczylo , Steffen Jaeckel Subject: Re: [PATCH] net: macb: add TX stall timeout callback to recover from lost TSTART write Message-ID: References: <771b8faeaee1fce4a84a5ba2661d60b35a65a6d5.1781253818.git.andrea.porta@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Nicolai, On 14:23 Fri 12 Jun , Nicolai Buchwitz wrote: > Hi Andrea > > On 12.6.2026 11:01, Andrea della Porta wrote: > > From: Lukasz Raczylo > > > > The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on > > the TX queue. > > While the exact root cause is not yet fully understood, it is likely > > related to a hardware issue where a TSTART write to the NCR register > > is missed, preventing the transmission from being kicked off. > > > > Implement a timeout callback to handle TX queue stalls, triggering the > > existing restart mechanism to recover. > > > > Link: > > https://lore.kernel.org/all/20260514215459.36109-1-lukasz@raczylo.com/ > > Fixes: dc110d1b23564 ("net: cadence: macb: Add support for Raspberry Pi > > RP1 ethernet controller") > > Signed-off-by: Lukasz Raczylo > > Co-developed-by: Steffen Jaeckel > > Signed-off-by: Steffen Jaeckel > > Co-developed-by: Andrea della Porta > > Signed-off-by: Andrea della Porta > > --- > > drivers/net/ethernet/cadence/macb_main.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/net/ethernet/cadence/macb_main.c > > b/drivers/net/ethernet/cadence/macb_main.c > > index a12aa21244e83..615da65d5d68d 100644 > > --- a/drivers/net/ethernet/cadence/macb_main.c > > +++ b/drivers/net/ethernet/cadence/macb_main.c > > @@ -4522,6 +4522,16 @@ static int macb_setup_tc(struct net_device *dev, > > enum tc_setup_type type, > > } > > } > > > > +static void macb_tx_timeout(struct net_device *dev, unsigned int q) > > +{ > > + struct macb *bp = netdev_priv(dev); > > + > > + if (net_ratelimit()) > > Do we need the net_ratelimit() check (and message) here? AFAIU the watchdog > core already prints a message for every timeout. Correct. I'll drop those two lines. > > > + netdev_err(dev, "TX stall detected, re-kicking TSTART\n"); > > + dev->stats.tx_errors++; > > + macb_tx_restart(&bp->queues[q]); > > +} > > + > > static const struct net_device_ops macb_netdev_ops = { > > .ndo_open = macb_open, > > .ndo_stop = macb_close, > > @@ -4540,6 +4550,7 @@ static const struct net_device_ops macb_netdev_ops > > = { > > .ndo_hwtstamp_set = macb_hwtstamp_set, > > .ndo_hwtstamp_get = macb_hwtstamp_get, > > .ndo_setup_tc = macb_setup_tc, > > + .ndo_tx_timeout = macb_tx_timeout, > > The commit message describes it as RP1 specific, but it gets applied to all > other variants? I've seen this issue happening only on RaspberryPi 5, but AFAIK it could affect also other MACB blocks connected through PCIe, so it may be widespread (even though it should have probably already been noticed in the past). In the orginal driver there's no timeout callback defined and this is much like pretgending the issue causing the timeout to happen to go away without doing anything (whatever the cause ot the specific hw are). So in my opinion we can just extend that to all MACB. Or maybe we should execute the restart conditionally on .compatible = "raspberrypi,rp1-gem"? Thanks, Andrea > > > }; > > > > /* Configure peripheral capabilities according to device tree > > Thanks > Nicolai