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]

Message-ID: <e8279305-6bad-4029-4436-b48a4a8d43e9@gmail.com>
Date:   Mon, 12 Sep 2022 23:40:41 +0300
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Tim Harvey <tharvey@...eworks.com>, Peng Fan <peng.fan@....nxp.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/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.

> 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

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

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