linux-kernel - Re: [PATCH 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding

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: <CAFEp6-1zpobZNLHt1192Ahtn2O7bV+As0P1YvVHrkRsORyH_Aw@mail.gmail.com>
Date: Thu, 16 Oct 2025 10:47:11 +0200
From: Loic Poulain <loic.poulain@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
        Jingyi Wang <jingyi.wang@....qualcomm.com>,
        "Bryan O'Donoghue" <bryan.odonoghue@...aro.org>,
        Robert Foss <rfoss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "Bryan O'Donoghue" <bod@...nel.org>, Todor Tomov <todor.too@...il.com>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>, linux-i2c@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        aiqun.yu@....qualcomm.com, tingwei.zhang@....qualcomm.com,
        trilok.soni@....qualcomm.com, yijie.yang@....qualcomm.com
Subject: Re: [PATCH 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding

On Thu, Oct 16, 2025 at 7:52 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 15/10/2025 05:21, Hangxiang Ma wrote:
> >>> +      - const: csiphy4
> >>> +      - const: csiphy5
> >>> +      - const: vfe0
> >>> +      - const: vfe1
> >>> +      - const: vfe2
> >>> +      - const: vfe_lite0
> >>> +      - const: vfe_lite1
> >> Wouldn't it make sense to simplify this and have different camss nodes
> >> for the 'main' and 'lite' paths?
> >>
> >> [...]
> > No such plan till now. Other series may take this into consideration.
>
> We don't care much about your plan. You are expected to send correct
> hardware description.

To be fair, other platforms like sc8280xp-camss already have the
all-in big camss node.
Point is that if Lite and Main blocks are distinct enough we could
have two simpler nodes.
Would it make things any better from a dts and camss perspective?

 camss: isp@...3000 {
    compatible = "qcom,kaanapali-camss";
    [...]
}

camss-lite:ips@...3000 {
   compatible = "qcom,kaanapali-lite-camss";
    [...]
}

That approach would create two distinct CAMSS instances and separate
media pipelines.
However, it may not work with the current implementation, as the CSI
PHYs would need to be shared between them.

I guess this should be part of the broader discussion around
splitting/busifying CAMSS.

Regards,
Loic