linux-kernel - Re: [PATCH 6/9] remoteproc: qcom_q6v5

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] [day] [month] [year] [list]

Message-ID: <7564740.MhkbZ0Pkbq@nukework.gtech>
Date: Wed, 24 Dec 2025 11:36:15 -0600
From: "Alex G." <mr.nuke.me@...il.com>
To: andersson@...nel.org, mathieu.poirier@...aro.org,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>, linux-kernel@...r.kernel.org,
 Vignesh Viswanathan <vignesh.viswanathan@....qualcomm.com>
Cc: krzk+dt@...nel.org, Philipp Zabel <p.zabel@...gutronix.de>,
 linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH 6/9] remoteproc: qcom_q6v5_wcss: support IPQ9574

On Wednesday, December 24, 2025 3:44:56 AM CST Vignesh Viswanathan wrote:
> On 12/24/2025 1:51 AM, Alex G. wrote:
> > On Friday, December 19, 2025 7:20:04 AM CST Konrad Dybcio wrote:
> >> On 12/19/25 5:34 AM, Alexandru Gagniuc wrote:
> >>> Q6 based firmware loading is also present on IPQ9574, when coupled
> >>> with a wifi-6 device, such as QCN5024. Populate driver data for
> >>> IPQ9574 with values from the downstream 5.4 kerrnel.
> >>> 
> >>> Add the new sequences for the WCSS reset and stop. The downstream
> >>> 5.4 kernel calls these "Q6V7", so keep the name. This is still worth
> >>> using with the "q6v5" driver because all other parts of the driver
> >>> can be seamlessly reused.
> >>> 
> >>> The IPQ9574 uses two sets of clocks. the first, dubbed "q6_clocks"
> >>> must be enabled before the Q6 is started by writing the Q6SS_RST_EVB
> >>> register. The second set of clocks, "clks" should only be enabled
> >>> after the Q6 is placed out of reset. Otherwise, the host CPU core that
> >>> tries to start the remoteproc will hang.
> >>> 
> >>> The downstream kernel had a funny comment, "Pray god and wait for
> >>> reset to complete", which I decided to keep for entertainment value.
> >>> 
> >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@...il.com>
> >>> ---
> >> 
> >> [...]
> >> 
> >>> @@ -128,6 +137,12 @@ struct q6v5_wcss {
> >>> 
> >>>  	struct clk *qdsp6ss_xo_cbcr;
> >>>  	struct clk *qdsp6ss_core_gfmux;
> >>>  	struct clk *lcc_bcr_sleep;
> >>> 
> >>> +	struct clk_bulk_data *clks;
> >>> +	/* clocks that must be started before the Q6 is booted */
> >>> +	struct clk_bulk_data *q6_clks;
> >> 
> >> "pre_boot_clks" or something along those lines?
> > 
> > I like "pre_boot_clocks".
> > 
> >> In general i'm not super stoked to see another platform where manual and
> >> through-TZ bringup of remoteprocs is supposed to be supported in
> >> parallel..
> >> 
> >> Are you sure your firmware doesn't allow you to just do a simple
> >> qcom_scm_pas_auth_and_reset() like in the multipd series?
> > 
> > I am approaching this from the perspective of an aftermarket OS, like
> > OpenWRT. I don't know if the firmware will do the right thing. I can
> > mitigate this for OS-loaded firmware, like ath11k 16/m3 firmware, because
> > I can test the driver and firmware together. I can't do that for
> > bootloader-loaded firmware, so I try to depend on it as little as
> > possible. I hope that native remoterproc loading for IPQ9574 will be
> > allowed.

Hi Vignesh,

> Does this rproc start sequence work on IPQ9574 without using the
> qcom_scm_pas_auth_and_reset ?

Yes, it works as presented in this series, without 
qcom_scm_pas_auth_and_reset().

Alex