On 30.11.2024 11:43 AM, 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? > > 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. Many of these components are simply not "fully on board" or "fully on SoC" on Qualcomm platforms, and probably others too. A number of components are tightly coupled and there are lots of circular dependencies, or in-between cases (like RPM(h)cc which abstract clocks specific to a SoC+PMIC combo). Some are effectively represented multiple times. There's also a lot of internal routing which can't be well-represented in DT without adding thousands of lines that Linux would register as virtual clocks that do absolutely nothing. There's also clocks that are not even visible from software POV that are physically connected. And as the final point, any given platform requires a fixed frequency crystal is present and will (to my understanding) not function otherwise. Hence, I think this is really form over function that gets in the way.. Konrad
