On 03/07/2026 14:31, Ananthu C V wrote:
> Most Qualcomm platforms feature Gunyah hypervisor, which typically
> handles Stage 2 IOMMU configuration. Additionally, SHM bridge setup
> is required to enable memory protection for both remoteproc metadata
> and its memory regions. When the aforementioned hypervisor is absent,
> the operating system must perform these configurations instead. We've
> been relying on the iommu property being present for this, but for
> remoteprocs that are already running like SoCCP the mappings are already
> in place, and any attempt to recreate them while active would lead to smmu
> faults and a non-functional remoteproc. Fix this by adding a needs_tzmem
> flag which ensures tzmem and SHM bridge setup is performed independent to
> the iommu property being present.
Looks awfully like LLM written and considering obvious problem, this
feels vibe coded.
According to current docs YOU SHOULD add vibe-coding tag to the commit
when doing that.
> static const struct of_device_id qcom_pas_of_match[] = {
> { .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
> + { .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource
> },
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> { .compatible = "qcom,kaanapali-soccp-pas", .data =
> &kaanapali_soccp_resource },
> { .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
> { .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
>
Best regards,
Krzysztof
