Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <517aecda-681f-ce77-08df-97738a865f96@linaro.org>
Date:   Thu, 4 May 2023 13:01:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.1
Subject: Re: [PATCH] clk: imx: imx93: introduce clk_bypassed module parameter
Content-Language: en-US
To:     Peng Fan <peng.fan@nxp.com>, Greg KH <greg@kroah.com>,
        "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
        Rob Herring <robh+dt@kernel.org>,
        "krzysztof.kozlowski+dt@linaro.org" 
        <krzysztof.kozlowski+dt@linaro.org>
Cc:     "abelvesa@kernel.org" <abelvesa@kernel.org>,
        "mturquette@baylibre.com" <mturquette@baylibre.com>,
        "sboyd@kernel.org" <sboyd@kernel.org>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "festevam@gmail.com" <festevam@gmail.com>,
        dl-linux-imx <linux-imx@nxp.com>,
        "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20230504085506.504474-1-peng.fan@oss.nxp.com>
 <2023050410-rejoin-vocation-8560@gregkh>
 <DU0PR04MB9417F9CBB5C9EE1FC85B10A2886D9@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <b09998bc-9ff7-3a18-89af-9778521ab127@linaro.org>
 <DU0PR04MB941792F2EF3DB5ADB0B1A75A886D9@DU0PR04MB9417.eurprd04.prod.outlook.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <DU0PR04MB941792F2EF3DB5ADB0B1A75A886D9@DU0PR04MB9417.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 04/05/2023 11:34, Peng Fan wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> Sent: 2023年5月4日 17:31
>> To: Peng Fan <peng.fan@nxp.com>; Greg KH <greg@kroah.com>; Peng Fan
>> (OSS) <peng.fan@oss.nxp.com>; Rob Herring <robh+dt@kernel.org>;
>> krzysztof.kozlowski+dt@linaro.org
>> Cc: abelvesa@kernel.org; mturquette@baylibre.com; sboyd@kernel.org;
>> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de;
>> festevam@gmail.com; dl-linux-imx <linux-imx@nxp.com>; linux-
>> clk@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH] clk: imx: imx93: introduce clk_bypassed module
>> parameter
>>
>> On 04/05/2023 11:17, Peng Fan wrote:
>>> + DT maintainers.
>>>
>>>> Subject: Re: [PATCH] clk: imx: imx93: introduce clk_bypassed module
>>>> parameter
>>>>
>>>> On Thu, May 04, 2023 at 04:55:06PM +0800, Peng Fan (OSS) wrote:
>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>
>>>>> With the clk names specified in clk_bypassed module parameter, give
>>>>> user an option to bypass the clk from managing them by Linux kernel.
>>>>
>>>> As I said on another email, no, please do not add new module
>>>> parameters for drivers, this is not the 1990s
>>>
>>> ok, but this is for boot, so only DT could be considered.
>>>
>>> But DT is to describe hardware, here I just wanna give user an option
>>> to bypass some clocks. Is it ok to add a DT property saying
>>> "fsl,imx93-bypass-clks = <IMX93_CLK_X>, <IMX93_CLK_Y>" ?
>>>
>>
>> I don't know what it is to "bypass some clocks". This does not look like
>> parameter for system at all.
> 
> Currently the linux clk driver registers all the clocks and manage them.
> But when M33 is running, M33 may not wanna linux to manage
> some clocks M33 is using. So I wanna linux not register those clocks
> that M33 will use.

Ask the one who designed such system that second processor pokes parts
of first processor... I assume if the clock controller is enabled in DTS
for Linux, then the Linux owns it. Otherwise how do you expect to handle
concurrent access to same registers from different processors?

And how are you going to decide which clocks should be managed by M33?
One firmware could want to play with one clock, other with everything...
Module parameter is not the way to deal with it.

Probably Ahmad's idea is the only one reasonable in your case, if you do
not have hypervisor.


Best regards,
Krzysztof