linux-kernel - Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure

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]

Date:   Tue, 13 Sep 2022 10:27:56 +0800
From:   Peng Fan <peng.fan@....nxp.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>,
        Tim Harvey <tharvey@...eworks.com>
Cc:     Marek Vasut <marex@...x.de>, Peng Fan <peng.fan@....com>,
        Stephen Boyd <sboyd@...nel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Fabio Estevam <festevam@...il.com>,
        Shawn Guo <shawnguo@...nel.org>,
        dl-linux-imx <linux-imx@....com>,
        Michael Turquette <mturquette@...libre.com>
Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure



On 9/13/2022 4:40 AM, Matti Vaittinen wrote:
> On 9/12/22 20:15, Tim Harvey wrote:
>> On Mon, Sep 12, 2022 at 12:40 AM Peng Fan <peng.fan@....nxp.com> wrote:
> 
> //snip
> 
>>>
>>> After a thought, maybe an easier way is to add a optional property
>>> xxx,32k-always-on to the pmic node/driver.
>>>
> 
> Yes, that would be easy. Yet, creating a driver specific DT-property 
> feels a tad wrong. I don't think the BD718xx is in any way special so it 
> should not need such a vendor specific property. It might be better to 
> find more generic solution.

I am not sure, even if saying always-on-clocks are accepted, the 
property still needs to wrote into the BD718xx node, because BD718xx
itself serves as a clock provider.

Regards,
Peng.

> 
>> Is there simply a way to add the clk to the snvs_rtc and the wdog dt
>> nodes so they have a use count and don't get disabled?
> 
> To me that does sound like the right thing to do. If we have a consumer 
> which requires the clock, then describing this dependency in DT sounds 
> like a correct approach - assuming this keeps the clock enabled without 
> a race between instantiating the PMIC and finding the clock consumers.
> 
> Finally, if adding the consumers does not help, and if there will be no 
> consensus regarding the generic property - then I think it's better to 
> have a vendor specific property (as Peng suggested) than it is having 
> the boards broken. Eg, if all else fails and if there is a buy-in for 
> the vendor specific propety from Rob and Stephen - then I can also live 
> with it (even if it sure significantly decreases my happiness level :p)



> 
> Yours,
>      -- Matti
>