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

Message-ID: <7f6754a4-4a3b-4b6f-9220-a1790a9ba393@gmail.com>
Date: Mon, 5 Jan 2026 10:09:19 -0600
From: mr.nuke.me@...il.com
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, andersson@...nel.org,
 mathieu.poirier@...aro.org, linux-kernel@...r.kernel.org
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 12/29/25 6:35 AM, Konrad Dybcio wrote:
> On 12/23/25 9:21 PM, 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.
> 
> These are two parallel questions. I didn't even know that the bootloader
> preloaded firmware on these platforms (are you sure that's the case?)
> 
> qcom_scm_pas_auth_and_reset() is usually preceded by qcom_mdt_pas_init() +
> qcom_mdt_load_no_init() where *you* supply the loadable firmware for the
> remote processor.

What I mean is that the init sequence is implemented in the trustzone 
firmware which is loaded at boot time. Irrespective of what Q6 and M3 
firmware I supply, if trustzone doesn't cooperate, I can't start the 
remoteproc. I don't have that problem when the init sequence is 
implemented in the kernel.

> The init sequence provided by this interface will be at worst identical to
> what you're proposing here (except abstracted out), and at best containing
> some fixes and/or workarounds that may be necessary.

I think this portrays the TZ path as somehow superior. That's not how 
things work in my use casee.

The bootloader/FW versions depends on when and who made the device. So 
while the newest TZ from upstream may have the latest fixes, I have no 
guarantee that they will be present on a given device at runtime. The 
best solution I found to get consistent behavior across devices is to do 
these sequences from the kernel. Is there something incomplete in my 
init sequence that I can fix?

  > Please try using PAS and see if that works.

I found the v6 of the multipd series [1]. It needed some minor 
adjustments to compile. I went as far as loading the Q6 firmware and 
starting the remoteproc without error. I did not test any further.

Alex

[1] 
https://patchwork.kernel.org/project/linux-remoteproc/patch/20231110091939.3025413-1-quic_mmanikan@quicinc.com/