linux-kernel - Re: [PATCH] dt-bindings: remoteproc: qcom,adsp: Re-add cx-supply

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d81e017e-e317-402d-a4bf-7ddfa033299e@oss.qualcomm.com>
Date: Mon, 8 Dec 2025 17:33:00 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Luca Weiss <luca@...aweiss.eu>, Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Dzmitry Sankouski <dsankouski@...il.com>
Cc: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: remoteproc: qcom,adsp: Re-add cx-supply

On 12/7/25 11:35 AM, Luca Weiss wrote:
> Some boards (e.g. sdm845-samsung-starqltechn) provide a cx-supply
> reference for the SLPI PAS.
> 
> The Linux driver unconditionally tries getting "cx" and "px" supplies,
> so it actually is used.
> 
> Fixes: 3d447dcdae53 ("dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as power domain")
> Signed-off-by: Luca Weiss <luca@...aweiss.eu>
> ---
> There's literally one board using this upstream, judging from that I'm
> not sure this is a misuse of cx-supply or what exactly. An alternative
> to this patch is of course removing the usage in
> sdm845-samsung-starqltechn, but as it stands right now the patch under
> "Fixes" introduces a dtbs_check warning.

FWIW that's likely a hack (because IIUC it needs to power up some
regulator for the sensor devices to work) but that's "fine"

I don't know if there's a better way to handle it though.. I think it's
a board design "issue", since the DSP has access to some GPIOs but it
seems like that wasn't utilized

I'm open to suggestions

+Dzmitry-the-starqltechn-submitter

Konrad