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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67EFFC7619A for ; Wed, 22 Mar 2023 22:19:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbjCVWTJ (ORCPT ); Wed, 22 Mar 2023 18:19:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbjCVWTH (ORCPT ); Wed, 22 Mar 2023 18:19:07 -0400 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9C9835B5; Wed, 22 Mar 2023 15:19:04 -0700 (PDT) Received: (Authenticated sender: alexandre.belloni@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 3862A1BF207; Wed, 22 Mar 2023 22:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1679523543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3mjbfAka6B37e0KLGUhxUpe2dBgCPhl+V2vV2LCTJ5E=; b=BOJeM2ybRH5eO7IdR+XNOl1FwdIrfDZl8WJBfo05uMnsQ68RwMvKvYWarJNDKZQ/qFk5RQ iujueB5qtsuYAv9VKqSMoMoifOcac5tHFuuPw/gA5zZqsKqKNhq5I/rbAqOsHKx9Ucz5e6 lOBvt3FfXcvcLX5HlnhedHCSVGthILVGJ3LrzWiVe64VPPZa1VuM2SVuujaucHV+iGupCb d11/XmzV6bcNets90AKh08DthMaYyJxs0V1SaR17bFGlVVE0Arc7fk0xE05fKdR1uY8/T4 gv/OB2jEH0Awmzp5ZK8pgzjFkJcTYgP0LWMvG+h294ivNcXbjH6q/00KSoqO1A== Date: Wed, 22 Mar 2023 23:19:01 +0100 From: Alexandre Belloni To: Frieder Schrempf Cc: Frieder Schrempf , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org, Alessandro Zummo , Krzysztof Kozlowski , Rob Herring , Sascha Hauer , Shawn Guo Subject: Re: [PATCH 0/7] Enable backup switch mode on RTCs via devicetree Message-ID: <2023032222190171a38d5f@mail.local> References: <20230201143431.863784-1-frieder@fris.de> <7268b05b-bbb1-ec4d-6a05-f5ccbdfeed90@kontron.de> <31b0a8b1-d027-d47a-e10d-614c09211734@kontron.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31b0a8b1-d027-d47a-e10d-614c09211734@kontron.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On 22/03/2023 14:14:50+0100, Frieder Schrempf wrote: > On 06.03.23 14:27, Frieder Schrempf wrote: > > On 13.02.23 10:18, Frieder Schrempf wrote: > >> Hi Alexandre, > >> > >> On 01.02.23 17:26, Frieder Schrempf wrote: > >>> On 01.02.23 17:15, Alexandre Belloni wrote: > >>>> Hello, > >>>> > >>>> You can't do that, this breaks an important use case and it is the > >>>> reason why I didn't use device tree in the beginning. What is wrong with > >>>> setting BSM from userspace? You will anyway have to set the time and > >>>> date from userspace for it to be saved. > >>> > >>> Ok, I was already afraid there is something I missed. Can you give a > >>> short explanation of what use case this would break? > >>> > >>> There is nothing wrong with setting BSM from userspace. It's just the > >>> fact that users expect BSM to be enabled in any case as there is a > >>> battery on the board. It is much more effort to ensure that production, > >>> user, etc. are aware of an extra step required than to let the kernel > >>> deal with it behind the scenes. > >> > >> Would you mind elaborating on your argument that this would break stuff? > >> I currently don't see how an additional optional devicetree property > >> would break anything. > > > > Ping!? > > It seems like you decided to ignore me for whatever reasons there are. > I'm sure we can sort it out in some way if you would respond, please. I do what I can with the time I have. There are 2 issues: - the first one is that this is encoding device configuration in the device tree which is forbidden. BSM is not really hardware related. The worse that could happen is that the backup voltage is not present and so the RTC will never switch to the backup source. - the second one is why I got to a userspace solution. There are RTC where it is crucial to be able to change BSM dynamically. Those RTCs have a standby mode: they will only draw current from the backup source once they have seen VDD once. This is useful when you install a battery in a product and this products stays on the shelf for a while before being used. However, if your production line needs to powerup the device to flash it or perform tests, the RTC will get out of standby mode and you need a way to get it back to standby. This is possible with the current interface, I'm not going to have a second interface. Regards, -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id ED809C6FD1C for ; Wed, 22 Mar 2023 22:20:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kvtv22BfuetkBrwBsA1y72XR2d+poDZDn++eNIF9gJg=; b=xNBgp0ZWqhZkku k4IvOGF1yqryeRznpb2FrsRH+9zr2H3BXigw89QDGW4PZeUid5EKkkQ7LIIfSTePJE9vHd+zJguNV G22PhwN7l47qDNbjSS97TdwIcWhdRzkitASx/FBuEkR3pDLTIpUYaJ2TF86l0+GbrJ7cGP6TER4BE 94gM266sIxiiJnYWb+zz7rTuke5+7Y1dkgPXJPpmHez6zNOEVOIcom9scb83G2pWZGH4rRUTBy85G G6/LuamNEeYYM7BnILWNXk2hjwjG2TGOyiGt1Matm19rbKA6/17bJ0LZC8GSqGg+c+9oDp6DYoI6c srcHsUgEqtBJObGWK9BA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pf6na-00Hadk-0Q; Wed, 22 Mar 2023 22:19:14 +0000 Received: from relay8-d.mail.gandi.net ([217.70.183.201]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pf6nW-00Habn-0y for linux-arm-kernel@lists.infradead.org; Wed, 22 Mar 2023 22:19:12 +0000 Received: (Authenticated sender: alexandre.belloni@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 3862A1BF207; Wed, 22 Mar 2023 22:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1679523543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3mjbfAka6B37e0KLGUhxUpe2dBgCPhl+V2vV2LCTJ5E=; b=BOJeM2ybRH5eO7IdR+XNOl1FwdIrfDZl8WJBfo05uMnsQ68RwMvKvYWarJNDKZQ/qFk5RQ iujueB5qtsuYAv9VKqSMoMoifOcac5tHFuuPw/gA5zZqsKqKNhq5I/rbAqOsHKx9Ucz5e6 lOBvt3FfXcvcLX5HlnhedHCSVGthILVGJ3LrzWiVe64VPPZa1VuM2SVuujaucHV+iGupCb d11/XmzV6bcNets90AKh08DthMaYyJxs0V1SaR17bFGlVVE0Arc7fk0xE05fKdR1uY8/T4 gv/OB2jEH0Awmzp5ZK8pgzjFkJcTYgP0LWMvG+h294ivNcXbjH6q/00KSoqO1A== Date: Wed, 22 Mar 2023 23:19:01 +0100 From: Alexandre Belloni To: Frieder Schrempf Cc: Frieder Schrempf , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org, Alessandro Zummo , Krzysztof Kozlowski , Rob Herring , Sascha Hauer , Shawn Guo Subject: Re: [PATCH 0/7] Enable backup switch mode on RTCs via devicetree Message-ID: <2023032222190171a38d5f@mail.local> References: <20230201143431.863784-1-frieder@fris.de> <7268b05b-bbb1-ec4d-6a05-f5ccbdfeed90@kontron.de> <31b0a8b1-d027-d47a-e10d-614c09211734@kontron.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <31b0a8b1-d027-d47a-e10d-614c09211734@kontron.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230322_151910_625729_9170AC5F X-CRM114-Status: GOOD ( 28.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello, On 22/03/2023 14:14:50+0100, Frieder Schrempf wrote: > On 06.03.23 14:27, Frieder Schrempf wrote: > > On 13.02.23 10:18, Frieder Schrempf wrote: > >> Hi Alexandre, > >> > >> On 01.02.23 17:26, Frieder Schrempf wrote: > >>> On 01.02.23 17:15, Alexandre Belloni wrote: > >>>> Hello, > >>>> > >>>> You can't do that, this breaks an important use case and it is the > >>>> reason why I didn't use device tree in the beginning. What is wrong with > >>>> setting BSM from userspace? You will anyway have to set the time and > >>>> date from userspace for it to be saved. > >>> > >>> Ok, I was already afraid there is something I missed. Can you give a > >>> short explanation of what use case this would break? > >>> > >>> There is nothing wrong with setting BSM from userspace. It's just the > >>> fact that users expect BSM to be enabled in any case as there is a > >>> battery on the board. It is much more effort to ensure that production, > >>> user, etc. are aware of an extra step required than to let the kernel > >>> deal with it behind the scenes. > >> > >> Would you mind elaborating on your argument that this would break stuff? > >> I currently don't see how an additional optional devicetree property > >> would break anything. > > > > Ping!? > > It seems like you decided to ignore me for whatever reasons there are. > I'm sure we can sort it out in some way if you would respond, please. I do what I can with the time I have. There are 2 issues: - the first one is that this is encoding device configuration in the device tree which is forbidden. BSM is not really hardware related. The worse that could happen is that the backup voltage is not present and so the RTC will never switch to the backup source. - the second one is why I got to a userspace solution. There are RTC where it is crucial to be able to change BSM dynamically. Those RTCs have a standby mode: they will only draw current from the backup source once they have seen VDD once. This is useful when you install a battery in a product and this products stays on the shelf for a while before being used. However, if your production line needs to powerup the device to flash it or perform tests, the RTC will get out of standby mode and you need a way to get it back to standby. This is possible with the current interface, I'm not going to have a second interface. Regards, -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel