linux-kernel - Re: [PATCH v2 1/3] dt-bindings: media: camss: Add qcom,sm6350-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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0337e0dd-d25c-4f22-968b-f1a3c364d025@kernel.org>
Date: Sat, 20 Dec 2025 05:53:03 +0000
From: Bryan O'Donoghue <bod@...nel.org>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Luca Weiss <luca.weiss@...rphone.com>, 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: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: media: camss: Add qcom,sm6350-camss

On 19/12/2025 16:18, Vladimir Zapolskiy wrote:
> FreeBSD or CamX are software, and they shall be excluded from consideration.
> 
> There shall be no guesses about software usage, the only concern is if
> the hardware desription in the shape of device tree nodes is proper or not.
> 
> Partial verifiable description is a proper description, and adding unknowns
> of "future goodness" does not serve any reasonable technical purpose, it
> adds an illusion of a proper description only, and it was proven that this
> illision shatters even for CAMSS, see CAMSS CSIPHY case, when a wrong DT
> choice can not be undone anymore for legacy platforms. It is good to acquire
> an ability to learn from the past.
> 
> Everything can be added ad-hoc while keeping the hardware description in
> a proper and correct state.

Are all of the VFE Lite's verified ?

Even some of them ? I think not.

We are seeing in multiple places how failure to properly articulate SIDs 
results in mess.

So full description of the hardware > partial.

BTW your statement about not being able to change DT bindings is wrong. 
You just need a good argument and to make that case successfully upstream.

---
bod