Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Gervais, Francois" <FGervais@distech-controls.com>
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
CC:     "linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Michael McCormick <michael.mccormick@enatel.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] rtc: pcf85063: add integrity check
Thread-Topic: [PATCH 1/1] rtc: pcf85063: add integrity check
Thread-Index: AQHXFp722WysSQ6OikqG5IlMHahVT6q37BqAgAR8yVw=
Date:   Mon, 19 Apr 2021 20:26:42 +0000
Message-ID: <SN6PR01MB4269E7C0A5B2069F96384A6BF3499@SN6PR01MB4269.prod.exchangelabs.com>
References: <20210311174940.23072-1-fgervais@distech-controls.com>,<YHoKQ9qtupDhXVm3@piout.net>
In-Reply-To: <YHoKQ9qtupDhXVm3@piout.net>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c677e2d-01b3-4130-5a05-08d9037171cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2021 20:26:42.3306
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: caadbe96-024e-4f67-82ec-fb28ff53d16d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NydR/nSPe38E4EQNxMcB6X2KcuBWimrrMwYnsL7PEICimgZhPjQGMPh3od9YPocQJEewXcISnL3FJTcbA5khSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0102MB3549
X-Proofpoint-ORIG-GUID: NRs-M3caHoBkS4Ka7Jw0TgEddYSKpP7v
X-Proofpoint-GUID: NRs-M3caHoBkS4Ka7Jw0TgEddYSKpP7v
X-Proofpoint-Processed: True
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0
 impostorscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 mlxscore=0
 lowpriorityscore=0 bulkscore=0 spamscore=0 malwarescore=0
 priorityscore=1501 clxscore=1011 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2104060000 definitions=main-2104190139
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> I'm not sure I get the use case because PCF85063_REG_CTRL2 should be=0A=
> initialized properly after the driver is probed anyway. The other two=0A=
> can be set from userspace once it detects the oscillator failure which=0A=
> would be better at deciding the policy anyway.=0A=
=0A=
Thank you for the feedback I think I understand now.=0A=
=0A=
We saw the reported problem on devices running kernel v5.4 which doesn't=0A=
have the common clock framework support and so PCF85063_REG_CTRL2=0A=
clkout was not initialized by the kernel and left at hardware default.=0A=
=0A=
I guess with CCF support, if PCF85063_REG_CTRL2 gets corrupted on=0A=
power application, on driver probe the clkout value will be set to 0b000=0A=
or some known default.=0A=
=0A=
I'm not familiar the CCF, do you know if it's the case that default values=
=0A=
will be set on boot?=