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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <DB9PR10MB46521072770D6A1C75DEE08380B29@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
Date:   Fri, 8 Oct 2021 09:46:04 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Alexandre Ghiti <alexandre.ghiti@...onical.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC:     David Abdurachmanov <david.abdurachmanov@...il.com>,
        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 06 October 2021 12:36, Alexandre Ghiti wrote:

> > Thanks for the info. So we believe, based on the event registers values
> > provided, it is the RTC event as that's not cleared by a power-cycle (it's in
> > the always-on domain). The other test would be to mask this event
> immediately
> > after an RTC based reboot and see if the long key-press then shuts down the
> > device. I suspect it would in that case, as per you clearing the event.
> 
> Indeed if I mask the RTC alarm in IRQ_MASK_A, the intempestive reboot
> disappears. But that's not something we can do: the reset driver will
> actually be implemented in openSBI at some point where the devices are
> probed on-demand (the same applies to u-boot I think), so we cannot
> clear or mask anything at boot.
> 
> >
> > I'm still curious as to the 16 seconds though. Would that be when the kernel
> > finally starts and masks/clears events (seems quite a long time)?
> 
> No, the kernel is not up yet. Maybe 16sec is not the right value, I
> may have been influenced by the discussion here
> https://www.dialog-semiconductor.com/products/pmics?post_id=10052#tab-
> support_tab_content.
> 
> It seems there is some consensus about having this reset driver be a
> SiFive Unmatched board specific thing: quid of the sequence I propose
> in this patch then? It does not mess with the RTC registers, it
> reboots reliably and there's no intempestive reboot: is it dangerous
> to use? Or do you have another alternative?

Yes, a board specific implementation would be the way to go. We're just checking
through the sequence again to be absolutely sure of any pitfalls that may 
present themselves, and will get back to you when we have something more.