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 EEF04C04E69 for ; Tue, 8 Aug 2023 17:28:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234592AbjHHR2O (ORCPT ); Tue, 8 Aug 2023 13:28:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234580AbjHHR1m (ORCPT ); Tue, 8 Aug 2023 13:27:42 -0400 Received: from mail.hugovil.com (mail.hugovil.com [162.243.120.170]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBE72EBB7; Tue, 8 Aug 2023 09:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hugovil.com ; s=x; h=Subject:Content-Transfer-Encoding:Mime-Version:Message-Id:Cc:To:From :Date:subject:date:message-id:reply-to; bh=dP3kh+kDx9zElDDDoC7PRVq68biyXb2WGj3LyKhU5Rs=; b=oK5r0qn1HYBL65s1wkMyqZfKO/ iRpuXeV0rC2jL8bkDzFW4w36CsFD5Kjy1iDR27NDMB5DLI1OMckuCxwqJXjDWrVKcgj0bf4QwPSIb s2PaB/GZIgfq3/08OsvQhDip/ufHuVE8YnsHFrWvMdpkvOHyjapupfetwCmnGKd6fr80=; Received: from modemcable061.19-161-184.mc.videotron.ca ([184.161.19.61]:53646 helo=pettiford) by mail.hugovil.com with esmtpa (Exim 4.92) (envelope-from ) id 1qTLmH-0004IO-Qo; Tue, 08 Aug 2023 08:25:34 -0400 Date: Tue, 8 Aug 2023 08:25:33 -0400 From: Hugo Villeneuve To: Conor Dooley Cc: a.zummo@towertech.it, alexandre.belloni@bootlin.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, linux-rtc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, bruno.thomsen@gmail.com, Hugo Villeneuve Message-Id: <20230808082533.b608c9a2a4bd922920643c4b@hugovil.com> In-Reply-To: <20230808-capsize-deodorize-5776d3dbb192@spud> References: <20230802191153.952667-1-hugo@hugovil.com> <20230802191153.952667-2-hugo@hugovil.com> <20230808-capsize-deodorize-5776d3dbb192@spud> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 184.161.19.61 X-SA-Exim-Mail-From: hugo@hugovil.com Subject: Re: [PATCH 1/2] dt-bindings: rtc: add properties to set battery-related functions X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on mail.hugovil.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Aug 2023 12:21:24 +0100 Conor Dooley wrote: > Hey Hugo, > > On Wed, Aug 02, 2023 at 03:11:52PM -0400, Hugo Villeneuve wrote: > > From: Hugo Villeneuve > > > > These properties can be defined in the board's device tree to set the > > default power-on values for battery-related functions. > > > > Signed-off-by: Hugo Villeneuve > > --- > > .../devicetree/bindings/rtc/rtc.yaml | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml > > index efb66df82782..0217d229e3fa 100644 > > --- a/Documentation/devicetree/bindings/rtc/rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml > > @@ -26,6 +26,25 @@ properties: > > 0: not chargeable > > 1: chargeable > > > > + battery-low-detect: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1] > > + description: | > > + For RTC devices supporting a backup battery/supercap, this flag can be > > + used to configure the battery low detection reporting function: > > + 0: disabled > > + 1: enabled > > + > > + battery-switch-over: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1] > > + description: | > > + For RTC devices supporting a backup battery/supercap, this flag can be > > + used to configure the battery switch over when the main voltage source is > > + turned off: > > + 0: disabled > > + 1: enabled > > Why are these implemented as enums? This seems to fall into the category > of using DT to determine software policy - why's it not sufficient to > have boolean properties that indicate hardware support and let the software > decide what to do with them? Hi Conor, the reason is that I based the new properties on the existing property "aux-voltage-chargeable": ------------------- aux-voltage-chargeable: $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] description: | Tells whether the battery/supercap of the RTC (if any) is chargeable or not: 0: not chargeable 1: chargeable ------------------- I agree with you that a boolean would be more appropriate. Should I also submit a (separate) patch to fix the "aux-voltage-chargeable" property to a boolean? Hugo. > Thanks, > Conor. > > > + > > quartz-load-femtofarads: > > description: > > The capacitive load of the quartz(x-tal), expressed in femto > > -- > > 2.30.2 > >