Hey Hugo, On Wed, Aug 02, 2023 at 03:11:52PM -0400, Hugo Villeneuve wrote: > From: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx> > > 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 <hvilleneuve@xxxxxxxxxxxx> > --- > .../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? Thanks, Conor. > + > quartz-load-femtofarads: > description: > The capacitive load of the quartz(x-tal), expressed in femto > -- > 2.30.2 >
Attachment:
signature.asc
Description: PGP signature
