On Sat, Nov 30, 2024 at 11:43:34AM +0100, Krzysztof Kozlowski wrote: > On 30/11/2024 11:26, Dmitry Baryshkov wrote: > > On Sat, Nov 30, 2024 at 11:00:32AM +0100, Krzysztof Kozlowski wrote: > >> On 30/11/2024 10:57, Dmitry Baryshkov wrote: > >>> On Sat, Nov 30, 2024 at 10:29:38AM +0100, Krzysztof Kozlowski wrote: > >>>> On 30/11/2024 02:44, Dmitry Baryshkov wrote: > >>>>> IPQ5018 is one of the platforms where board-level clocks (XO, sleep) > >>>>> definitions are split between the SoC dtsi file and the board file. > >>>>> This is not optimal, as the clocks are a part of the SoC + PMICs design. > >>>>> Frequencies are common for the whole set of devices using the same SoC. > >>>>> Remove the split and move frequencies to the SoC DTSI file. > >>>>> > >>>>> Suggested-by: Bjorn Andersson <andersson@xxxxxxxxxx> > >>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > >>>> > >>>> This contradicts DTS coding style and all my existing review. Obviously > >>>> that's a NAK from me. If you want to merge this patch, please kindly > >>>> carry my formal objection for this and all following "move board clocks" > >>>> patches: > >>>> > >>>> Nacked-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > >>> > >>> I'd kindly ask Bjorn to chime in as a platform maintainer. > >> > >> > >> To change my NAK? NAK is still a NAK. We discussed it many, many times > >> already. We have coding style for this explicitly mentioning this case. > >> Could not be more specific... plus all my reviews for Qualcomm, NXP, TI, > >> ST and other platforms. I would be quite unpredictable or unfair if I > >> gave here some sort of exception while expecting different code from > >> other platforms. > >> > >> Please carry my NAK. > > > > Of course. I didn't mean to drop your tag or your objection. > > > > BTW, would it be possible for you to clarify the policy on external > > references? I mean, is it fine for DTSI to reference a label which is > > not defined within that file or within one of the files that it includes? > > > It is fine, you have plenty of such examples of shared components like > some audio blocks or PMICs. > > All Qualcomm PMICs DTSI (e.g. arch/arm64/boot/dts/qcom/pmi632.dtsi ) > reference them. Chromebooks are even "worse" here: > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > Nothing gets included there but hundred of phandles! > > Are you planning to "fix" these as well? No. > > These are just Qualcomm, but same cases are everywhere else. > > But *that's not even important* because I do not suggest to move clocks > to DTSI. I suggest - and was almost always suggesting as best compromise > - to follow DTS coding style by doing opposite of what this patch is > doing. That's why I NAKed this and following patches, except last two > which are different. If you remmember my first attempt was implemented other way around. But I think it still better to have both frequencies in the SoC dtsi, it points out that it is tightly coupled with the RPM CC (and can not be easily changed), it saves us from 32 kHz / 32.768 kHz / 32.764 kHz typos, etc. -- With best wishes Dmitry
