On 9/10/19 11:14, Stephen Boyd wrote: > Quoting Jorge Ramirez-Ortiz, Linaro (2019-09-09 09:54:08) >> On 09/09/19 09:17:03, Stephen Boyd wrote: >>> But now the binding is different for the same compatible. I'd prefer we >>> keep using devm_clk_get() and use a device pointer here and reorder the >>> map and parent arrays instead. The clocks property shouldn't change in a >>> way that isn't "additive" so that we maintain backwards compatibility. >>> >> >> but the backwards compatibility is fully maintained - that is the main reason >> behind the change. the new stuff is that instead of hardcoding the >> names in the source - like it is being done on the msm8916- we provide >> the clocks in the dts node (a cleaner approach with the obvious >> benefit of allowing new users to be added without having to modify the >> sources). >> > > This is not a backwards compatible change. > >>>> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi >>>> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi >>>> @@ -429,7 +429,8 @@ >>>> compatible = "qcom,msm8916-apcs-kpss-global", "syscon"; >>>> reg = <0xb011000 0x1000>; >>>> #mbox-cells = <1>; >>>> - clocks = <&a53pll>; >>>> + clocks = <&gcc GPLL0_VOTE>, <&a53pll>; >>>> + clock-names = "aux", "pll"; >>>> #clock-cells = <0>; >>>> }; >>>> > > Because the "clocks" property changed from > > <&a53pll> > > to > > <&gcc GPLL0_VOTE>, <&a53pll> > > and that moves pll to cell 1 instead of cell 0. > > what do you mean by backwards compatible? because this change does not break previous clients.
