On 1/5/26 4:23 PM, [email protected] wrote: > > > On 12/29/25 6:37 AM, Konrad Dybcio wrote: >> 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 <[email protected]> >>>>> --- >> >> [...] >> >>>>> +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 > > Oops. >>>> >>>> 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 > > I tried this without the M3 firmware, and I don't see a measurable difference > in normal operation. I only tested AP mode briefly. How can I know for sure > if the M3 firmware is needed or not?
Without knowing more, I would assume M3 means "a Cortex-M3-based [power] management MCU" without which the thing wouldn't start up.. Konrad
