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: <7140b8a8-1380-4859-84a3-681b3f1ce505@kernel.org>
Date: Mon, 20 Oct 2025 12:16:28 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Loic Poulain <loic.poulain@....qualcomm.com>
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 16/10/2025 12:43, Krzysztof Kozlowski wrote:
> On 16/10/2025 10:47, Loic Poulain wrote:
>> 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.
> 
> And this discussion CAN happen now, stopping this camss and any future
> camss till we conclude the discussion. Whatever internal plans of that
> teams are, rejecting technical discussion based on "no plans for that"
> is a really bad argument, only stalling this patchset and raising eyebrows.


To be clear, I expect Loic's comment to be fully and technically
addressed, not with "no plan for that".

This blocks this patchset and any new versions.

Best regards,
Krzysztof