linux-kernel - Re: [PATCH v8 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: <msscnw2e4xil3kynnrfpujaybknbbzzk7mgcowgefqlk57zzfd@h73cxwezx7fg>
Date: Mon, 8 Dec 2025 21:58:27 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        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,
        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>,
        Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH v8 1/5] media: dt-bindings: Add CAMSS device for Kaanapali

On Sun, Dec 07, 2025 at 09:41:11PM -0800, Vijay Kumar Tumati wrote:
> 
> On 12/7/2025 5:44 PM, Dmitry Baryshkov wrote:
> > On Sat, Dec 06, 2025 at 10:11:20PM +0000, Bryan O'Donoghue wrote:
> > > On 01/12/2025 06:30, Hangxiang Ma wrote:
> > > > Add the compatible string "qcom,kaanapali-camss" to describe the Camera
> > > > Subsystem (CAMSS) on the Qualcomm Kaanapali platform.
> > > > 
> > > > The Kaanapali platform provides:
> > > > - 3 x VFE, 5 RDI per VFE
> > > > - 2 x VFE Lite, 4 RDI per VFE Lite
> > > > - 3 x CSID
> > > > - 2 x CSID Lite
> > > > - 6 x CSIPHY
> > > > - 2 x ICP
> > > > - 1 x IPE
> > > > - 2 x JPEG DMA & Downscaler
> > > > - 2 x JPEG Encoder
> > > > - 1 x OFE
> > > > - 5 x RT CDM
> > > > - 3 x TPG
> > > > 
> > > > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> > > > Reviewed-by: Krzysztof Kozlowski <krzk@...nel.org>
> > > > Signed-off-by: Hangxiang Ma <hangxiang.ma@....qualcomm.com>
> > > > ---
> > > >    .../bindings/media/qcom,kaanapali-camss.yaml       | 647 +++++++++++++++++++++
> > > >    1 file changed, 647 insertions(+)
> > > > 
> > > > +      - const: gcc_hf_axi
> > > https://patchwork.linuxtv.org/project/linux-media/patch/20251126-add-support-for-camss-on-sm8750-v1-2-646fee2eb720@oss.qualcomm.com/
> > > 
> > > Pointed out by Krzysztof in the 8750 patches but the name of this clock is
> > > gcc_axi_hf.
> > > 
> > > ~/Development/worktree/qcom-linux-next
> > > ➞  grep gcc_axi_hf * -r | wc -l              [git:platform-qcom-next] ✖
> > > 48
> > > 
> > > ~/Development/worktree/qcom-linux-next
> > > ➞  grep gcc_hf_axi * -r | wc -l              [git:platform-qcom-next] ✖
> > > 0
> > My 2c: it should be none of those. gcc_axi_hf is the _source_ of the
> > clock, while the bindings (in my opinion) should be describing the
> > function of the clock on the consumer side (e.g. bus, iface, something
> > else, etc).
> 
> Hi Dmitry, this is MMNOC side of the AXI bus clock for the HF clients. If
> it's ok, we can change it to be consistent with previous generations for KNP
> and we can take it up in detail when we refactor the bindings for Hawi?
> Please let me know if you have a strong opinion on this at this point and we
> can discuss accordingly.

Well, why do you think that for Hawi the requirement will be different?
It's the same: describe the _use_ of the clock rather than the source.
You got that feedback internally already  during our telcos and then
later when you've sent your proposal, but for some reason you didn't get
it.

BTW, if it's an MMNOC end of the bus, should it instead be voted by the
NoC driver?

> Hi Bryan, we are addressing the things that makes sense for KNP as well in
> the next revision. Btw, couple things like a separate CSIPHY DT node and
> ordering of the resources (that were to be added at the end as you advised),
> I believe are not relevant for KNP. As for the GDSC names, we preferred the
> module name and it's GDSC name to be consistent so changed the latter as
> well to VFE. Hope that's ok. Please let us know if you would suggest any
> further changes to KNP v9 bindings and we can move forward accordingly.
> 
> Thank you both.
> 
> > > Please resolve the other inconsitencies pointed out by Krzysztof in that
> > > thread here also.
> > > 
> > > I will have to skip application of this series in the meantime.
> > > 
> > > ---
> > > bod

-- 
With best wishes
Dmitry