From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A3BBC2BA19 for ; Wed, 15 Apr 2020 22:29:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5420120774 for ; Wed, 15 Apr 2020 22:29:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="gXSGbTR0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732133AbgDOW3s (ORCPT ); Wed, 15 Apr 2020 18:29:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1732109AbgDOW3n (ORCPT ); Wed, 15 Apr 2020 18:29:43 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C119AC061A0F for ; Wed, 15 Apr 2020 15:29:42 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id b12so18944668ion.8 for ; Wed, 15 Apr 2020 15:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PVtGYrIeBI2+9xVgD4LCkJpnGBHTWG+8tKFXeAJgTRU=; b=gXSGbTR09MscBjxHvvT6Zy0GE7nYGjJ8nQRhWPJMjuaPZPTM411vSTxLoPH1wb/lRH E6Z4jtglLRMXQKommS2CbxodCJi11rjz7cgYPRAWFMxtk1Sc3UXB1U2xuagdbDr83VUY 5gnHcn+7SSgE8W9/iOMJ1SOy7cFoMYxBGg8EM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PVtGYrIeBI2+9xVgD4LCkJpnGBHTWG+8tKFXeAJgTRU=; b=dJA3OSz8ENq5aoWhZ/ipoR78y7VFaMVpq7T4JEH9p45r1xgXgaI+TwrRLXuTfIkfzR RqNyUxiahuYfEzgbMf4i1VlfJNzorys45bF5qZkBc9ktIMncvfNy7hU6iYUVFLiYUsyx EO35TjIyIH+tuJjgIxBrPxkxdlyvC9fgcPQd3Atxx2K/HR2Eom107dNGmgkzyNrdP/2/ 1S/ovSxTgE/hwHald7PGPIwKRH1dOj/0XocRMIZikWr2vDhMBgzspERW5lgxnYlIEVaO 6kYVwhWQFSgDNNMU82eECTuUHGU7CGWMrUjcuuRSpbIY1thQHcbKNyYnG0anM5FmJJZq MC3A== X-Gm-Message-State: AGi0PubqF8gG9y48S4nRMD+wbjqUJv+YHXLAQsI2KgFJNQBaYg8xd+o5 hw6UOArBVUF4xPpUU/pRpZ77lJz5CpAWd2rcenxPeA== X-Google-Smtp-Source: APiQypJ3eoCymVEhOWkVktr1qddf2Xa0knAtkx0Gy+/ySRR66TTx2i5h4oQ94XSCgON3AJO5/Bo8xzGkGGc86wd33Kk= X-Received: by 2002:a05:6602:1302:: with SMTP id h2mr28555486iov.186.1586989781796; Wed, 15 Apr 2020 15:29:41 -0700 (PDT) MIME-Version: 1.0 References: <20200403052900.258855-1-evanbenn@chromium.org> <890948ef-7276-fdae-d270-eb30eff3eab2@amlogic.com> <243e107c-35c1-2d14-5285-c9e13744963c@amlogic.com> In-Reply-To: <243e107c-35c1-2d14-5285-c9e13744963c@amlogic.com> From: Julius Werner Date: Wed, 15 Apr 2020 15:29:29 -0700 Message-ID: Subject: Re: [PATCH v2 0/2] Add a watchdog driver that uses ARM Secure Monitor Calls. To: Xingyu Chen Cc: Evan Benn , LKML , Julius Werner , Andy Shevchenko , Anson Huang , Bjorn Andersson , Catalin Marinas , "David S. Miller" , Greg Kroah-Hartman , Guenter Roeck , Jonathan Cameron , Leonard Crestez , Manivannan Sadhasivam , Marcin Juszkiewicz , Mark Rutland , Matthias Brugger , Mauro Carvalho Chehab , Olof Johansson , Rob Herring , Rob Herring , Shawn Guo , Valentin Schneider , Vinod Koul , Will Deacon , Wim Van Sebroeck , devicetree@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "moderated list:ARM/Mediatek SoC support" , LINUX-WATCHDOG , Jianxin Pan , Yonghui Yu , "open list:ARM/Amlogic Meson..." Content-Type: text/plain; charset="UTF-8" Sender: linux-watchdog-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-watchdog@vger.kernel.org > In addition, It looks more reasonable to use the "msec" as the unit of > timeout parameter for the ATF fw interface with SMCWD_SET_TIMEOUT: > > - The fw interface will compatible with the uboot generic watchdog > interface at [0], and there is no need to convert timeout from msec > to sec. I think we're trying hard to keep this compatible to a Trusted Firmware counterpart that we have already shipped, so we would prefer to keep it at seconds if possible. That's what the Linux watchdog core uses as well after all, so it just seems natural. I don't really see how what U-Boot does would have anything to do with this. > - Some vendor's watchdog may be not support the "wdt_trigger_reset" > reset operation, but they can use the method below to reset the system > by the watchdog right now. > > watchdog_set_time(1); //1ms > watchdog_enable(); They can still do that but they should do that on the Trusted Firmware side. Emulating a missing reset functionality should be handled by the hardware abstraction layer (in this case Trusted Firmware), not at the Linux API level. So Linux would still send a PSCI_SYSTEM_RESET SMC, but then Trusted Firmware can choose to implement that by setting the watchdog to the smallest possible timeout (which it can because it's accessing it directly, not through this SMC interface) and letting it expire.