From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6113C433B4 for ; Mon, 19 Apr 2021 21:16:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C512611EE for ; Mon, 19 Apr 2021 21:16:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238515AbhDSVQ3 (ORCPT ); Mon, 19 Apr 2021 17:16:29 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:55541 "EHLO relay10.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229714AbhDSVQ0 (ORCPT ); Mon, 19 Apr 2021 17:16:26 -0400 Received: from localhost (lfbn-lyo-1-1676-55.w90-65.abo.wanadoo.fr [90.65.108.55]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 8453A240003; Mon, 19 Apr 2021 21:15:54 +0000 (UTC) Date: Mon, 19 Apr 2021 23:15:54 +0200 From: Alexandre Belloni To: "Gervais, Francois" Cc: "linux-rtc@vger.kernel.org" , Alessandro Zummo , Michael McCormick , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/1] rtc: pcf85063: add integrity check Message-ID: References: <20210311174940.23072-1-fgervais@distech-controls.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/04/2021 20:26:42+0000, Gervais, Francois wrote: > > 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. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com