Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp182258pxb; Thu, 14 Jan 2021 03:14:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJwjE4eSJXA7nMBjBb7cc36QFP8pW0cHETUVbXZ8b0BYjP6jU523A2232rINwY863F/ndxaZ X-Received: by 2002:a05:6402:3c3:: with SMTP id t3mr5419360edw.86.1610622893408; Thu, 14 Jan 2021 03:14:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610622893; cv=none; d=google.com; s=arc-20160816; b=BGR4oYMmaWEBBBtpUGEWCcPR1x0IITMyfY2bPd8sVwvc2I2SbWq0IcivqNWYOot/Ci 1+LHl129aaSoRatk7RFh6jHjQw/zT7Uob3h/ODtsdBq6/4F7nQFyvuy/GyiInNK5+fvQ /dKiokXBCO8I33wWPZg/TVZ1NlvQhRrj8uLmvNi6hLVM3IJJAgkO4vhHUh5/wFYLnLsm mWDLk3k1WcKjHQyMvj8k7zmxO/dAr2X7vAx3huR4a+GZQTFwyD5bRjBi1q5G84kUxJsk mMAC/yr812TvepotjRyy44iPDDV1clnlNxIumDbx+0h3NGjAD09KNuJDD6c2nLRuFUSo Ul2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Vu8EZHZLDvI93TI0gZJG6NHXlYplYWDXYEq+q7+QmYs=; b=WpJT568eGX33lBF64DBZ3peTR5fW3jQkjpNFlI7WLZVIbleLXJVEAp5Xro6cK8okS2 1LHn7qgYc//Ot2w7SK/2cko1HeYWW6uV/ftx+ADiKZZfzZkZhp8JPlCCxMl1ROEwr8QV sn/N9XkMzXmEVFvly86CTY+g0u0Gk+pbHOqlr8HDmXAqY46CK6iT59k5SG0tTesEuFwX kCF55RIR2vu0LWJCsg8XKdOM8Pdy3y328A1yKU3WG3bS8X5TgTzWO2asWbPJpIDTEySL XAWYmgWTmRuFGkUc8+uBR3D6D1QoL3/zSh2YgX1hOfNdCkqxX2/okmxX5LQP8pdvQlK9 jvEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q26si2157464edt.415.2021.01.14.03.14.28; Thu, 14 Jan 2021 03:14:53 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726701AbhANLMk (ORCPT + 99 others); Thu, 14 Jan 2021 06:12:40 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:14107 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726472AbhANLMk (ORCPT ); Thu, 14 Jan 2021 06:12:40 -0500 X-Originating-IP: 86.202.109.140 Received: from localhost (lfbn-lyo-1-13-140.w86-202.abo.wanadoo.fr [86.202.109.140]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 89878240019; Thu, 14 Jan 2021 11:11:57 +0000 (UTC) Date: Thu, 14 Jan 2021 12:11:57 +0100 From: Alexandre Belloni To: Philipp Rosenberger Cc: dan.carpenter@oracle.com, u.kleine-koenig@pengutronix.de, biwen.li@nxp.com, lvb@xiphos.com, bruno.thomsen@gmail.com, l.sanfilippo@kunbus.com, Alessandro Zummo , linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] rtc: pcf2127: Run a OTP refresh if not done before Message-ID: <20210114111157.GC3654@piout.net> References: <20210113112742.7354-1-p.rosenberger@kunbus.com> <20210113112742.7354-3-p.rosenberger@kunbus.com> <20210114095008.GV3654@piout.net> <77d07f5e-2891-21d6-feee-19e841a8343e@kunbus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77d07f5e-2891-21d6-feee-19e841a8343e@kunbus.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/01/2021 11:30:37+0100, Philipp Rosenberger wrote: > > > + ret = regmap_set_bits(pcf2127->regmap, PCF2127_REG_CLKOUT, > > > + PCF2127_BIT_CLKOUT_OTPR); > > > + if (ret < 0) { > > > + dev_err(dev, "%s: OTP refresh (clkout_ctrl) failed.\n", __func__); > > > > Please drop this error message. > > If I return from the probe with an error, shouldn't there be an error > message? Or should I ignore the problem at all and don't return from the > probe? You can return from probe without an error message. > > > > > > + return ret; > > > + } > > > + msleep(100); > > > > Maybe this should be done just before setting the time. Or if you want > > to keep it in probe, then you could optimise by not waiting but ensuring > > the time between pcf2127_probe and the first pcf2127_rtc_set_time is > > more than 100ms. > > > > Doing it just before setting the time might be not the best way. The > watchdog might be used before the OTPR is done. > > From the PCF2129 manual: > | The OTP refresh (see Section 8.3.2 on page 13) should ideally be > | executed as the first instruction after start-up and also after a > | reset due to an oscillator stop. > > As I see it this should be done before setting up the watchdog as well. So > sleeping if the OTPR wasn't done before might be the most viable solution. > So I would check the OTPR and only if the OTPR is not set starting an OTPR > and then sleep 100ms. > Indeed, the remaining question is whether you should test OTPR or OSF. OSF states: "oscillator has stopped and chip reset has occurred since flag was last cleared" if OTPR is always 0 when OSF is 1, then OTPR is probably enough. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com