From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FC8A383322 for ; Thu, 4 Jun 2026 08:48:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780562900; cv=none; b=rLMnlaECJjalOP6a4GpecVldqtnS7hU2LqkJO3oQqYvcIPSRxDDkK4nmIIx5v0XkTMxepptW59obN7O8SjXUimuiK5Gwbump1q9AxzxFNUnTr3CpRr87QkiKg1HvTjQSAYTfXYAxV1mkhTaKWBi7Au1vkvP8IEf7bGTWVJqB9J0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780562900; c=relaxed/simple; bh=ff1L/NMEv6IrgzuRMJul8C6mMqZeof/Dw+M6uv9veRM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Vt0DSAUMOonyQ0a6mWrtJg1uJEAqipQhWmxadYWqMQi/uciWfQpZ0Uz1EtpvYWHlXHloYl6QakCHYj+PQTttzgd8/VsCkeUEwxT4Qoopr7EFIsOIj0sHfjmnlMy/epzHfSQ1dFOcozmrCZxN6XcgRYhhsnLrmDurGtteRWVluAw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=djAY8CMF; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="djAY8CMF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780562897; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NLy2ui1zH+xe/yDG2eZDPsP5/IZUw8RGdjLB0ACLri4=; b=djAY8CMF/CmuG6ycETQylzCXJ/TQlre+hXfd7lSakCrcMJVTl1zp9p5TVlWHeT/gzcjTh1 Op4ERQ5sUfQdV+0wkHoHNJaDt6kVKRr1xzGSzbmbxUlDWY37hBVHNPKLIVV7RvS5olrOkb rSk4b/+9RO9FjzPdJJZzpZ39iAYRJIM= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-578-hhwUpmD1OMuYdnB4wQYmMA-1; Thu, 04 Jun 2026 04:48:13 -0400 X-MC-Unique: hhwUpmD1OMuYdnB4wQYmMA-1 X-Mimecast-MFC-AGG-ID: hhwUpmD1OMuYdnB4wQYmMA_1780562892 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0BEA0195608C; Thu, 4 Jun 2026 08:48:11 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.44.49.23]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A45151800361; Thu, 4 Jun 2026 08:48:06 +0000 (UTC) From: Paolo Abeni To: muhammad.nazim.amirul.nazle.asmade@altera.com Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, maxime.chevallier@bootlin.com, Jose.Abreu@synopsys.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Date: Thu, 4 Jun 2026 10:48:03 +0200 Message-ID: <20260604084803.67068-1-pabeni@redhat.com> In-Reply-To: <20260529071734.27722-1-muhammad.nazim.amirul.nazle.asmade@altera.com> References: <20260529071734.27722-1-muhammad.nazim.amirul.nazle.asmade@altera.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 From: AI Reviewer This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev/ --- net: stmmac: xgmac2: disable RBUE in default RX interrupt mask This commit removes the Receive Buffer Unavailable (RBUE) interrupt from the default RX and DMA interrupt masks. The goal is to prevent MAC interrupt storms when the DMA runs out of descriptors under heavy RX pressure. > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > index 51943705a2b03..b5fdc253a2f24 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h [ ... ] > @@ -379,9 +379,9 @@ > #define XGMAC_RIE BIT(6) > #define XGMAC_TBUE BIT(2) > #define XGMAC_TIE BIT(0) > -#define XGMAC_DMA_INT_DEFAULT_EN (XGMAC_NIE | XGMAC_AIE | XGMAC_RBUE | \ > +#define XGMAC_DMA_INT_DEFAULT_EN (XGMAC_NIE | XGMAC_AIE | \ > XGMAC_RIE | XGMAC_TIE) [Severity: Medium] Does removing XGMAC_RBUE from XGMAC_DMA_INT_DEFAULT_EN prevent the XGMAC_RBU status bit from being cleared in dwxgmac2_dma_interrupt()? If this default mask is used to clear pending interrupts, writing a 0 to the XGMAC_RBU position would fail to clear it. Would this cause the bit to latch indefinitely, triggering redundant NAPI schedules on unrelated abnormal interrupts? > -#define XGMAC_DMA_INT_DEFAULT_RX (XGMAC_RBUE | XGMAC_RIE) > +#define XGMAC_DMA_INT_DEFAULT_RX (XGMAC_RIE) [Severity: High] Does disabling RBUE entirely break RX out-of-memory recovery? If the RX ring becomes completely empty during memory pressure because stmmac_rx_refill() fails to allocate SKBs, the MAC DMA will suspend. Once a new packet arrives, the MAC drops it and sets the XGMAC_RBU status. Since RIE is only asserted when a packet is successfully received and transferred to a descriptor, and RBUE is now disabled, it appears no interrupt will fire at all in this state. Could this leave NAPI unscheduled and result in a permanent RX path lockup even after memory becomes available again? -- This is an AI-generated review.