From: sashiko-bot@kernel.org
To: "Richard Cheng" <icheng@nvidia.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v2 1/2] cxl/hdm: Allow zero sized HDM decoders
Date: Tue, 02 Jun 2026 05:57:34 +0000 [thread overview]
Message-ID: <20260602055735.6392E1F00893@smtp.kernel.org> (raw)
In-Reply-To: <c743dde11ad652a65b84d206085d09d7e56b9183.1779957270.git.icheng@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping devm_cxl_dpa_reserve() for zero-size decoders leaves port->hdm_end un-incremented, causing the out-of-order DPA allocation check to fail unconditionally for subsequent decoders.
--
commit 413b72f0366d77ee154e5fec85ab5deab385b5af
Author: Richard Cheng <icheng@nvidia.com>
cxl/hdm: Allow zero sized HDM decoders
This commit allows committing an HDM decoder with a size of 0 to support BIOS
configurations that burn slots for Trusted Computing Base devices. It sets
port->commit_end before checking for a zero size and skips
devm_cxl_dpa_reserve() for these decoders since they have no DPA range to
reserve.
> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c
> index 0c80b76a5f9b4..467ac45bee553 100644
> --- a/drivers/cxl/core/hdm.c
> +++ b/drivers/cxl/core/hdm.c
[ ... ]
> @@ -1096,6 +1095,10 @@ static int init_hdm_decoder(struct cxl_port *port, struct cxl_decoder *cxld,
> if (!committed)
> return 0;
>
> + /* Committed zero-size decoder has nothing to reserve in DPA. */
> + if (size == 0)
> + return 0;
> +
[Severity: High]
Does skipping devm_cxl_dpa_reserve() here prevent port->hdm_end from being
incremented for the zero-size decoder?
If port->hdm_end is not updated, won't subsequent decoders fail the DPA
reservation path?
drivers/cxl/core/hdm.c:__cxl_dpa_reserve() {
...
if (port->hdm_end + 1 != cxled->cxld.id) {
/*
* Assumes alloc and commit order is always in hardware instance
* order...
*/
dev_dbg(dev, "decoder%d.%d: expected decoder%d.%d\n", port->id,
cxled->cxld.id, port->id, port->hdm_end + 1);
return -EBUSY;
}
...
}
If a zero-size decoder (e.g. ID N) skips the reserve step, port->hdm_end stays
at N-1. When decoder N+1 tries to reserve DPA, port->hdm_end + 1 is N, which
does not match N+1, causing an unconditional -EBUSY.
> dpa_size = div_u64_rem(size, cxld->interleave_ways, &remainder);
> if (remainder) {
> dev_err(&port->dev,
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779957270.git.icheng@nvidia.com?part=1
next prev parent reply other threads:[~2026-06-02 5:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 5:40 [PATCH v2 0/2] Support zero-sized HDM decoders Richard Cheng
2026-06-02 5:40 ` [PATCH v2 1/2] cxl/hdm: Allow zero sized " Richard Cheng
2026-06-02 5:57 ` sashiko-bot [this message]
2026-06-04 2:56 ` Alison Schofield
2026-06-02 5:40 ` [PATCH v2 2/2] tools/testing/cxl: Enable zero sized decoders under hb0 Richard Cheng
2026-06-04 2:44 ` Alison Schofield
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=20260602055735.6392E1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=icheng@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.