Message ID | 20240123095006.979437-1-0x1207@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-35042-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp225007dyi; Tue, 23 Jan 2024 01:53:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IEAcuzjwmzHZIEf2ftugVQzszJMWMxbF7aT1UQdc3YS9h1nzJU6PeQ9S8ZMfcuTSA6b3C4r X-Received: by 2002:a05:6214:d06:b0:681:9748:8702 with SMTP id 6-20020a0562140d0600b0068197488702mr610467qvh.58.1706003603492; Tue, 23 Jan 2024 01:53:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706003603; cv=pass; d=google.com; s=arc-20160816; b=wcWaaZhsnFDUmp/QE+YudNKx5723A9+HRiYsJzJPQhF6XyOa66dOLQGhzhS6M9iRmn RZlBB8RyxyT7aGHEK41kKLvxw+cXZgp+2UaRQOT//+mvHinTXOwluUM+Om5YJ4E/icgT kKTNV+PGzuNywEDXvbjdmAQTHSaFORgkfaNDbgFZipEhr/WZw6iH2yVH7htDAB0LyZeV bimDPcURx0U6+m9H0U8npbYeb3VOKhFHot5PMfG3GBH7FJRfE/pjGKyG/S6+lQuoQpWX yx8PdfbqreK0ZAfe+dTFGDPhT3IQ+nzmfQjBc4dZ2Qn0hwFdZMWgWab12LPVmjIDYLkL jwIg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=PB92u9IW1i3UPi9lwUSJ6To660URrQExv6UFr5Kbu60=; fh=lNbqm66A/wpozhFc+nLwOwrPosFlY20hAnN9jlxMS5I=; b=Zn9IgWYKL9FoBsqFr34nuDrRYj/IkqQBsT6E7YGcPhwHTqysK6dLz/a0A60+Ci42wN MdduA/x4ebKY/VY+oA2UEM4rRz334TYnRf06ATExeXEg4cbA8wSrhMTeux2F5q49kCcB dFHRsngXTy7+4so2sq3tk/8xmYOUp7q9YRNPoIEY6AYXAyzdXnybRnYmoeQvnNnd5LfC Tp4r2z+gb4ZUtM8fM1W0hk0dSPRLbWnU2GDPrbY8bLltErIbPoW3WDvG39aWE7s0FG4Q U/FkJHDwj1W6YipbpX5k93ycOcfVIMI/aj+L2K/U4N18P73Ryp+H7N/Lz/V/OkIKYGjO /Mkw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="e+Q/MKVU"; arc=pass (i=1 spf=pass spfdomain=gmail.com dkim=pass dkdomain=gmail.com dmarc=pass fromdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-35042-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-35042-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id e26-20020a0caa5a000000b00683ffc30b06si7530148qvb.269.2024.01.23.01.53.23 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 01:53:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-35042-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="e+Q/MKVU"; arc=pass (i=1 spf=pass spfdomain=gmail.com dkim=pass dkdomain=gmail.com dmarc=pass fromdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-35042-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-35042-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4AC471C22BE1 for <ouuuleilei@gmail.com>; Tue, 23 Jan 2024 09:53:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8C6A25EE81; Tue, 23 Jan 2024 09:50:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e+Q/MKVU" Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 2DCCA5C90E; Tue, 23 Jan 2024 09:50:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706003425; cv=none; b=MWoRw5BhT8cM2CQxCLYV9/UrLOKqIpj8E//Qzit2Xgq0O2wJwJJS9Aks5iI6T8sw8yyDyycrpnjCWpHZr+RCsiFVSByXywQFWuQynV1ylBncfUng4GXZVErPy64PFBCGiwUhxXINGvdUMyJ6rdHRrqzeFLzcxIeifwTZ4fhr0Eo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706003425; c=relaxed/simple; bh=mgeZFk1nt8TaMRKGQpVuxzk3SGlZGmEO4300G5Tg2kw=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=cqgojLzk0kmZGaQqTNNyhw/6g0m1kTDrBZ10LejrJ/tSJQTjH7d0kZFdgBZ95tUyaw8CtDgdHKSP4ORTZd2D11kE4zpByPq1Lw2W7Zow4iBxX7e4thk9xv1jnLwWWrF5yjXPAtqiDlw07HvPLROwn/jkRrjgurk55yM00PRgNYI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=e+Q/MKVU; arc=none smtp.client-ip=209.85.167.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-3bba50cd318so4220087b6e.0; Tue, 23 Jan 2024 01:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706003421; x=1706608221; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PB92u9IW1i3UPi9lwUSJ6To660URrQExv6UFr5Kbu60=; b=e+Q/MKVUa/3OhvDaFkl2wXv1JxLeQMYfGtLlMVyK+JTFxiaIU6VPvCYJpiVWNBjcF9 aUywdUQ2qW9EBqE5G8j3jpdgx1xT3hjt7xFuqA6hUfi0DyWSDipf4HKp5aUIuvrGa85D vd30f3PArALA4fcFHKmRA17Tk2OXIFn1hIEgQ1t24M1XX9xZIVGjf8Jf0TJAGHs6dXJM 50pgsFePzaKkfaTP33AJ0MMsF8XlZPT5rys3y1dqk/pZ3G/NAaj73V5BpEe4ay+WHMwT pmAkEN/e0ibcTlOd01UwDjMSH4e8+NQzIbfffUph7ubWeioE+fDjSF1RboKR7xElTEZT EQOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706003421; x=1706608221; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PB92u9IW1i3UPi9lwUSJ6To660URrQExv6UFr5Kbu60=; b=MutXdlFykJwzy1pWI3YhxhFIQ+pRIi/JLP/DGzsueOihIxysVAWC4m9Nuq/6+2OZgX rw7aWiMgXshT2BQHsoTFl69+teyFBxjI1AyYp5dAsljEzdW3GLPB+AfcYwf+0De1BBEe rscixxCRtNFxdPTG6Vbo22H6iZGAeUwQyGJc5wUHzA0jRyoHJduYC+R/MSv3SJd9jb8j kUPTd4z85k5j5QEbc8KZI0Meb4348pBZJKVwEZ/XQKD97okJzDyViQugpO/D5aRAWa3Z kiXt2xGyx1cY4rT8tonkKaPy0OKpy+gZRC553j0nj84BTz+qbby2L1Tr1SoIE3zpD3GZ N3HA== X-Gm-Message-State: AOJu0YxjhqL94NxoFZvYXw3Wb6zNp555P4ul9+1ANyjkGTqiM1xF2SFt Yxq6f92N1Iwtf8eX7ht0OKcMRJEgb3LlchfnJJ+CoWY6ikJQiDun X-Received: by 2002:a05:6808:1a17:b0:3bd:c43b:f935 with SMTP id bk23-20020a0568081a1700b003bdc43bf935mr1051159oib.9.1706003420915; Tue, 23 Jan 2024 01:50:20 -0800 (PST) Received: from localhost.localdomain ([112.65.140.130]) by smtp.googlemail.com with ESMTPSA id lp4-20020a056a003d4400b006dce766903dsm1325482pfb.90.2024.01.23.01.50.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 01:50:20 -0800 (PST) From: Furong Xu <0x1207@gmail.com> To: "David S. Miller" <davem@davemloft.net>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Joao Pinto <jpinto@synopsys.com>, Simon Horman <horms@kernel.org> Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xfr@outlook.com, rock.xu@nio.com, Furong Xu <0x1207@gmail.com> Subject: [PATCH net] net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Date: Tue, 23 Jan 2024 17:50:06 +0800 Message-Id: <20240123095006.979437-1-0x1207@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788874434699517223 X-GMAIL-MSGID: 1788874434699517223 |
Series |
[net] net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
|
|
Commit Message
Furong Xu
Jan. 23, 2024, 9:50 a.m. UTC
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
XGMAC core") checks and reports safety errors, but leaves the
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
a storm of interrupt.
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core")
Signed-off-by: Furong Xu <0x1207@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 ++++++
2 files changed, 7 insertions(+)
Comments
On Tue, Jan 23, 2024 at 05:50:06PM +0800, Furong Xu wrote: > Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in > XGMAC core") checks and reports safety errors, but leaves the > Data Path Parity Errors for each channel in DMA unhandled at all, lead to > a storm of interrupt. > Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. > > Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") > Signed-off-by: Furong Xu <0x1207@gmail.com> > --- > drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 + > drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 ++++++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > index 207ff1799f2c..188e11683136 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > @@ -385,6 +385,7 @@ > #define XGMAC_DCEIE BIT(1) > #define XGMAC_TCEIE BIT(0) > #define XGMAC_DMA_ECC_INT_STATUS 0x0000306c > +#define XGMAC_DMA_DPP_INT_STATUS 0x00003074 > #define XGMAC_DMA_CH_CONTROL(x) (0x00003100 + (0x80 * (x))) > #define XGMAC_SPH BIT(24) > #define XGMAC_PBLx8 BIT(16) > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > index eb48211d9b0e..874e85b499e2 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > @@ -745,6 +745,12 @@ static void dwxgmac3_handle_mac_err(struct net_device *ndev, > > dwxgmac3_log_error(ndev, value, correctable, "MAC", > dwxgmac3_mac_errors, STAT_OFF(mac_errors), stats); > + > + value = readl(ioaddr + XGMAC_DMA_DPP_INT_STATUS); > + writel(value, ioaddr + XGMAC_DMA_DPP_INT_STATUS); > + > + if (value) > + netdev_err(ndev, "Found DMA_DPP error, status: 0x%x\n", value); 1. Why not to implement this in the same way as the rest of the safety errors handle code? (with the flags described by the dwxgmac3_error_desc-based table and the respective counters being incremented should the errors were detected) 2. I don't see this IRQ being enabled in the dwxgmac3_safety_feat_config() method. How come the respective event has turned to be triggered anyway? -Serge(y) > } > > static const struct dwxgmac3_error_desc dwxgmac3_mtl_errors[32]= { > -- > 2.34.1 > >
On Wed, 24 Jan 2024 17:36:10 +0300 Serge Semin <fancer.lancer@gmail.com> wrote: > On Tue, Jan 23, 2024 at 05:50:06PM +0800, Furong Xu wrote: > > Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in > > XGMAC core") checks and reports safety errors, but leaves the > > Data Path Parity Errors for each channel in DMA unhandled at all, lead to > > a storm of interrupt. > > Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. > > > > Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") > > Signed-off-by: Furong Xu <0x1207@gmail.com> > > --- > > drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 + > > drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 ++++++ > > 2 files changed, 7 insertions(+) > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > index 207ff1799f2c..188e11683136 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > @@ -385,6 +385,7 @@ > > #define XGMAC_DCEIE BIT(1) > > #define XGMAC_TCEIE BIT(0) > > #define XGMAC_DMA_ECC_INT_STATUS 0x0000306c > > +#define XGMAC_DMA_DPP_INT_STATUS 0x00003074 > > #define XGMAC_DMA_CH_CONTROL(x) (0x00003100 + (0x80 * (x))) > > #define XGMAC_SPH BIT(24) > > #define XGMAC_PBLx8 BIT(16) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > index eb48211d9b0e..874e85b499e2 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > @@ -745,6 +745,12 @@ static void dwxgmac3_handle_mac_err(struct net_device *ndev, > > > > dwxgmac3_log_error(ndev, value, correctable, "MAC", > > dwxgmac3_mac_errors, STAT_OFF(mac_errors), stats); > > + > > + value = readl(ioaddr + XGMAC_DMA_DPP_INT_STATUS); > > + writel(value, ioaddr + XGMAC_DMA_DPP_INT_STATUS); > > + > > + if (value) > > + netdev_err(ndev, "Found DMA_DPP error, status: 0x%x\n", value); > > 1. Why not to implement this in the same way as the rest of the safety > errors handle code? (with the flags described by the > dwxgmac3_error_desc-based table and the respective counters being > incremented should the errors were detected) > XGMAC_DMA_DPP_INT_STATUS is just a bitmap of DMA RX and TX channels, bottom 16 bits for 16 DMA TX channels and top 16 bits for 16 DMA RX channels. No other descriptions. And the counters should be updated, I will send a new patch. > 2. I don't see this IRQ being enabled in the dwxgmac3_safety_feat_config() > method. How come the respective event has turned to be triggered > anyway? This error report is enabled by default, and cannot be disabled or marked(as Synopsys Databook says). What we can do is clearing it when it asserts. > > -Serge(y) > > > } > > > > static const struct dwxgmac3_error_desc dwxgmac3_mtl_errors[32]= { > > -- > > 2.34.1 > > > >
On Thu, Jan 25, 2024 at 10:56:20AM +0800, Furong Xu wrote: > On Wed, 24 Jan 2024 17:36:10 +0300 > Serge Semin <fancer.lancer@gmail.com> wrote: > > > On Tue, Jan 23, 2024 at 05:50:06PM +0800, Furong Xu wrote: > > > Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in > > > XGMAC core") checks and reports safety errors, but leaves the > > > Data Path Parity Errors for each channel in DMA unhandled at all, lead to > > > a storm of interrupt. > > > Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. > > > > > > Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") > > > Signed-off-by: Furong Xu <0x1207@gmail.com> > > > --- > > > drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 + > > > drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 ++++++ > > > 2 files changed, 7 insertions(+) > > > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > > index 207ff1799f2c..188e11683136 100644 > > > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > > @@ -385,6 +385,7 @@ > > > #define XGMAC_DCEIE BIT(1) > > > #define XGMAC_TCEIE BIT(0) > > > #define XGMAC_DMA_ECC_INT_STATUS 0x0000306c > > > +#define XGMAC_DMA_DPP_INT_STATUS 0x00003074 > > > #define XGMAC_DMA_CH_CONTROL(x) (0x00003100 + (0x80 * (x))) > > > #define XGMAC_SPH BIT(24) > > > #define XGMAC_PBLx8 BIT(16) > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > > index eb48211d9b0e..874e85b499e2 100644 > > > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > > @@ -745,6 +745,12 @@ static void dwxgmac3_handle_mac_err(struct net_device *ndev, > > > > > > dwxgmac3_log_error(ndev, value, correctable, "MAC", > > > dwxgmac3_mac_errors, STAT_OFF(mac_errors), stats); > > > + > > > + value = readl(ioaddr + XGMAC_DMA_DPP_INT_STATUS); > > > + writel(value, ioaddr + XGMAC_DMA_DPP_INT_STATUS); > > > + > > > + if (value) > > > + netdev_err(ndev, "Found DMA_DPP error, status: 0x%x\n", value); > > > > 1. Why not to implement this in the same way as the rest of the safety > > errors handle code? (with the flags described by the > > dwxgmac3_error_desc-based table and the respective counters being > > incremented should the errors were detected) > > > XGMAC_DMA_DPP_INT_STATUS is just a bitmap of DMA RX and TX channels, > bottom 16 bits for 16 DMA TX channels and top 16 bits for 16 DMA RX channels. > No other descriptions. > > And the counters should be updated, I will send a new patch. Ok. I'll wait for this patch v2 then with the counters fixed. Please also note that you are adding the _DMA_ DPP events handling support. Thus the more suitable place for this change would be dwmac5_handle_dma_err(). > > > 2. I don't see this IRQ being enabled in the dwxgmac3_safety_feat_config() > > method. How come the respective event has turned to be triggered > > anyway? > This error report is enabled by default, and cannot be disabled or marked(as Synopsys Databook says). > What we can do is clearing it when it asserts. This sounds so strange that I can barely believe in it. The DW QoS Eth MTL DPP feature can be enabled/disabled, but the DW XGMAC DMA DPP can't? This doesn't look logical. What's the point in having a never maskable IRQ for not that much crucial but optional feature? Moreover DPP adds some data flow overhead. If we are sure that no problem with the device data paths, then it seems redundant to have it always enabled. So I guess it must be switchable. Are you completely sure it isn't? -Serge(y) > > > > -Serge(y) > > > > > } > > > > > > static const struct dwxgmac3_error_desc dwxgmac3_mtl_errors[32]= { > > > -- > > > 2.34.1 > > > > > > >
On Thu, 25 Jan 2024 22:07:15 +0300 Serge Semin <fancer.lancer@gmail.com> wrote: > On Thu, Jan 25, 2024 at 10:56:20AM +0800, Furong Xu wrote: > > On Wed, 24 Jan 2024 17:36:10 +0300 > > Serge Semin <fancer.lancer@gmail.com> wrote: > > > > > On Tue, Jan 23, 2024 at 05:50:06PM +0800, Furong Xu wrote: > > > > Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in > > > > XGMAC core") checks and reports safety errors, but leaves the > > > > Data Path Parity Errors for each channel in DMA unhandled at all, lead to > > > > a storm of interrupt. > > > > Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. > > > > > > > > Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") > > > > Signed-off-by: Furong Xu <0x1207@gmail.com> > > > > --- > > > > drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 + > > > > drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 ++++++ > > > > 2 files changed, 7 insertions(+) > > > > > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > > > index 207ff1799f2c..188e11683136 100644 > > > > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > > > > @@ -385,6 +385,7 @@ > > > > #define XGMAC_DCEIE BIT(1) > > > > #define XGMAC_TCEIE BIT(0) > > > > #define XGMAC_DMA_ECC_INT_STATUS 0x0000306c > > > > +#define XGMAC_DMA_DPP_INT_STATUS 0x00003074 > > > > #define XGMAC_DMA_CH_CONTROL(x) (0x00003100 + (0x80 * (x))) > > > > #define XGMAC_SPH BIT(24) > > > > #define XGMAC_PBLx8 BIT(16) > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > > > index eb48211d9b0e..874e85b499e2 100644 > > > > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c > > > > @@ -745,6 +745,12 @@ static void dwxgmac3_handle_mac_err(struct net_device *ndev, > > > > > > > > dwxgmac3_log_error(ndev, value, correctable, "MAC", > > > > dwxgmac3_mac_errors, STAT_OFF(mac_errors), stats); > > > > + > > > > + value = readl(ioaddr + XGMAC_DMA_DPP_INT_STATUS); > > > > + writel(value, ioaddr + XGMAC_DMA_DPP_INT_STATUS); > > > > + > > > > + if (value) > > > > + netdev_err(ndev, "Found DMA_DPP error, status: 0x%x\n", value); > > > > > > 1. Why not to implement this in the same way as the rest of the safety > > > errors handle code? (with the flags described by the > > > dwxgmac3_error_desc-based table and the respective counters being > > > incremented should the errors were detected) > > > > > > XGMAC_DMA_DPP_INT_STATUS is just a bitmap of DMA RX and TX channels, > > bottom 16 bits for 16 DMA TX channels and top 16 bits for 16 DMA RX channels. > > No other descriptions. > > > > And the counters should be updated, I will send a new patch. > > Ok. I'll wait for this patch v2 then with the counters fixed. Please > also note that you are adding the _DMA_ DPP events handling support. > Thus the more suitable place for this change would be > dwmac5_handle_dma_err(). > > > > > > 2. I don't see this IRQ being enabled in the dwxgmac3_safety_feat_config() > > > method. How come the respective event has turned to be triggered > > > anyway? > > This error report is enabled by default, and cannot be disabled or marked(as Synopsys Databook says). > > What we can do is clearing it when it asserts. > > This sounds so strange that I can barely believe in it. The DW QoS Eth > MTL DPP feature can be enabled/disabled, but the DW XGMAC DMA DPP > can't? This doesn't look logical. What's the point in having a never > maskable IRQ for not that much crucial but optional feature? Moreover > DPP adds some data flow overhead. If we are sure that no problem with > the device data paths, then it seems redundant to have it always > enabled. So I guess it must be switchable. Are you completely sure it > isn't? Sorry for my bad explanation. Double checked DMA_DPP error report path on my device. XGMAC DMA_DPP is enable by DDPP bit of MTL_DPP_Control. DDPP bit is default to 0(Data path Parity Protection is enabled). When DDPP bit is set to 1(Data path Parity Protection is disabled), no DMA_DPP interrupt is reported. Once DMA_DPP interrupt is reported, there is no control bit to disable it or mask it. DMA_DPP error is unrecoverable type, and unrecoverable error interrupt cannot be disabled or masked, this is a design(as Synopsys Databook says). A explicit ops on MTL_DPP_Control to clear DDPP bit can add to dwxgmac3_safety_feat_config to make code looks better. > > -Serge(y) > > > > > > > -Serge(y) > > > > > > > } > > > > > > > > static const struct dwxgmac3_error_desc dwxgmac3_mtl_errors[32]= { > > > > -- > > > > 2.34.1 > > > > > > > > > >
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h index 207ff1799f2c..188e11683136 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h @@ -385,6 +385,7 @@ #define XGMAC_DCEIE BIT(1) #define XGMAC_TCEIE BIT(0) #define XGMAC_DMA_ECC_INT_STATUS 0x0000306c +#define XGMAC_DMA_DPP_INT_STATUS 0x00003074 #define XGMAC_DMA_CH_CONTROL(x) (0x00003100 + (0x80 * (x))) #define XGMAC_SPH BIT(24) #define XGMAC_PBLx8 BIT(16) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c index eb48211d9b0e..874e85b499e2 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c @@ -745,6 +745,12 @@ static void dwxgmac3_handle_mac_err(struct net_device *ndev, dwxgmac3_log_error(ndev, value, correctable, "MAC", dwxgmac3_mac_errors, STAT_OFF(mac_errors), stats); + + value = readl(ioaddr + XGMAC_DMA_DPP_INT_STATUS); + writel(value, ioaddr + XGMAC_DMA_DPP_INT_STATUS); + + if (value) + netdev_err(ndev, "Found DMA_DPP error, status: 0x%x\n", value); } static const struct dwxgmac3_error_desc dwxgmac3_mtl_errors[32]= {