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: <d1b0b5c1-a031-4429-bb4b-ad8bc914c971@linaro.org>
Date: Thu, 26 Jun 2025 11:48:12 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: 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,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v5 3/4] media: dt-bindings: Add qcom,msm8939-camss

On 26/06/2025 11:28, Krzysztof Kozlowski wrote:
> On 26/06/2025 12:19, Bryan O'Donoghue wrote:
>> On 26/06/2025 11:00, Krzysztof Kozlowski wrote:
>>>> +  reg-names:
>>>> +    items:
>>>> +      - const: csi_clk_mux
>>> No, I already provided arguments in two lengthy discussions - this is
>>> not sorted by name.
>>>
>>> Keep the same order as in previous device, so msm8916 for example. Or
>>> any other, but listen to some requests to sort it by some arbitrary rule
>>> which was never communicated by DT maintainers.
>>
>> I don't think if you look through the history that you can find a
>> consistent rule that was used to arrange the registers.
>>
>> So we are trying to have a consistent way of doing that. Thats why the
>> last number of additions have been sort by name, because it seemed to be
>> the most consistent.
> 
> 
> Why are we discussing it again? You asked me the same here:
> https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/
> 
> and I already said - not sorting by name. You take the same order as
> previous.
> 
> If you ever want to sort by name, answer to yourself:
> NO. Take the same order as other existing device.
> 
> If you ever want to sort by value, answer to yourself:
> NO.
> 
> You both came with some new, invented rules of sorting, applied it, and
> now you claim that "existing devices were sorted like that". What? NO!
> 
> Best regards,
> Krzysztof

OK.

Discussed this on Slack with Krzysztof.

8939 should be like 8916 because these are devices of a similar class.

x1e has a particular order if a new device x1e+1 comes along with a new 
register then

reg-names:
  23     items:
  24       - const: csid0
  25       - const: csid1
  26       - const: csid2
  27       - const: csid_lite0
  28       - const: csid_lite1
  29       - const: csid_wrapper
  30       - const: csiphy0
  31       - const: csiphy1
  32       - const: csiphy2
  33       - const: csiphy4
  34       - const: csitpg0
  35       - const: csitpg1
  36       - const: csitpg2
  37       - const: vfe0
  38       - const: vfe1
  39       - const: vfe_lite0
  40       - const: vfe_lite1

reg-names:
  23     items:
  24       - const: csid0
  25       - const: csid1
  26       - const: csid2
  27       - const: csid_lite0
  28       - const: csid_lite1
  29       - const: csid_wrapper
  30       - const: csiphy0
  31       - const: csiphy1
  32       - const: csiphy2
  33       - const: csiphy4
  34       - const: csitpg0
  35       - const: csitpg1
  36       - const: csitpg2
  37       - const: vfe0
  38       - const: vfe1
  39       - const: vfe_lite0
  40       - const: vfe_lite1
           - NEW ENTRY GOES HERE csid3

A new SoC with a significantly different architecture could have 
different ordering of regs.

The main block should go first which means the above should look like:

reg-names:
  23     items:
  24       - const: csid_wrapper
  25       - const: csid0
  26       - const: csid1
  27       - const: csid2
  28       - const: csid_lite0
  29       - const: csid_lite1
  30       - const: csiphy0
  31       - const: csiphy1
  32       - const: csiphy2
  33       - const: csiphy4
  34       - const: csitpg0
  35       - const: csitpg1
  36       - const: csitpg2
  37       - const: vfe0
  38       - const: vfe1
  39       - const: vfe_lite0
  40       - const: vfe_lite1

I think I personally haven't understood what was meant by "devices of a 
class" but its clearer now.

Appreciate the explanation.

---
bod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ