linux-kernel - Re: [PATCH v3 2/4] media: dt-bindings: qcom,sc7280-venus: drop non-PAS support

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: <b6adf4df-2fb1-4e18-8c3f-3aabb4e155ea@oss.qualcomm.com>
Date: Wed, 28 Jan 2026 18:15:17 +0530
From: Vikash Garodia <vikash.garodia@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Bryan O'Donoghue <bod@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        cros-qcom-dts-watchers@...omium.org,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>
Cc: linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 2/4] media: dt-bindings: qcom,sc7280-venus: drop
 non-PAS support



On 1/27/2026 5:53 PM, Dmitry Baryshkov wrote:
> The only users of the non-PAS setup on SC7280 platform are the ChromeOS
> devices, which were cancelled before reaching end users. Iris, the
> alternative driver for the same hardware, does not support non-PAS
> setup. It is expected that in future both Venus and Iris devices will
> use different ABI for non-PAS (EL2) setup.
> 
> In order to declare only the future-proof hardware description drop
> support for non-PAS setup from the SC7280 Venus schema (breaking almost
> non-existing SC7280 ChromeOS devices).
> 
> The dropped iommus entry reflects the extra stream, which should not be
> treated in the same way as the main one (which doesn't match the usage
> described by the iommus definition).
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
> ---
>   Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml | 10 ++--------
>   1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
> index 413c5b4ee650..9725fcb761dc 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
> @@ -43,8 +43,7 @@ properties:
>         - const: vcodec_bus
>   
>     iommus:
> -    minItems: 1
> -    maxItems: 2
> +    maxItems: 1
>   
>     interconnects:
>       maxItems: 2
> @@ -120,12 +119,7 @@ examples:
>                           <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>;
>           interconnect-names = "cpu-cfg", "video-mem";
>   
> -        iommus = <&apps_smmu 0x2180 0x20>,
> -                 <&apps_smmu 0x2184 0x20>;

SID 0x2184 was for one of the secure internal buffer specific to encode 
usecase. To make it work on qcm6490, there have been changes done in VPU 
firmware to avoid configuring that buffer as secure, and VPU generates 
0x2180 only while accessing that specific internal buffer now.

> +        iommus = <&apps_smmu 0x2180 0x20>;
>   
>           memory-region = <&video_mem>;
> -
> -        video-firmware {
> -            iommus = <&apps_smmu 0x21a2 0x0>;
> -        };
>       };
> 

Regards,
Vikash