linux-kernel - Re: [PATCH 4/5] ARM: dts: sam9x60: add rtt

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200414124741.GJ34509@piout.net>
Date:   Tue, 14 Apr 2020 14:47:41 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Claudiu.Beznea@...rochip.com
Cc:     a.zummo@...ertech.it, robh+dt@...nel.org, mark.rutland@....com,
        Nicolas.Ferre@...rochip.com, Ludovic.Desroches@...rochip.com,
        tglx@...utronix.de, jason@...edaemon.net, maz@...nel.org,
        linux-rtc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] ARM: dts: sam9x60: add rtt

On 14/04/2020 12:13:46+0000, Claudiu.Beznea@...rochip.com wrote:
> 
> 
> On 14.04.2020 14:16, Alexandre Belloni wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On 14/04/2020 08:42:08+0000, Claudiu.Beznea@...rochip.com wrote:
> >>> Why would one use the RTT while the RTC is far superior?
> >>
> >> I didn't enabled this for a particular use case, but: couldn't this be used
> >> by some user that wants to generate multiple alarms? from multiple RTCs?
> >>
> > 
> > I very much doubt that as Linux is able to properly multiplex alarms and
> > basically, the only one we are interested in is actually wakeup.
> 
> I think you can use the wakealarm sysfs exported file to prepare an alarm
> and take user space actions based on that without being suspended.
> 
> > 
> >> Moreover, this IP's counter has the possibility of being clocked at 1Hz.
> >> Couldn't this minimize the power consumption while being in a power saving
> >> mode?
> >>
> > 
> > And that 1Hz clock is coming from the RTC so using the RTC is
> > definitively consuming less power.
> 
> Datasheet specifies this: "Configuring the RTPRES field value to 0x8000
> (default value) corresponds to feeding the real-time counter with a
> 
> 1Hz signal (if the slow clock is 32.768 kHz)."
> 
> So, it is not the RTC, it is the slow clock divided by 32768.

This is not what you described previously, using RTPRES means running
the RTT at 32kHz. This is exactly what happens with the RTC but you get
the added clock calibration circuitry that is probably not drawing to
much power but the added consumption of the configurable prescaler
versus the static prescaler of the RTC is probably similar.

Using RTC1HZ would be driving the RTT at 1Hz.

> > But this is very unlikely to happen because this would be limited to a
> > single board device tree instead of impact every sam9x60 based boards.
> 
> Very unlikely but a having a patch with diff like this:
> 
> +&gpbr {
> +     status = "okay";
> +};
> +
> +&rtt {
> +     atmel,rtt-rtc-time-reg = <&gpbr 0x0>;
> +     status = "okay";
> +};
> +
> 
> and reverting it may affect the other users of gpbr in sam9x60ek.dts.
> 

Again, this affects only sam9x60ek.dts instead of possibly multiple DTs
that may be out of tree. So the risk of doing that is null.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com