From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Pisati <p.pisati@gmail.com>
Date: Fri, 10 Feb 2017 16:18:37 +0100
Subject: [U-Boot] [PATCH] bcm2835_wdt: support for the BCM2835/2836
 watchdog
In-Reply-To: <2765682.6PCLvXzOU7@sbruens-linux>
References: <1485511145-31425-1-git-send-email-p.pisati@gmail.com>
 <1485511145-31425-2-git-send-email-p.pisati@gmail.com>
 <2765682.6PCLvXzOU7@sbruens-linux>
Message-ID: <20170210151837.GA22442@harukaze>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Fri, Jan 27, 2017 at 04:20:10PM +0000, Br?ns, Stefan wrote:
> > ...
> > +
> >  __efi_runtime_data struct bcm2835_wdog_regs *wdog_regs =
> >  	(struct bcm2835_wdog_regs *)BCM2835_WDOG_PHYSADDR;
> > 
> > -void __efi_runtime reset_cpu(ulong addr)
> > +void __efi_runtime reset_cpu(ulong ticks)
> >  {
> > -	uint32_t rstc;
> > +	uint32_t rstc, timeout;
> > +
> > +	if (ticks == 0) {
> > +		hw_watchdog_disable();
> > +		timeout = RESET_TIMEOUT;
> 
> This is wrong. The efi runtime reset function calls this as reset_cpu(0), and 
> then tries to call hw_watchdog_disable, which is not marked as __efi_runtime.

Ok.
 
> Actually, I can see no reason the watchdog setup piggybacks on the reset_cpu 
> funtion.

Because there's a window after reset_cpu() is called but before real reset happens,
and if hw_watchdog_reset() is called in between, it breaks the reset procedure.

There must be a mechanism for reset_cpu() to disable the watchdog driver so it
won't interfere.

> 
> I think the rule is no new CONFIG_xxx options, but appropriate options in 
> KConfig.

I'll send a V2.
-- 
bye,
p.