Hi Krzysztof,
On 10/11/24 17:29, Krzysztof Kozlowski wrote:
On Fri, Oct 11, 2024 at 10:14:49AM +0300, Vladimir Zapolskiy wrote:
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss@ac65000 {
+ compatible = "qcom,sdm670-camss";
+
+ reg = <0 0x0acb3000 0 0x1000>,
This is immediately wrong, unit address shall be the same as the address of the
first value of reg property.
I still object to the sorting order of reg values dictated by reg-names property.
There are a few recently added CAMSS device tree binding descriptions, where
reg values are sorted by address values without a connection to another property
values, and I believe this is the correct way to go.
Two most recently added CAMSS IP descriptions (qcom,sm8250-camss.yaml and
qcom,sc8280xp-camss.yaml) do implement sorting by reg values, I believe from now on
it should be assumed that all subsequently added CAMSS IP descriptions to follow
the same established policy.
Heh, sc8280xp introduced entirely different sorting also in interrupt-names.
Just look at interrupts of sm8250 and sc8280xp. Luckily clocks are still
keeping style.
Can you start keeping consistency? All bindings from the same family of
devices, especially if they share something, should have similar order
in lists.
How do you imagine writing drivers and request items by order (not by
name) if the order is different in each flavor?
I don't see a problem here, and I don't remember any reports about this
kind of problem while adding CAMSS support in the driver to new platforms.
While the problem of improper CAMSS unit address appears again and again,
the focus shall be on removing a chance to make a commin mistake here.
As I've already said above, device tree bindings of CAMSS in two most
recently added platforms sm8250 and sc8280xp follow the numerical order
of addresses from reg value. This becomes the policy.
Sorting lists of interrupts or clocks by numerical values makes no sense,
thus the argument of *-names sorting becomes valid here. For clarity, reg
property is very special, also a snippet of its value goes as a unit
address.
--
Best wishes,
Vladimir
