From: Val Packett <val@packett.cool>
To: Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>
Cc: "Val Packett" <val@packett.cool>,
"Matti Lehtimäki" <matti.lehtimaki@gmail.com>,
"Luca Weiss" <luca@lucaweiss.eu>,
"Vladimir Lypak" <vladimir.lypak@gmail.com>,
"Barnabás Czémán" <barnabas.czeman@mainlining.org>,
"Konrad Dybcio" <konrad.dybcio@oss.qualcomm.com>,
"Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>,
~postmarketos/upstreaming@lists.sr.ht, linux@mainlining.org,
phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-remoteproc@vger.kernel.org, llvm@lists.linux.dev
Subject: [PATCH v2] remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3
Date: Sun, 1 Feb 2026 17:55:03 -0300 [thread overview]
Message-ID: <20260201210230.911220-1-val@packett.cool> (raw)
The changes introduced to handle single power domain platforms have
swapped the info pointer increment from num_pd_vregs to num_pds, which
would shift the info pointer past the end of the array for pronto-v3,
which does not list power domain regulators in vregs.
This showed up as a difference between GCC- and LLVM-compiled kernels
on SDM632 devices, where only with LLVM one would get the
"regulator request with no identifier" error, because the out-of-bounds
memory ended up being zeroed. Fix by skipping the increment when there
are more power domains than regulators.
Signed-off-by: Val Packett <val@packett.cool>
---
v2: changed to detect the >= condition suggested by Konrad
v1: https://lore.kernel.org/all/20260126235018.969140-1-val@packett.cool/
"possible_pds" is the best name I could come up with (as "num" is already
taken by the number of *successfully attached* PDs and "max" is the constant
for the array length) for the count we're checking against. Maybe the "num"
could be changed to "attached" but that feels like too much diff.
~val
---
drivers/remoteproc/qcom_wcnss.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index ee18bf2e8054..60f629b5bbed 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -441,25 +441,31 @@ static void wcnss_release_pds(struct qcom_wcnss *wcnss)
}
static int wcnss_init_regulators(struct qcom_wcnss *wcnss,
- const struct wcnss_vreg_info *info,
- int num_vregs, int num_pd_vregs)
+ const struct wcnss_data *data)
{
+ const struct wcnss_vreg_info *info = data->vregs;
struct regulator_bulk_data *bulk;
+ size_t i, possible_pds = 0, num_vregs = data->num_vregs;
int ret;
- int i;
+
+ for (i = 0; i < WCNSS_MAX_PDS; i++)
+ if (data->pd_names[i])
+ possible_pds++;
/*
* If attaching the power domains suceeded we can skip requesting
* the regulators for the power domains. For old device trees we need to
* reserve extra space to manage them through the regulator interface.
*/
- if (wcnss->num_pds) {
+ if (possible_pds >= num_vregs) {
+ /* Do nothing if vregs do not include PD regulators (pronto-v3) */
+ } else if (wcnss->num_pds) {
info += wcnss->num_pds;
/* Handle single power domain case */
- if (wcnss->num_pds < num_pd_vregs)
- num_vregs += num_pd_vregs - wcnss->num_pds;
+ if (wcnss->num_pds < data->num_pd_vregs)
+ num_vregs += data->num_pd_vregs - wcnss->num_pds;
} else {
- num_vregs += num_pd_vregs;
+ num_vregs += data->num_pd_vregs;
}
bulk = devm_kcalloc(wcnss->dev,
@@ -607,8 +613,7 @@ static int wcnss_probe(struct platform_device *pdev)
if (ret && (ret != -ENODATA || !data->num_pd_vregs))
return ret;
- ret = wcnss_init_regulators(wcnss, data->vregs, data->num_vregs,
- data->num_pd_vregs);
+ ret = wcnss_init_regulators(wcnss, data);
if (ret)
goto detach_pds;
--
2.52.0
next reply other threads:[~2026-02-01 21:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-01 20:55 Val Packett [this message]
2026-02-02 10:57 ` [PATCH v2] remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3 Konrad Dybcio
2026-02-23 20:03 ` Bjorn Andersson
2026-02-24 18:45 ` Val Packett
2026-02-27 3:52 ` Bjorn Andersson
2026-02-27 4:20 ` Val Packett
-- strict thread matches above, loose matches on Subject: below --
2026-02-09 23:05 Yoann Lecuyer
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=20260201210230.911220-1-val@packett.cool \
--to=val@packett.cool \
--cc=andersson@kernel.org \
--cc=barnabas.czeman@mainlining.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=justinstitt@google.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux@mainlining.org \
--cc=llvm@lists.linux.dev \
--cc=luca@lucaweiss.eu \
--cc=mathieu.poirier@linaro.org \
--cc=matti.lehtimaki@gmail.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=phone-devel@vger.kernel.org \
--cc=vladimir.lypak@gmail.com \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/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