Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4030776pxb; Mon, 8 Feb 2021 06:24:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJw937quvLxGaqmSdCNXe96I6MauuPtJ6itpCFynUMMij9sSSK4JTO650MQRJbC+1seukshK X-Received: by 2002:a17:906:2e06:: with SMTP id n6mr10862521eji.329.1612794282111; Mon, 08 Feb 2021 06:24:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612794282; cv=none; d=google.com; s=arc-20160816; b=VRnU8TSDaMWsLZvzCj5kTEGU7+qbSIahgPg4rMhPAenxy9qI2Kd2mSswc8Dr87DyyU 5nP7sI5pFGerAgomRaQ1ZCz0FC3l8EJrbmUdnJtzZc9os3MLKSMNjt1YEC9R8+ei58It I+7jwPxphZzL3dSajYqNvOASC1pN2KC3YzHdsXCSyfiX7HGpNA2xlzZgT55JOivnEhAr uVcUF7pBfvGLWSPzG1Cav4VrcQev/Pjoh2hBe2Nvx1hWGCZv50U3mZc9hhjqgf8VXdgK OxWIrqIgbFQCteyCiXNOUky9qFpxe4oabBvvB4JWIxhA1FXpCS0HE6yTQLR8khd+gVI+ kksg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Dn2tjRVCiIlt89GivQNloNkG4LCboAP+96ruNyInems=; b=ODQnuKgSGU1XNL6zVicwH7Na3ntno838kmr0xCJnt9EePbVCBu6biskfHH43MEkoD4 h0f3fFmE/N7IVjFANWdRYQ6XzZvQbG99CL7pfsewnw/QQy2IeRi6wQnFBjm0BIXuiLVJ sJh5wwIW0feusc+LABA0S1CcLluZASl2ZbyJM3rTMkt8gJAO9y4Eztg0iCz/JfadYz8B GMxkoqLf0pPB+OR8tZmkIf50LnOTMclUxAzEg/VTP5nUoIxLXpJTkIY553qWvif+aCBX A5BcqPyKyK6HIyveF1Yb2haIuCvWWxB7bOwZMkvAQ9nlw9hVLFn7HnZELBAVmE8r0nuD E0og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u23si13555460edi.71.2021.02.08.06.24.15; Mon, 08 Feb 2021 06:24:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232739AbhBHOWr (ORCPT + 99 others); Mon, 8 Feb 2021 09:22:47 -0500 Received: from mail.baikalelectronics.com ([87.245.175.226]:57234 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232698AbhBHOE2 (ORCPT ); Mon, 8 Feb 2021 09:04:28 -0500 From: Serge Semin To: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Jakub Kicinski , Joao Pinto , Jose Abreu , Maxime Coquelin CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Vyacheslav Mitrofanov , Russell King , Andrew Lunn , Heiner Kallweit , , , , Subject: [PATCH 03/20] net: stmmac: Fix false MTL RX overflow handling for higher queues Date: Mon, 8 Feb 2021 17:03:24 +0300 Message-ID: <20210208140341.9271-4-Sergey.Semin@baikalelectronics.ru> In-Reply-To: <20210208140341.9271-1-Sergey.Semin@baikalelectronics.ru> References: <20210208140341.9271-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Judging by the MAC/MTL-related part of the ISR implementation if MTL IRQs status handler returns MTL Rx overflow bit set, the stmmac_set_rx_tail_ptr() method will be called for all subsequent queues. That most likely isn't what we want. Fix it by just overriding the status variable on each loop iteration. Note we can freely break the loop at the very beginning if the stmmac_host_mtl_irq_status() method returns -EINVAL, because that error means the MTL IRQ status handler isn't available for the detected hardware. Fixes: 7bac4e1ec3ca ("net: stmmac: stmmac interrupt treatment prepared for multiple queues") Signed-off-by: Serge Semin --- Folks, I haven't seen an effect of that bug. The patch has been created purely based on the code visual perception. If you think the handler is supposed to work like that and I am missing something (though I have much doubt about that), just drop this patch. --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 5ee840525824..d45af1ea2565 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -4149,7 +4149,6 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id) /* To handle GMAC own interrupts */ if ((priv->plat->has_gmac) || xmac) { int status = stmmac_host_irq_status(priv, priv->hw, &priv->xstats); - int mtl_status; if (unlikely(status)) { /* For LPI we need to save the tx status */ @@ -4162,10 +4161,10 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id) for (queue = 0; queue < queues_count; queue++) { struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue]; - mtl_status = stmmac_host_mtl_irq_status(priv, priv->hw, - queue); - if (mtl_status != -EINVAL) - status |= mtl_status; + status = stmmac_host_mtl_irq_status(priv, priv->hw, + queue); + if (status == -EINVAL) + break; if (status & CORE_IRQ_MTL_RX_OVERFLOW) stmmac_set_rx_tail_ptr(priv, priv->ioaddr, -- 2.29.2