linux-kernel - Re: [PATCH 0/7] Enable backup switch mode on RTCs via devicetree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cb4d7ae5-f10f-e5d3-60c8-b96151160e10@kontron.de>
Date:   Tue, 28 Mar 2023 09:10:56 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
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

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.