public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Udit Kumar <udit.kumar@nxp.com>
Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Thomas Panakamattam Abraham <thomas.abraham@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"edk2-devel (edk2-devel@lists.01.org)" <edk2-devel@lists.01.org>,
	Ming Huang <ming.huang@linaro.org>,
	Heyi Guo <heyi.guo@linaro.org>,
	Matteo Carlini <Matteo.Carlini@arm.com>,
	Nariman Poushin <nariman.poushin@linaro.org>
Subject: Re: SP805 driver
Date: Tue, 18 Dec 2018 12:49:58 +0000	[thread overview]
Message-ID: <20181218124958.iziphtwopl5nyrlx@bivouac.eciton.net> (raw)
In-Reply-To: <VI1PR04MB4640BEBB49E82DE67566A62591BD0@VI1PR04MB4640.eurprd04.prod.outlook.com>

On Tue, Dec 18, 2018 at 12:30:34PM +0000, Udit Kumar wrote:
> > > >"If no handler has been registered, or the registered handler
> > > >returns, then the system will be reset by calling the Runtime Service
> > > >ResetSystem()."
> > > I believe,  this handler needs to be called by wdt driver after wdt is
> > > expired. Meaning , we want wdt to work without resetting the system.
> > > Therefore a mask is needed with wdt, which will prevent to reset the
> > > system.   I see it working, at least for SP805, because of PMU mask
> > > bits.
> > 
> > Yes, if the WDT can be configured to generate an interrupt instead of a
> > hardware reset, it can be used to implement this protocol.
> 
> Here I am just thinking of one condition , some application started the wdt
> and CPU got stuck somewhere in ISR routine, 
> Now this wdt is expired. We will end up in hang system. 
> I agree doing reset in graceful manner is always great, but In this case, resetting the 
> as it is, will be more useful. 
> 
> Thought ? 

The short answer is:
That would violate the specification, so what is the purpose of
debating the merit?

The longer answer is:
The comparison conflates software and hardware watchdogs. There is
nothing saying a system couldn't have both.

But giving someone a hardware watchdog when they explicitly ask for a
software one is not OK.

> > > Also ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c has this
> > limitation.
> > > I haven’t read spec of this wdt.  I hope there should a mask around.
> > 
> > No, the situation for the GenericWatchdogDxe is not as dire.
> > 
> > Correct: it does not permit registering software handlers (which perhaps we
> > should do something about, but is ... acceptable).
> > 
> > _But_, it still conforms to the above text; when the timer expires, it resets the
> > system by calling the ResetSystem() service. It does not directly force a
> > hardware reset.
> 
> Hmm, this does partly by calling  ResetSystem(), however this does not 
> Allow to install handler in WatchdogRegisterHandler.

As I said, it's acceptable - it's not ideal.

> > The severe problem is not the lack of the ability to register the software handler
> > (which does remove much of the utility), but the removal of reset control from
> > the system firmware.
> > 
> > > Coming back to hardware, which does not have mask around wdt, how to
> > > implement this feature.
> > 
> > Simple - you can't.
> > 
> > You can absolutely implement exactly the functionality you have today, with
> > minimal changes to the protocol - it just should not be registered as an
> > implementation of EFI_WATCHDOG_TIMER_ARCH_PROTOCOL.
> 
> I believe,  EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is must 
> Are you suggesting to EFI_WATCHDOG_TIMER_ARCH_PROTOCOL from MdeModulePkg
> and hook platform specific code with this.
> Or simply register EFI_WATCHDOG_TIMER_ARCH_PROTOCOL with dummy functions.

Are you referring to
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf?

That is certainly what most of the platforms in edk2-platforms use.

The EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is used by core code.

If you want to use your hardware watchdog as part of your platform
specific code, that is absolutely fine and probably a very good idea -
but it has nothing to do with this protocol. There is nothing forcing
you to use the platform-independent EFI_WATCHDOG_TIMER_ARCH_PROTOCOL
for this.

Regards,

Leif


  reply	other threads:[~2018-12-18 12:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-17 12:55 SP805 driver Leif Lindholm
2018-12-18  5:20 ` Udit Kumar
2018-12-18  9:26   ` Leif Lindholm
2018-12-18 12:30     ` Udit Kumar
2018-12-18 12:49       ` Leif Lindholm [this message]
2018-12-18 12:57         ` Udit Kumar
2018-12-18 13:16           ` Leif Lindholm
2018-12-18  7:13 ` Thomas Abraham
2018-12-20 15:00 ` Ming Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181218124958.iziphtwopl5nyrlx@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox