Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1543915pxu; Thu, 17 Dec 2020 12:30:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJx236ZuAW6w+wYapQp3hD7JrdRAyym7gKYc+8w+lTfMKL5Okl7f2YWEGl/OEgR2C/ukRQ0g X-Received: by 2002:a05:6402:1386:: with SMTP id b6mr1195944edv.42.1608237013460; Thu, 17 Dec 2020 12:30:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608237013; cv=none; d=google.com; s=arc-20160816; b=Nc4rV8+S0cGfs7sJQQKXNif0HyT1X6qQfB5XePNDZNiAChl9SY82JOFdeHEeaiCo12 j4Z1LYLWxOVfjVWaob3Cq97qY2qPgLEiO2K9f9h2Fn3AOxFcFWeB0ZflB1+YZuN7jJqA dClqTktVsQFrmJbC1v2xisrHuANA1RnuYLfDgzd//qcLzdQya67UOnbuh//2ndHmzncO 1eaSCUMXC5bdC7xiCOmQz/+6bIxKtl0nXJBCzylmyq+5c3reZ7DOshk0iNj0N3JiAzpO 5E4fk1E3K22qaZ/gIeLL7RCf/4Hf/jKYxbsSXu0SL68ROK3gQ/tthls/UkrcmruabKra jmIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=7wbMOCTf6tpjEH8mtEYbucPZty+RQkzYv1n+01JtUOA=; b=QzT2x7eGiikNWpkITNt+EGMTBZAJG6nar2OowwpPnrYXx7LQkDb+sFou/Yc29rsKFG UlKhJBLJxxZEDSSgTls7WE940beAs11lRvZpRVgwKoUwDkZF6wxKa3Jc6mzIwU0lrNPQ 6XikAnAa4IzzNBmBy8oUaUj2+Vc6sfGFwf2oPKj482RWti/vKihLEtOzwDZdTsFYRn+4 YpJUW8xXvIa1TdamsdT1i1za4DBR8eV+w6S/J+pGXl0SFNeZrlMiM2zKeM19XRR3CshE 4jFP4gW3NLag86xDZByHyvhzxj1vkZjVXsEUyRSMXELpZHMOgRO6GgrxhOfIOkwqvkwP F9Sw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lx16si3359294ejb.103.2020.12.17.12.29.44; Thu, 17 Dec 2020 12:30:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730315AbgLQU31 (ORCPT + 99 others); Thu, 17 Dec 2020 15:29:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730184AbgLQU31 (ORCPT ); Thu, 17 Dec 2020 15:29:27 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FA1DC0617A7 for ; Thu, 17 Dec 2020 12:28:47 -0800 (PST) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpztC-0003Wk-Nj; Thu, 17 Dec 2020 21:28:42 +0100 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1kpztB-0004Ur-TG; Thu, 17 Dec 2020 21:28:41 +0100 Date: Thu, 17 Dec 2020 21:28:41 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Rob Herring Cc: Rasmus Villemoes , "open list:REAL TIME CLOCK (RTC) SUBSYSTEM" , Alexandre Belloni , "linux-kernel@vger.kernel.org" , Qiang Zhao , Bruno Thomsen Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: add reset-source property Message-ID: <20201217202841.gcr5bxlaqpupiuu2@pengutronix.de> References: <20201204092752.GE74177@piout.net> <20201211215611.24392-1-rasmus.villemoes@prevas.dk> <20201211215611.24392-2-rasmus.villemoes@prevas.dk> <20201217181209.sibyhlfvlpjaewrv@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="didtc42d7qrszfpa" Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --didtc42d7qrszfpa Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 17, 2020 at 01:02:32PM -0600, Rob Herring wrote: > On Thu, Dec 17, 2020 at 12:12 PM Uwe Kleine-K=F6nig > wrote: > > > > On Thu, Dec 17, 2020 at 10:51:08AM -0600, Rob Herring wrote: > > > On Fri, Dec 11, 2020 at 5:10 PM Rasmus Villemoes > > > wrote: > > > > > > > > On 11/12/2020 23.30, Rob Herring wrote: > > > > > On Fri, Dec 11, 2020 at 3:56 PM Rasmus Villemoes > > > > > wrote: > > > > >> > > > > >> Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog.= But > > > > >> if the reset pin is not actually wired up, the driver exposes a > > > > >> watchdog device that doesn't actually work. > > > > >> > > > > >> Provide a standard binding that can be used to indicate that a g= iven > > > > >> RTC can perform a reset of the machine, similar to wakeup-source. > > > > > > > > > > Why not use the watchdog 'timeout-sec' property? > > > > > > > > Wouldn't that be overloading that property? AFAIU, that is used to = ask > > > > the kernel to program an initial timeout value into the watchdog de= vice. > > > > But what if one doesn't want to start the watchdog device at kernel > > > > boot, but just indicate that the RTC has that capability? > > > > > > Yeah, I guess you're right. > > > > I agree, too. The initial suggestion looks fine. > > > > > > It's quite possible that if it can act as a watchdog device (and > > > > has-watchdog was also suggested), one would also want timeout-sec a= nd > > > > other watchdog bindings to apply. But that can be added later, by t= hose > > > > who actually want that. > > > > > > > > For now, I'd really like to get my board booting again (or rather, = not > > > > get reset by the real watchdog just because the pcf2127 driver now > > > > exposes something as /dev/wathdog0, pushing the real one to > > > > /dev/wathcdog1 which doesn't get pinged from userspace). > > > > > > I'm wondering how you solve which wdog to ping when there are multiple > > > without relying on numbering. I guess 'reset-source' will solve that > > > even if that's not your current fix. So I guess I'm fine with this. > > > > I guess you'd need some udev magic that ensures that the right watchdog > > always gets the same number. >=20 > Why involve udev and keep the magic numbering important? Provide > enough details on watchdogs' features so an intelligent decision can > be made. It's the same thing every time folks try to number things in > DT. Note that it was you wanted to solve the more complicated problem about selecting the right watchdog from a set of several working watchdogs. The problem here is easier: We have machines with two watchdog devices and only one of them is actually working. So the straight forward thing to do is to not provide the watchdog device for the rtc chip that cannot reset the system. Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --didtc42d7qrszfpa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl/bv3YACgkQwfwUeK3K 7AnImgf9Fw73318x4WDmojLr4RhZjDZhjfvA6Gq6JqEHpz0ZbId8iNX6TO/DoUTn nHBQVUIGab9KfGzaLwkRoxPUw7x2H3CFCrXtOxfbetHLSh6w4nOuQDHhmsbakfN5 03ryeRsa00FuDjWbH/+jMSnGipfWrxJjPJ2jEkvH8ZE5TMo0DEP8dwZXkJcKlA4/ QMuNq0MjbhbyHwIuOCLGPOjkYan8dGflQfV/CbJUxEPaAFoqMv8tjFGW4u2FWdiq GZVVPnYGSp5OaOObox3XPPPqIOhRWvlV9w0W4cG7h5lEbdXT93VGWNsW68fr1FwY bAqy2R0tWm1JeACw8YgALQ7IsJ08Ag== =vFOg -----END PGP SIGNATURE----- --didtc42d7qrszfpa--