From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3D33F2FD1DD; Tue, 30 Sep 2025 15:11:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759245103; cv=none; b=TDMFep1c0XieR/0hTlXsI+P3tb079L65oC2ki5fJTjCdlCFOJlLIgAnHNGnJGEUyTLQmuJA3ZM3VYAUgt2iDZLLgL+7FEYTbfIfKSwC/gyrkHHXi4gQYlu3lFQAzZuqiR1+3x88O3gBgpfDlCZj92QwPCIrepMhu08BU5rDsC8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759245103; c=relaxed/simple; bh=LpH7Atfa1HyxORtKkPswUHIj5ZVMESq2ZgWb1DkqAuQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kn++NA1Q1uzPcrhW4Q7EOR6+0ux4i7lbt49+Ok/SB6YSZmYyNSiuAfjS0WXEhVcOCKgHmBScsXTkMSVJobl0s4F01yhUkcIvesDUW/2maoA2rj/mYyHtcTrkk70QQZBNj+8XyxFAIShk/eiDRf/amwwkqQ80i+vyRt1FQXRr5eg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=EML0QkaP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="EML0QkaP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7605C113D0; Tue, 30 Sep 2025 15:11:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1759245103; bh=LpH7Atfa1HyxORtKkPswUHIj5ZVMESq2ZgWb1DkqAuQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EML0QkaPFU0cqyZ35Z2PeIWf0tjup8pkoa21vFjg+xldoY/xbSj0M+Ars9Ts5A4hi B7vnD7EPcMycEPADqheI8Se6TlQnBYhtve1ldkAMm8CwZv68R5j8QPoEF+n1VNW5nf C251nxGw8apDPIepXhdoQxmPpMymaLJ5Sd0m7vPM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ioana Ciornei , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.15 070/151] dpaa2-switch: fix buffer pool seeding for control traffic Date: Tue, 30 Sep 2025 16:46:40 +0200 Message-ID: <20250930143830.386428778@linuxfoundation.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20250930143827.587035735@linuxfoundation.org> References: <20250930143827.587035735@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ioana Ciornei [ Upstream commit 2690cb089502b80b905f2abdafd1bf2d54e1abef ] Starting with commit c50e7475961c ("dpaa2-switch: Fix error checking in dpaa2_switch_seed_bp()"), the probing of a second DPSW object errors out like below. fsl_dpaa2_switch dpsw.1: fsl_mc_driver_probe failed: -12 fsl_dpaa2_switch dpsw.1: probe with driver fsl_dpaa2_switch failed with error -12 The aforementioned commit brought to the surface the fact that seeding buffers into the buffer pool destined for control traffic is not successful and an access violation recoverable error can be seen in the MC firmware log: [E, qbman_rec_isr:391, QBMAN] QBMAN recoverable event 0x1000000 This happens because the driver incorrectly used the ID of the DPBP object instead of the hardware buffer pool ID when trying to release buffers into it. This is because any DPSW object uses two buffer pools, one managed by the Linux driver and destined for control traffic packet buffers and the other one managed by the MC firmware and destined only for offloaded traffic. And since the buffer pool managed by the MC firmware does not have an external facing DPBP equivalent, any subsequent DPBP objects created after the first DPSW will have a DPBP id different to the underlying hardware buffer ID. The issue was not caught earlier because these two numbers can be identical when all DPBP objects are created before the DPSW objects are. This is the case when the DPL file is used to describe the entire DPAA2 object layout and objects are created at boot time and it's also true for the first DPSW being created dynamically using ls-addsw. Fix this by using the buffer pool ID instead of the DPBP id when releasing buffers into the pool. Fixes: 2877e4f7e189 ("staging: dpaa2-switch: setup buffer pool and RX path rings") Signed-off-by: Ioana Ciornei Link: https://patch.msgid.link/20250910144825.2416019-1-ioana.ciornei@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c index 6448e06dcf826..1e6b29c047710 100644 --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c @@ -2682,7 +2682,7 @@ static int dpaa2_switch_setup_dpbp(struct ethsw_core *ethsw) dev_err(dev, "dpsw_ctrl_if_set_pools() failed\n"); goto err_get_attr; } - ethsw->bpid = dpbp_attrs.id; + ethsw->bpid = dpbp_attrs.bpid; return 0; -- 2.51.0