On 8/21/26 10:15, Paul Hollinsky wrote:
> Commit f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS
> TZ APIs") changed the probe-time gate for need_mem_protection platforms
> from qcom_scm_is_available() to qcom_pas_is_available(). Memory
> protection in this driver is implemented with qcom_scm_assign_mem(),
> which is a TZ service distinct from PAS. The only PAS call in the driver
> is qcom_pas_mem_setup(), and it is already guarded by need_pas_mem_setup.
Bjorn, will you send this fix for a 7.3 regression to Linus any time
soon? It's in -next for two weeks now as b853857293584d ("remoteproc:
qcom_q6v5_mss: Don't require PAS for memory protection") afaics, but
from the branch name it sounds like it might be queued for merging in
the next merge window.
Ciao, Thorsten
> No descriptor sets both flags: sc7180, sc7280, sdm660, sdm845, msm8996
> and msm8998 set need_mem_protection only, while msm8937, msm8940 and
> msm8953 set need_pas_mem_setup only. On TrustZone firmware that does not
> implement PAS - for example SC7180 Chromebooks, where call-availability
> queries report every QCOM_SCM_SVC_PIL command as unavailable - the modem
> consequently never probes:
>
> platform 4080000.remoteproc: deferred probe pending: (reason unknown)
>
> On those machines the modem is also what loads the WLAN firmware, so
> ath10k never receives QMI and wifi does not come up either.
>
> Gate memory protection on SCM availability as it was before, and require
> PAS only where a PAS call is actually issued. Keeping the SCM check
> matters: qcom_scm_assign_mem() passes __scm->mempool to
> qcom_tzmem_alloc() without testing __scm, so dropping the gate entirely
> would allow a NULL dereference when qcom_scm has not yet probed.
>
> Fixes: f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ
> APIs")
> Link:
> https://lore.kernel.org/r/[email protected]
> Signed-off-by: Paul Hollinsky <[email protected]>
> ---
> Reported and analysed in:
> https://lore.kernel.org/linux-arm-msm/[email protected]/
> Konrad agreed with this shape in
> https://lore.kernel.org/linux-arm-msm/[email protected]/
>
> f3b1357673dd is not in mainline yet, so this is based on
> remoteproc/rproc-next; it would be good to get it in before that branch
> is sent on.
>
> Tested on a Lenovo IdeaPad Duet 3 (sc7180-trogdor-wormdingler) on
> next-20260805, which carries the same code: with this applied the modem
> probes, mba/mpss load, and ath10k_snoc gets its QMI handshake so wifi
> comes up.
>
> drivers/remoteproc/qcom_q6v5_mss.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index bef198b9ee63..2f71ed2feff6 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -2079,7 +2079,16 @@ static int q6v5_probe(struct platform_device *pdev)
> if (!desc)
> return -EINVAL;
>
> - if (desc->need_mem_protection && !qcom_pas_is_available())
> + /*
> + * Memory protection is done through qcom_scm_assign_mem(), which needs
> + * SCM but not PAS. Only the memory setup path issues PAS calls, so
> + * requiring PAS for every need_mem_protection platform prevents the
> + * modem from probing at all on TZ firmware that offers no PAS.
> + */
> + if (desc->need_mem_protection && !qcom_scm_is_available())
> + return -EPROBE_DEFER;
> +
> + if (desc->need_pas_mem_setup && !qcom_pas_is_available())
> return -EPROBE_DEFER;
>
> mba_image = desc->hexagon_mba_image;
>
> base-commit: bb840ea69347aff7bde5a208e7b5b180669a7656
