linux-kernel - Re: [RFC PATCH 2/3] clk: bd718x7: Enable the possibility to mark the clock as critical

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]

Message-ID: <22f3c925-309f-4ebe-a481-2553cfa71c0c@gmail.com>
Date: Thu, 15 Aug 2024 09:07:25 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
Cc: Michael Turquette <mturquette@...libre.com>,
 Stephen Boyd <sboyd@...nel.org>,
 "open list:COMMON CLK FRAMEWORK" <linux-clk@...r.kernel.org>,
 open list <linux-kernel@...r.kernel.org>,
 Dario Binacchi <dario.binacchi@...rulasolutions.com>,
 linux-amarula@...rulasolutions.com, Marek Vasut <marex@...x.de>
Subject: Re: [RFC PATCH 2/3] clk: bd718x7: Enable the possibility to mark the
 clock as critical

On 8/14/24 19:00, Michael Nazzareno Trimarchi wrote:
> Hi Stephen
> 
> On Mon, Jun 6, 2022 at 7:26 AM Matti Vaittinen <mazziesaccount@...il.com> wrote:
>>
>> Hi Michael,
>>
>> On 6/5/22 19:57, Michael Trimarchi wrote:
>>> If the clock is used to generate the osc_32k, we need to mark
>>> as critical. clock-critical has no binding description at the moment
>>> but it's defined in linux kernel
>>>
>>> bd71847: pmic@4b {
>>> ...
>>>        rohm,reset-snvs-powered;
>>>
>>>        #clock-cells = <0>;
>>>        clock-critical = <1>;
>>>        clocks = <&osc_32k 0>;
>>>        clock-output-names = "clk-32k-out";
>>> ...
>>> }
>>>
>>> Signed-off-by: Michael Trimarchi <michael@...rulasolutions.com>
>>> ---
>>>    drivers/clk/clk-bd718x7.c | 4 ++++
>>
>> //snip
>>
>>> @@ -100,6 +101,9 @@ static int bd71837_clk_probe(struct platform_device *pdev)
>>>
>>>        parent_clk = of_clk_get_parent_name(parent->of_node, 0);
>>>
>>> +     of_clk_detect_critical(dev->of_node, 0, &flags);
>>
>> Purely judging the kerneldoc for of_clk_detect_critical - you may have
>> hard time getting this accepted.
>>
>> I think you're working on a very valid problem though. Maybe you could
>> see if you could align your effort with Marek?
>>
>> https://lore.kernel.org/all/20220517235919.200375-1-marex@denx.de/T/#m52d6d0831bf43d5f293e35cb27f3021f278d0564
>>
> 
> Old thread but same problem. Is there any way to make this acceptable?
> any suggestion?

Hi Michael. I'm not sure what is the correct way but I think there are a 
few tricks people have used to fix (or paper over) the problem. One was 
suggested by Sebastian:

https://lore.kernel.org/all/20220913152140.iikckob5h3ecagfi@mercury.elektranox.org/

No one shouted for implementing this fix though.

It also seems to me that there is a way to 'make things work' by 
modelling the clock dependencies in the DT in certain way, AND having 
correct drivers enabled. This understanding came just by reading mails 
Marek sent in this discussion:

https://lore.kernel.org/all/20220924174603.458956-1-marex@denx.de/

I've not tested any of this myself - but I hope you can use these as 
pointers to a solution that works for you...

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~