linux-kernel - Re: [PATCH v6 10/14] arm64: dts: freescale: imx8qxp: Remove unnecessary clock related entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220630083636.2c7mclmbq3tjma2j@fsr-ub1664-116>
Date:   Thu, 30 Jun 2022 11:36:36 +0300
From:   Viorel Suman <viorel.suman@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     "Viorel Suman (OSS)" <viorel.suman@....nxp.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Dong Aisheng <aisheng.dong@....com>,
        Fabio Estevam <festevam@...il.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Stefan Agner <stefan@...er.ch>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Amit Kucheria <amitk@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        NXP Linux Team <linux-imx@....com>,
        Abel Vesa <abelvesa@...nel.org>,
        Oliver Graute <oliver.graute@...oconnector.com>,
        Liu Ying <victor.liu@....com>,
        Mirela Rabulea <mirela.rabulea@....com>,
        Peng Fan <peng.fan@....com>, Ming Qian <ming.qian@....com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-input@...r.kernel.org,
        linux-gpio@...r.kernel.org, linux-rtc@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-watchdog@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 10/14] arm64: dts: freescale: imx8qxp: Remove
 unnecessary clock related entries

On 22-06-29 20:04:43, Krzysztof Kozlowski wrote:
> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> > From: Viorel Suman <viorel.suman@....com>
> > 
> > "clocks" and "clock-names" are not used the driver, so
> > remove them in order to match the yaml definition.
> 
> So this explains the unexpected change in the bindings... but actually
> it does not explain whether it is correct or not. Just because driver
> does not use it, is not a proof that clocks are not there. In different
> OS/implementation this DTS might break stuff, so basically it is ABI
> break. DTS should describe the hardware fully, so if the clocks are
> there, should be in DTS regardless of the driver.

Hi Krzysztof,

Both XTAL clocks - 24MHz and 32kHz - are still defined in DTSI files, see for instance in
arch/arm64/boot/dts/freescale/imx8qxp.dtsi :
---------------
        xtal32k: clock-xtal32k {
                compatible = "fixed-clock";
                #clock-cells = <0>;
                clock-frequency = <32768>;
                clock-output-names = "xtal_32KHz";
        };

        xtal24m: clock-xtal24m {
                compatible = "fixed-clock";
                #clock-cells = <0>;
                clock-frequency = <24000000>;
                clock-output-names = "xtal_24MHz";
        };
---------------
Both can be seen in /sys/kernel/debug/clk/clk_summary once boot is complete, both can be referenced
in any DTS node, so there is no ABI break.

"DTS should describe the hardware fully" - this is true in case the OS is supposed to controll the
hardware fully. i.MX8 System Controller Unit concept implies resources being allocated and managed
by SCU, there is no direct OS access to some hardware. SCU actually defines the hardware environment
the OS is being able to see and run within. SCU is able to define several such isolated hardware
environments, each having its own OS running. So, in this particular case - i.MX8 SCU concept -
DTS should describe the hardware from the perspective of the hardware environment exposed by SCU to
OS.

Best regards,
Viorel