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: <f5a1076f-f06c-404d-88d4-fef4f7694c82@linaro.org>
Date: Mon, 20 Oct 2025 11:56:05 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 Loic Poulain <loic.poulain@....qualcomm.com>
Cc: Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
 Jingyi Wang <jingyi.wang@....qualcomm.com>, 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 20/10/2025 11:16, Krzysztof Kozlowski wrote:
> 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

I think we should stick with the existing bindings.

There is no "lite" ISP there are so-called lite blocks within the CAMSS 
block.

It makes sense to split out the PHYs from this block as they have their 
own power-rails but, if you look at the block diagrams for this IP there 
is no specific ISP lite, there are merely blocks within the camera 
called lite.

It might be nice to structure things like this 
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi with each component 
separated out into its own node with its own compat string but, I'd have 
a hard time justifying changing up the bindings we already have for that 
reason - aside from anything else - all of those components in CAMSS 
live inside of the TITAN_TOP_GDSC which is the power-domain for the 
whole camera system.

So not meaning to answer for Hangxiang but, I think the compelling logic 
here is to stick to and extend the existing bindings.

So in fact I have no problem with the bindings as submitted - not 
including the regular fixups these types of submissions entail.

---
bod