linux-kernel - Re: [PATCH v2 1/3] media: dt-bindings: Add qcom,sm6150-camss

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <khu5l5uqbnouciu2yari2t5ragt3dejdfmhjga2rvxoj4wi43s@c6klzwsscyzh>
Date: Wed, 24 Dec 2025 14:24:50 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Wenmeng Liu <wenmeng.liu@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Robert Foss <rfoss@...nel.org>,
        Todor Tomov <todor.too@...il.com>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, linux-media@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] media: dt-bindings: Add qcom,sm6150-camss

On Wed, Dec 24, 2025 at 06:29:43PM +0800, Wenmeng Liu wrote:
> 
> 
> On 12/24/2025 5:46 PM, Krzysztof Kozlowski wrote:
> > On 24/12/2025 06:36, Wenmeng Liu wrote:
> > > 
> > > 
> > > On 12/24/2025 1:03 PM, Dmitry Baryshkov wrote:
> > > > On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote:
> > > > > 
> > > > > 
> > > > > On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote:
> > > > > > On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote:
> > > > > > > > On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote:
> > > > > > > > > +  interconnects:
> > > > > > > > > +    maxItems: 4
> > > > > > > > > +
> > > > > > > > > +  interconnect-names:
> > > > > > > > > +    items:
> > > > > > > > > +      - const: ahb
> > > > > > > > > +      - const: hf0_mnoc
> > > > > > > > > +      - const: hf1_mnoc
> > > > > > > > 
> > > > > > > > Same comments as before, do not invent names.
> > > > > > > 
> > > > > > > <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS
> > > > > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> > > > > > > <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS
> > > > > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> > > > > > > 
> > > > > > > This platform(qcs615) is different from others. It has two types of sf,
> > > > > > > namely sf0 and sf1.
> > > > > > > The same as it is:
> > > > > > > sc7180 sc8180x sdm670 sdm845 sm8150
> > > > > > > Do you have any suggestions about this?
> > > > > > 
> > > > > > Which _names_ are used on other platforms? This question is quite clear
> > > > > > from Krzysztof's comment.
> > > > > 
> > > > > The platform mentioned above either has no camss ICC node or no support for
> > > > > CAMSS on the upstream, so this is a new one.
> > > > 
> > > > I did a quick look for you.
> > > > 
> > > > kodiak, lemans, monaco: ahb, hf_0
> > > > 
> > > > x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc
> > > > sm8650: ahb, hf_mnoc
> > > > agatti: ahb, hf_mnoc, sf_mnoc
> > > > sm8550: ahb, hf_0_mnoc
> > > > 
> > > > sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc
> > > > sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc
> > > > sdm660: vfe-mem
> > > > 
> > > > I'd obviously hope for some unification here. Other than that, we have
> > > > two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is
> > > > different from either of the options. In fact, none of the platforms
> > > > have the same _approach_ as yours. Why?
> > > > 
> > > 
> > > Yes, you're right.
> > > But none of the above cases involved having two hf_mnoc simultaneously,
> > > so do you have any good suggestions for handling such a situation?
> > 
> > And this is your answer to use completely different style? This makes no
> > sense.
> > 
> > This is your logic:
> > 1. If there is one HF, I will add underscore.
> > 2. If there is more than one HF, I will remove underscore.
> > 
> > This makes absolutely NO SENSE.
> > 
> 
> Would it make sense to use hf_0_mnoc and hf_1_mnoc to differentiate the two
> paths?

Or just hf_0 / hf_1.

-- 
With best wishes
Dmitry