linux-kernel - RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <DB9PR10MB46524AA5496F513E34A2BF2480AA9@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
Date:   Thu, 30 Sep 2021 10:47:57 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Alexandre Ghiti <alexandre.ghiti@...onical.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC:     Support Opensource <Support.Opensource@...semi.com>,
        Lee Jones <lee.jones@...aro.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation

On 30 September 2021 10:38, Alexandre Ghiti wrote:

> > Regardless of this though, the consensus right now would be to use the RTC as
> a
> > wake event to restart the platform. An alarm can be set for a couple of seconds
> > into the future (or longer if required) and that would provide the event
> > required to come up from powerdown/shutdown, in the absence of
> AUTOBOOT being
> > set in OTP. I believe this would be the safest route to take in this case. You
> > can then just use the SHUTDOWN bit on CONTROL_F to take down the board.
> >
> > To reiterate, I believe this should be made a board specific quirk, rather than
> > as part of the generic MFD core of DA9063, as the timings may vary for other
> > platforms.
>
> What timings are you referring to? Is the timing you're talking to the
> time between the shutdown and the tick that wakes the device up?

That was one of the considerations.....

> Because I have another series ready which uses a new device tree
> binding so that platforms that want the reset from the DA9063 can ask
> for it via the device tree. And then I could add a property "duration"
> that is platform dependent.

... but having thought further on this. Say you use this approach within the
kernel then you're limiting that platform to immediate reboots are you not?
What happens if you say wanted to shutdown the platform, then reboot at some
more distant future point using the RTC? In this case that option is then off
the table as the kernel hard codes this and overrides any existing alarm.

I don't believe there's anything to stop us configuring an RTC alarm from
user-space, prior to the reboot/shutdown being triggered, and that can act as an
'immediate' restart or, if the user requires, a delayed wake could also used if
necessary.

Of course none of this resolves the watchdog case if that's used, but am not
sure if that's included/used in your setup.