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.
WARNING: multiple messages have this Message-ID (diff)
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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-28 7:11 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-01 14:34 [PATCH 0/7] Enable backup switch mode on RTCs via devicetree Frieder Schrempf 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 ` 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 14:34 ` Frieder Schrempf 2023-02-01 16:15 ` [PATCH 0/7] Enable backup switch mode on RTCs via devicetree Alexandre Belloni 2023-02-01 16:15 ` Alexandre Belloni 2023-02-01 16:26 ` Frieder Schrempf 2023-02-01 16:26 ` Frieder Schrempf 2023-02-13 9:18 ` Frieder Schrempf 2023-02-13 9:18 ` Frieder Schrempf 2023-03-06 13:27 ` Frieder Schrempf 2023-03-06 13:27 ` Frieder Schrempf 2023-03-22 13:14 ` Frieder Schrempf 2023-03-22 13:14 ` Frieder Schrempf 2023-03-22 22:19 ` Alexandre Belloni 2023-03-22 22:19 ` Alexandre Belloni 2023-03-28 7:10 ` Frieder Schrempf [this message] 2023-03-28 7:10 ` Frieder Schrempf
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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.