[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SN6PR01MB4269E5EDFCAAA1308AF3EE10F3459@SN6PR01MB4269.prod.exchangelabs.com>
Date: Fri, 23 Apr 2021 15:21:33 +0000
From: "Gervais, Francois" <FGervais@...tech-controls.com>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
CC: "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
Alessandro Zummo <a.zummo@...ertech.it>,
Michael McCormick <michael.mccormick@...tel.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] rtc: pcf85063: add integrity check
>>> I'm not sure I get the use case because PCF85063_REG_CTRL2 should be
>>> initialized properly after the driver is probed anyway. The other two
>>> can be set from userspace once it detects the oscillator failure which
>>> would be better at deciding the policy anyway.
>>
>> Thank you for the feedback I think I understand now.
>>
>> We saw the reported problem on devices running kernel v5.4 which doesn't
>> have the common clock framework support and so PCF85063_REG_CTRL2
>> clkout was not initialized by the kernel and left at hardware default.
>>
>> I guess with CCF support, if PCF85063_REG_CTRL2 gets corrupted on
>> power application, on driver probe the clkout value will be set to 0b000
>> or some known default.
>>
>> I'm not familiar the CCF, do you know if it's the case that default values
>> will be set on boot?
>
> The CCF will disable any clocks that are not used on boot so the clock
> will be either used and configured or not used and disabled.
I see now, thank you for the feedback.
I changed the patch status to "Not Applicable" and archived it.
Powered by blists - more mailing lists