From: Frieder Schrempf <frieder.schrempf@kontron.de>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Frieder Schrempf <frieder@fris.de>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org,
Alessandro Zummo <a.zummo@towertech.it>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>
Subject: Re: [PATCH 0/7] Enable backup switch mode on RTCs via devicetree
Date: Tue, 28 Mar 2023 09:10:56 +0200 [thread overview]
Message-ID: <cb4d7ae5-f10f-e5d3-60c8-b96151160e10@kontron.de> (raw)
In-Reply-To: <2023032222190171a38d5f@mail.local>
On 22.03.23 23:19, Alexandre Belloni wrote:
> 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.
Thanks for taking the time! I know that maintainers are usually
chronically overloaded. Still I got a bit worried after ~7 weeks that I
wont get a reply at all.
>
> 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.
This is an argument that I was expecting to hear in the first place. I
think this is kind of a grey area as the BSM feature is definitely
related to the hardware implementation of the V_DD and V_BACKUP supply
voltages, but at the same time it also might reflect device configuration.
>
> - 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.
Thanks for pointing that out. The userspace solution is definitely
useful and necessary and I would never argue against it. What I'm
proposing is not really a second interface but a way to set the default
mode at boot time. If you really think this is too much, then I will
need to scratch this approach.
prev parent reply other threads:[~2023-03-28 7:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 14:34 Frieder Schrempf
2023-02-01 14:34 ` [PATCH 1/7] dt-bindings: rtc: Move RV3028 to separate binding file Frieder Schrempf
2023-02-01 20:10 ` Rob Herring
2023-02-02 9:10 ` Krzysztof Kozlowski
2023-02-02 10:17 ` Frieder Schrempf
2023-02-01 14:34 ` [PATCH 2/7] dt-bindings: rtc: Add backup-switch-mode property Frieder Schrempf
2023-02-01 14:34 ` [PATCH 3/7] dt-bindings: rtc: microcrystal,rv3032: " Frieder Schrempf
2023-02-01 14:34 ` [PATCH 4/7] rtc: Move BSM defines to separate header for DT usage Frieder Schrempf
2023-02-02 23:22 ` kernel test robot
2023-02-01 14:34 ` [PATCH 5/7] rtc: class: Support setting backup switch mode from devicetree Frieder Schrempf
2023-02-01 14:34 ` [PATCH 6/7] arm64: dts: imx8mm-kontron: Remove useless trickle-diode-disable from RTC node Frieder Schrempf
2023-02-01 14:34 ` [PATCH 7/7] arm64: dts: imx8mm-kontron: Enable backup switch mode for RTC on OSM-S module Frieder Schrempf
2023-02-01 16:15 ` [PATCH 0/7] Enable backup switch mode on RTCs via devicetree Alexandre Belloni
2023-02-01 16:26 ` Frieder Schrempf
2023-02-13 9:18 ` Frieder Schrempf
2023-03-06 13:27 ` Frieder Schrempf
2023-03-22 13:14 ` Frieder Schrempf
2023-03-22 22:19 ` Alexandre Belloni
2023-03-28 7:10 ` Frieder Schrempf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb4d7ae5-f10f-e5d3-60c8-b96151160e10@kontron.de \
--to=frieder.schrempf@kontron.de \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=frieder@fris.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®