linux-kernel - Re: [PATCH V2] clk: imx: support protected-clocks

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] [day] [month] [year] [list]

Date:   Tue, 23 Aug 2022 09:05:00 +0800
From:   Peng Fan <peng.fan@....nxp.com>
To:     Sascha Hauer <s.hauer@...gutronix.de>
Cc:     abelvesa@...nel.org, abel.vesa@...aro.org, mturquette@...libre.com,
        sboyd@...nel.org, shawnguo@...nel.org, kernel@...gutronix.de,
        festevam@...il.com, linux-imx@....com, linux-clk@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Peng Fan <peng.fan@....com>
Subject: Re: [PATCH V2] clk: imx: support protected-clocks



On 8/16/2022 11:02 PM, Sascha Hauer wrote:
> On Tue, Aug 16, 2022 at 09:03:27PM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@....com>
>>
>> For the clocks listed in protected-clocks, enable them to avoid
>> Linux disable them. This will benifit root Linux and inmate cell run
>> on top of Jailhouse hypervisor, and benifit the other case(
>> A53 Linux run together with M7 RTOS).
>>
>> Signed-off-by: Peng Fan <peng.fan@....com>
>> ---
>>
>> V2:
>>   Per Sascha, use common protected-clocks property.
> 
> See my mail to v1. I did not request that you should use the
> protected-clocks property:
> 
>> There were cases when a property first started with a "soc," prefix and
>> later when people realized that it could be useful for other
>> drivers/SoCs as well, the prefix was removed. With that in mind I
>> would expect that a "fsl,protected-clocks" property behaves the same
>> as a "protected-clocks" property without the prefix.
>>
>> If it doesn't please pick a different name. I didn't want to suggest
>> to just drop the "fsl," prefix and to use the generic property name
>> when the properties have a different meaning.

oh, I misunderstood.

Here I just wanna linux prepare enable clks and never off them,
the clks may vary per different usecase.

how about
fsl,init-on-clks=<xx>?
or extend to
fsl,init-on-clks-with-rate=<xx>?

Thanks,
Peng.
> 
> Sascha
>