linux-kernel - Re: [PATCH v3 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: <7efc63ed-9c84-43c0-b524-f7e9e60b2846@kernel.org>
Date: Tue, 28 Oct 2025 17:56:55 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>,
 Hangxiang Ma <hangxiang.ma@....qualcomm.com>
Cc: Loic Poulain <loic.poulain@....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>, Todor Tomov <todor.too@...il.com>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.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,
 Jingyi Wang <jingyi.wang@....qualcomm.com>,
 Atiya Kailany <atiya.kailany@....qualcomm.com>
Subject: Re: [PATCH v3 2/6] dt-bindings: media: camss: Add
 qcom,kaanapali-camss binding

On 28/10/2025 16:22, Vijay Kumar Tumati wrote:
>>> +  interconnects:
>>> +    maxItems: 2
>>> +
>>> +  interconnect-names:
>>> +    items:
>>> +      - const: ahb
>>> +      - const: hf_mnoc
>> Why previously this was called hf_0 but now hf?
> Hi Krzysztof, the interconnect driver exposes only one node 'camnoc_hf' 

Drivers don't matter. Interconnect driver does not matter here. You
describe this hardware, not interconnect driver.

Keep it consistent with previous devices, whichever these are.

> to the camera driver, with it internally managing the voting on hf_0 and 
> hf_1 clients. The traffic from the Real Time blocks in camera go through 
> both HF_0 and HF_1, with the former being the primary. This change 
> correctly represents that the BW voting is for the whole of the HF 
> client. Please let me know if you have any further questions and we 
> would be happy to answer. Thank you.
>>> +
>>> +  iommus:
>>> +    maxItems: 1
>>> +
>>> +  power-domains:
>>> +    items:
>>> +      - description:
>>> +          TFE0 GDSC - Thin Front End, Global Distributed Switch Controller.
>>> +      - description:
>>> +          TFE1 GDSC - Thin Front End, Global Distributed Switch Controller.
>>> +      - description:
>>> +          TFE2 GDSC - Thin Front End, Global Distributed Switch Controller.
>>> +      - description:
>>> +          Titan GDSC - Titan ISP Block Global Distributed Switch Controller.
>>> +
>>> +  power-domain-names:
>>> +    items:
>>> +      - const: tfe0
>>> +      - const: tfe1
>>> +      - const: tfe2
>> Why not using the same names as before? It really does not matter that
>> it is thin or image, all of them are the same because only the
>> difference against top matters.
> Right, this is done to maintain the consistency with the clock driver on 

Sorry, this makes no sense. This device has nothing to do with clock
driver. Don't ever use clock drivers as arguments for doing something in
completely different place.

Not mentioning that drivers don't matter much for the bindings, so I
really do not get what you try to explain here.

Best regards,
Krzysztof