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: <DB9PR10MB465270EA5D6F25C44E68D1E580B09@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
Date:   Wed, 6 Oct 2021 09:30:14 +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 05 October 2021 14:43, Alexandre Ghiti wrote:

> > > > Thanks for the pointer! I have just tested this sequence from the
> > > > u-boot shell, it resets the board correctly. But then if we try to
> > > > power down the board by a long press to the corresponding button on
> > > > the board within 16 seconds, it resets the board: so we cannot
> > > > shutdown the board in the next 16 seconds that follow this sequence.
> > > >
> > > > Maybe that can be resolved by using the one-shot alarm as described by
> > > > Adam, I'll try to find that in the datasheet.
> > >
> > > After configuring the one-shot alarm, I still have those intempestive
> > > reboots if I try to power down the board by a long press within 16
> > > seconds. The only thing I found in the datasheet regarding this timing
> > > is in case of power undervoltage, not sure how this is linked to what
> > > I see.
> > >
> > > @Adam Thomson Any ideas?
> >
> > Nothing immediately springs to mind. Can you confirm this is the nONKEY long
> > press that you're attempting here, which is resetting the board rather than
> > shutting down?
>
> Yes, this is the nONKEY long press that, if done within ~16sec after
> the board is reset using the alarm, resets the board instead of
> shutting it down.
>
> >
> > Also, would you able to again provide events and fault log when this unwanted
> > reset occurs, just in case there's anything there to give a clue. Can then
> > discuss internally to see if we can ascertain what might be happening here.
>
> FAULT_LOG = 0x60
> EVENT_A = 0x12
> EVENT_B to EVENT_D = 0
>
> But I'm unsure of those values since they are the same after the reset
> triggered by the one-shot alarm *and* if I clear EVENT_A, the
> intempestive reboot does not appear!

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.

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)?