On 9/10/19 11:34, Jorge Ramirez wrote: > 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. as per the comments I added to the code (in case this helps framing the discussion) [..] legacy bindings only defined the pll parent clock (index = 0) with no name; when both of the parents are specified in the bindings, the pll is the second one (index = 1). [..] > > > > > > >
