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?
And such change to randomness in style - sometimes reg sorted that way,
sometimes other, interrupts sometimes like this or like that - should
not come from Linaro.
Best regards,
Krzysztof
