Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1104759ybj; Tue, 5 May 2020 13:09:59 -0700 (PDT) X-Google-Smtp-Source: APiQypIrtF4dERnc8g/Q8RJJ4+D+5j9ybYJCDmcEUlAU2eaWmAQHXOlfdiC6yeqmUXG+l4BGITw0 X-Received: by 2002:aa7:d655:: with SMTP id v21mr4347435edr.355.1588709398924; Tue, 05 May 2020 13:09:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588709398; cv=none; d=google.com; s=arc-20160816; b=cF8cncXUXLalkkc8v3y2TfIKWvvpuCMrbnSeJRPbqYCb1/l3VxqK1WESjpFwKmeZ8q SnZjnPw1PCyy1LBBI/YhnkEunUWps6emXi/V+BG0OTzHI9yhyBLdMYO2/IUg1XVgwgyg 4aMvserGNJMIbnBLvXSlxuYkjaFu5iNa0qdn+0Pd0Q2xOpAid/OeXm1zovJ8gjmgKwP2 ZC159OmxAHX8zeyW0YqATiETpTfTDoX4ChQjhzb4FUoIanI10a0fbSrMLrAynyAJBgd6 drzZgyZAxrb2I9P2l+dAbFcT9LUCNvzZNgA2TyrvMMvbRl2NMoa5kxaEb3PCy3QkG6Q7 U/SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Ld8MVTHnAZ3WxJ+qc0XpwbkBwwrgB74x8i7/WgcYuAo=; b=qI4Yv+LoFFRy0to5qX+4OV8XFBzFBAjXiOePHJG6mkF/xmWBkc9o8S/5zcSjsFBYTR rug6fMuurMglTeMwg03nb5OV2YhsHiy0dorpgDyfwR33iUJfxZl1QIUE83tSH1EYBnvL nH51imblNMzNsj5zQROEXU3SOCsa16Q3keK5MQRO4Jch5ZftzF2y76BQOFhGN7+rtwaN ua2G00p/KMnYB0hclXDWDmLesPx6oUP9T5cHGGMbDnurJUdLnpN2RhLUgHqe+x0wUdVi T1MYf/2JOLn9enO/egv4U3szqZL0T1+/F4F73ZCK1A2zuj6OvZ09LRHimn4J6XoUrpQY OZSA== 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 j13si1852920edn.465.2020.05.05.13.09.34; Tue, 05 May 2020 13:09:58 -0700 (PDT) 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 S1728609AbgEEUHq (ORCPT + 99 others); Tue, 5 May 2020 16:07:46 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:47001 "EHLO relay10.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727785AbgEEUHq (ORCPT ); Tue, 5 May 2020 16:07:46 -0400 Received: from localhost (lfbn-lyo-1-9-35.w86-202.abo.wanadoo.fr [86.202.105.35]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 89F51240008; Tue, 5 May 2020 20:07:44 +0000 (UTC) Date: Tue, 5 May 2020 22:07:44 +0200 From: Alexandre Belloni To: Rasmus Villemoes Cc: Bruno Thomsen , Per =?iso-8859-1?Q?N=F8rgaard?= Christensen , LKML Subject: Re: battery switch-over detection on pcf2127 Message-ID: <20200505200744.GV34497@piout.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/05/2020 21:54:47+0200, Rasmus Villemoes wrote: > Hi Bruno > > I just noticed your "rtc: pcf2127: add tamper detection support" > (03623b4b04) from 5.4. Unfortunately, clearing the BTSE bit breaks a use > case of ours: > > We rely on the battery switch-over detection to distinguish a powerfail > during boot from a PORESET by the external watchdog (in the latter case, > the RTC is still powered throughout, meaning there is no battery > switch-over event). OTOH, we do not use the tamper detection - in fact, > the TS signal is unconnected on our board. > > We're currently still on 4.19, but we will eventually upgrade to a > kernel containing the above commit. So I was wondering if we could > figure out a way that would work for both of us - either some CONFIG > knob, or perhaps something in the device-tree. Any ideas? > Yes, I was working on a patch series last week allowing to read BF. I'm not sure clearing BTSE is your issue but clearing BF is. I'm going to send it tonight, I'll copy you, let me now if that works for you. You can then read BF using the RTC_VL_READ ioctl. The RTC_VL_BACKUP_SWITCH flag will be set if a switchover happened. The RTC_VL_CLR ioctl can be used to clear the flag. I think clearing BTSE is still the right thing to do. Regards, -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com