linux-kernel - Re: [PATCH v5 3/4] media: dt-bindings: Add qcom,msm8939-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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <8c83b5c1-b7ca-4fc8-9246-a950c356214c@linaro.org>
Date: Thu, 26 Jun 2025 12:41:06 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Krzysztof Kozlowski <krzk@...nel.org>, vincent.knecht@...loo.org,
 Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
 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>
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 André Apitzsch <git@...tzsch.eu>,
 phone-devel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v5 3/4] media: dt-bindings: Add qcom,msm8939-camss

On 26/06/2025 12:17, Vladimir Zapolskiy wrote:

> What's about MSM8953 then?

Should be fixed up to match 8916. We don't have an upstream user and we, 
I, did the wrong thing.
> Please see commit c830aff08d51 ("media: dt-bindings: Add qcom,msm8953- 
> camss").
> 
>> x1e has a particular order if a new device x1e+1 comes along with a new
>> register then
>>
> 
>>
>> I think I personally haven't understood what was meant by "devices of a
>> class" but its clearer now.
>>
> 
> And I still didn't get it, how to read this "devices of a class"?
> 
> In particular why is MSM8939 a device of MSM8916 class and MSM8953 is
> not?
> 
> For sake of simplicity I list only accepted CAMSS dt bindings:
> 
> qcom,msm8916-camss.yaml
> qcom,msm8953-camss.yaml
> qcom,msm8996-camss.yaml
> qcom,sc7280-camss.yaml
> qcom,sc8280xp-camss.yaml
> qcom,sdm660-camss.yaml
> qcom,sdm670-camss.yaml
> qcom,sdm845-camss.yaml
> qcom,sm8250-camss.yaml
> qcom,sm8550-camss.yaml
> qcom,x1e80100-camss.yaml

I mean some old commits in Linux wouldn't make it through the 
upstreaming process now.

8953 is not right and can be changed.

8250, 845 may have bindings we wouldn't accept now but they have users 
so we live with them.

> I kindly ask to select a number of class defining IPs from the list,
> so that all next ones will derive from those only, and not from
> "another class". It's a task for a DT maintainer I presume.
> 
> Before completing this and getting a common understanding all next
> work to provide CAMSS suppor for new platforms is not directed by
> any policy, because the policy "do as it's been done before" is
> applied inconsistently.
> 
I think I personally am clear on the rule from the DT people, even if I 
may not get it right on subsequient submissions.

The sort order thing is a red herring, in simple terms. We should be 
consistent in device classes.

For example TITAN 680 and 690 should look pretty similar, TITAN 340 and 
990 probably can have greater divergence.

Either way the sort order thing is a dead end, anything upstream on that 
basis like x1e is probably fine because it is of its particular class of 
device.

8953 and 8939 should match their device class of 8916.

---
bod