From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::433; helo=mail-wr1-x433.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B371F2119EF23 for ; Tue, 18 Dec 2018 04:50:03 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id l9so15733843wrt.13 for ; Tue, 18 Dec 2018 04:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=XlF0JvBegGgS2L0gwMrGSQra76ksgUYO7aNnFeoHcOo=; b=FQZSAGFZ7Ok4IADWY81Q+zxAdbfAEw1tXTJ20bVoeIdIYwKlMKU8hqEBYC7Ri/iQMO +3A0PEGqZ+DvoY397anE2DZSOtpKjx5iNYWJJjQ6u/VkihWc4pxqZnGGp7mc/Kin3K/b Be2BwzyGv/NU4QbNTiBiGb6CM/6yJs8Knmgpo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=XlF0JvBegGgS2L0gwMrGSQra76ksgUYO7aNnFeoHcOo=; b=JqKD2s7lMV570eIoKNWuinKj29s9M7v+rioKYfE8Xa8ox2Ko6ehH7JcGl8M5F3u8Xq JX2p0BtfCEsJKWPWKFMWt/LOGg1zQLba14KL/WWGoWzAx7tesd/ARpG4S6ZqoRmw/Van guqLkAIkfVB2vbd0uhz4WLGsM1AiNwWsfFHbsDPphnsZdxpNONozz1r2Eveqx1/apyzN iLY6N1ZXNpjx2Bmnoe0+4SKYTdZYrhcOKFfwXU+4R7SHybxcutTtIxtU9gkMZSt4rHRp AF8BxqQyFdz8Lh6byBox2ooboDELGs5qrNwlD7Cq2rb2ZETc7B3Z3PHpKBZ4MCXkdMaw S8ig== X-Gm-Message-State: AA+aEWZL9iR8vqSl862IbGOMZPuR6wSuB4JmSdX+agqmFX5+ARh8S0lO LmXB2az1I1+TldUU/6VhJgLi7XncMpo= X-Google-Smtp-Source: AFSGD/VTQJ1Sd3CRgkShtWy10/BBruVVwiw8yItG5D0mOp26FN9nKVdAFxix+qgfMZ/sKhfDKcCQmA== X-Received: by 2002:adf:b243:: with SMTP id y3mr15137326wra.184.1545137401635; Tue, 18 Dec 2018 04:50:01 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id r12sm4835784wrq.3.2018.12.18.04.50.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 18 Dec 2018 04:50:00 -0800 (PST) Date: Tue, 18 Dec 2018 12:49:58 +0000 From: Leif Lindholm To: Udit Kumar Cc: Meenakshi Aggarwal , Sami Mujawar , Thomas Panakamattam Abraham , Ard Biesheuvel , "edk2-devel (edk2-devel@lists.01.org)" , Ming Huang , Heyi Guo , Matteo Carlini , Nariman Poushin Message-ID: <20181218124958.iziphtwopl5nyrlx@bivouac.eciton.net> References: <20181218092626.juymiyl3yxjfqclb@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: SP805 driver X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 12:50:04 -0000 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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