[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023032222190171a38d5f@mail.local>
Date: Wed, 22 Mar 2023 23:19:01 +0100
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Frieder Schrempf <frieder.schrempf@...tron.de>
Cc: Frieder Schrempf <frieder@...s.de>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-rtc@...r.kernel.org, Alessandro Zummo <a.zummo@...ertech.it>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Shawn Guo <shawnguo@...nel.org>
Subject: Re: [PATCH 0/7] Enable backup switch mode on RTCs via devicetree
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
Powered by blists - more mailing lists