linux-kernel - Re: [PATCH 7/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: <4e21205e-0b09-496e-9d6f-9fe2c327c13a@oss.qualcomm.com>
Date: Mon, 29 Dec 2025 13:37:45 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: "Alex G." <mr.nuke.me@...il.com>, andersson@...nel.org
Cc: mathieu.poirier@...aro.org, krzk+dt@...nel.org,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/9] remoteproc: qcom_q6v5_wcss: support m3 firmware

On 12/23/25 9:35 PM, Alex G. wrote:
> On Friday, December 19, 2025 7:29:07 AM CST Konrad Dybcio wrote:
>> On 12/19/25 5:34 AM, Alexandru Gagniuc wrote:
>>> IPQ8074, IPQ6018, and IPQ9574 support an m3 firmware image in addtion
>>> to the q6 firmware. The firmware releases from qcom provide both q6
>>> and m3 firmware for these SoCs. Support loading the m3 firmware image.
>>>
>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@...il.com>
>>> ---

[...]

>>> +static int q6v5_wcss_load_aux(struct q6v5_wcss *wcss, const char
>>> *fw_name)
>>> +{
>>> +	const struct firmware *extra_fw;
>>> +	int ret;
>>> +
>>> +	dev_info(wcss->dev, "loading additional firmware image %s\n", 
> fw_name);

Your email client is messing up the reply context - if it happens to
be Thunderbird, set:

mailnews.wraplength = 0
mailnews.send_plaintext_flowed = false

in the config

>>
>> I don't think this log line is useful beyond development
> 
> Remoteproc driver prints the main (q6) fimrware name, so I thought it would be 
> prudent to print the names of any additional firmwares:
> 
>     remoteproc remoteproc0: Booting fw image IPQ9574/q6_fw.mdt, size 8140
> 
>>> +
>>> +	ret = request_firmware(&extra_fw, fw_name, wcss->dev);
>>> +	if (ret)
>>> +		return 0;
>>
>> return ret, perhaps? Unless you want to say that "it's fine if the M3 image
>> is missing, particularly not to impose any new requirements on existing
>> setups". But you haven't spelt that out explicitly.
> 
> I intended to not abort when aux firmware is missing. Maybe the better way to 
> handle this is to check for "-ENOENT" in the caller instead of return 0 here.
> 
>> You also haven't provided an explanation as to why the firmware should be
>> loaded. Is it necessary for some functionality? Is it that case on the
>> newly-supported IPQ9574?
> 
> I don't have a good answer. I reasoned that since the qcom provides it [1], 
> the M3 firmware would need to be loaded. I haven't done much testing without 
> it.

Well, could you please try?

IIRC it was strictly necessary for ATH1xk-on-PCIe so I'm assuming it's going
to be a necessity here as well 

Konrad