From: Gagandeep Singh <g.singh@nxp.com>
To: dev@dpdk.org
Cc: david.marchand@redhat.com, hemant.agrawal@nxp.com,
Gagandeep Singh <g.singh@nxp.com>
Subject: [PATCH v3 2/2] bus/dpaa: fix unneeded conditional in bman_release
Date: Tue, 27 Oct 2026 15:03:35 +0530 [thread overview]
Message-ID: <20261027093335.4109017-3-g.singh@nxp.com> (raw)
In-Reply-To: <20261027093335.4109017-1-g.singh@nxp.com>
bman_release() computed i = num - 1 before the num == 0 bounds check,
which only exists under RTE_LIBRTE_DPAA_HWDEBUG. With that debug flag
disabled and num == 0, i wraps to UINT32_MAX, and the subsequent
'if (i)' guard is then always taken regardless of num, relying on the
for loop's own bound to do nothing. The indirection added no value and
obscured the num == 0 handling.
Drop the i = num - 1 initializer and the if (i) wrapper, relying
solely on the for (i = 1; i < num; i++) loop condition, matching the
simpler pattern already used in bman_release_fast().
Fixes: f38f61e982f8 ("bus/dpaa: add BMAN hardware interfaces")
Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
---
drivers/bus/dpaa/base/qbman/bman.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/bman.c b/drivers/bus/dpaa/base/qbman/bman.c
index 76e612662f..31114b2d57 100644
--- a/drivers/bus/dpaa/base/qbman/bman.c
+++ b/drivers/bus/dpaa/base/qbman/bman.c
@@ -304,7 +304,7 @@ int bman_release(struct bman_pool *pool, const struct bm_buffer *bufs, u8 num,
{
struct bman_portal *p;
struct bm_rcr_entry *r;
- u32 i = num - 1;
+ u32 i;
u8 avail;
#ifdef RTE_LIBRTE_DPAA_HWDEBUG
@@ -329,11 +329,9 @@ int bman_release(struct bman_pool *pool, const struct bm_buffer *bufs, u8 num,
r->bufs[0].opaque =
cpu_to_be64(((u64)pool->params.bpid << 48) |
(bufs[0].opaque & MAX_U48));
- if (i) {
- for (i = 1; i < num; i++)
- r->bufs[i].opaque =
- cpu_to_be64(bufs[i].opaque & MAX_U48);
- }
+ for (i = 1; i < num; i++)
+ r->bufs[i].opaque =
+ cpu_to_be64(bufs[i].opaque & MAX_U48);
bm_rcr_pvb_commit(&p->p, BM_RCR_VERB_CMD_BPID_SINGLE |
(num & BM_RCR_VERB_BUFCOUNT_MASK));
--
2.25.1
prev parent reply other threads:[~2026-10-27 9:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 6:15 [PATCH] bus/dpaa: fix maybe-uninitialized in bman_release_fast Gagandeep Singh
2026-10-27 6:31 ` [PATCH v2 0/1] DPAA compilation fix ppc64le and riscv Gagandeep Singh
2026-10-27 6:31 ` [PATCH v2 1/1] bus/dpaa: fix maybe-uninitialized in bman_release_fast Gagandeep Singh
2026-10-27 7:48 ` David Marchand
2026-10-27 13:46 ` Stephen Hemminger
2026-10-27 9:33 ` [PATCH v3 0/2] DPAA compilation fix ppc64le and riscv Gagandeep Singh
2026-10-27 9:33 ` [PATCH v3 1/2] bus/dpaa: fix maybe-uninitialized in bman_release_fast Gagandeep Singh
2026-10-27 9:33 ` Gagandeep Singh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261027093335.4109017-3-g.singh@nxp.com \
--to=g.singh@nxp.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox