linux-kernel - Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali

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: <1c9db550-677e-4fdc-8929-89c21deecf17@linaro.org>
Date: Wed, 10 Dec 2025 21:45:56 +0000
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
 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>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali

On 10/12/2025 19:36, Vijay Kumar Tumati wrote:
> 
> On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote:
>> On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
>>> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
>>>> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>>>>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>>>>>>> +  interconnects:
>>>>>>>> +    maxItems: 4
>>>>>>>> +
>>>>>>>> +  interconnect-names:
>>>>>>>> +    items:
>>>>>>>> +      - const: ahb
>>>>>>>> +      - const: hf_mnoc
>>>>>>>> +      - const: sf_icp_mnoc
>>>>>>>> +      - const: sf_mnoc
>>>>>>> You know... Failure to look around is a sin. What are the names of
>>>>>>> interconnects used by other devices? What do they actually describe?
>>>>>>>
>>>>>>> This is an absolute NAK.
>>>>>> Please feel free to correct me here but, a couple things.
>>>>>>
>>>>>> 1. This is consistent with
>>>>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
>>>>> I see that nobody noticed an issue with Agatti, Lemans and Monaco
>>>>> bindings (Krzysztof?)
>>>>>
>>>>> Usually interconnect names describe the blocks that are connected. 
>>>>> Here
>>>>> are the top results of a quick git grep of interconnect names through
>>>>> arch/arm64/dts/qcom:
>>>>>
>>>>>       729 "qup-core",
>>>>>       717 "qup-config",
>>>>>       457 "qup-memory",
>>>>>        41 "usb-ddr",
>>>>>        41 "apps-usb",
>>>>>        39 "pcie-mem",
>>>>>        39 "cpu-pcie",
>>>>>        28 "sdhc-ddr",
>>>>>        28 "cpu-sdhc",
>>>>>        28 "cpu-cfg",
>>>>>        24 "mdp0-mem",
>>>>>        17 "memory",
>>>>>        14 "ufs-ddr",
>>>>>        14 "mdp1-mem",
>>>>>        14 "cpu-ufs",
>>>>>        13 "video-mem",
>>>>>        13 "gfx-mem",
>>>>>
>>>>> I hope this gives you a pointer on how to name the interconnects.
>>>>>
>>>>>> 2. If you are referring to some other targets that use, "cam_"
>>>>>> prefix, we
>>>>>> may not need that , isn't it? If we look at these interconnects
>>>>>> from camera
>>>>>> side, as you advised for other things like this?
>>>>> See above.
>>>> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
>>>> should be ok?
>>>>
>>>> Or the other option, go exactly like
>>>> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
>>>>
>>>> What would you advise?
>>>>
>>> To keep it consistent with the previous generations and still 
>>> represent the
>>> block name, we will go ahead with the style in qcom,sc8280xp- 
>>> camss.yaml. If
>>> anyone has any concerns, please do let us know.
>> Krzysztof, Bryan, your opinion? My preference would be to start using
>> sensible names, but I wouldn't enforce that.
>>
>>>>>>>> +
>>>>>>>> +  iommus:
>>>>>>>> +    items:
>>>>>>>> +      - description: VFE non-protected stream
>>>>>>>> +      - description: ICP0 shared stream
>>>>>>>> +      - description: ICP1 shared stream
>>>>>>>> +      - description: IPE CDM non-protected stream
>>>>>>>> +      - description: IPE non-protected stream
>>>>>>>> +      - description: JPEG non-protected stream
>>>>>>>> +      - description: OFE CDM non-protected stream
>>>>>>>> +      - description: OFE non-protected stream
>>>>>>>> +      - description: VFE / VFE Lite CDM non-protected stream
>>>>>>> This will map all IOMMUs to the same domain. Are you sure that 
>>>>>>> this is
>>>>>>> what we want? Or do we wait for iommu-maps to be fixed?
>>> Yes, when it is available, we can start using iommu-maps to create 
>>> separate
>>> context banks.
>> It would be necessary to justify removing items from the list. Wouldn't
>> it be better to map only necessary SIDs now and add other later once we
>> have iommu-maps?
> I will let Bryan take the call on this. He was the one who wanted all 
> the SIDs in the bindings. Hi @Bryan, if you can kindly share your 
> thoughts on this and the interconnect naming, we will go ahead and push 
> rev 10 for this. I believe we have taken care of other things. Thank you.
>>

Since when are we delaying patches for future patches that may land never ?

I'm fine with whatever clock name changes you can agree with Krzysztof 
but it seems a bit ironic to me to be given feedback to "align with 
previous dts" to then have the result be further change.

I'd like a bit of stability and consistency TBH.

---
bod