Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993557AbdDYUe2 (ORCPT ); Tue, 25 Apr 2017 16:34:28 -0400 Received: from mail-pf0-f172.google.com ([209.85.192.172]:36662 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993479AbdDYUeU (ORCPT ); Tue, 25 Apr 2017 16:34:20 -0400 Date: Tue, 25 Apr 2017 13:34:18 -0700 From: Moritz Fischer To: Guenter Roeck Cc: Moritz Fischer , Alexandre Belloni , Linux Kernel Mailing List , Moritz Fischer , linux-watchdog@vger.kernel.org, wim@iguana.be, a.zummo@towertech.it, rtc-linux@googlegroups.com, alex.williams@ni.com Subject: Re: [PATCH 0/2] DS1374 Watchdog fixes Message-ID: <20170425203418.GA5198@tyrael.amer.corp.natinst.com> References: <1493071512-5718-1-git-send-email-mdf@kernel.org> <5f8fac22-4037-9983-436a-da8ff87d4b17@roeck-us.net> <20170425161743.GA8443@roeck-us.net> <20170425163204.rj6on6phtbfuvcd7@piout.net> <20170425165824.GA10024@roeck-us.net> <20170425202210.GA20929@roeck-us.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20170425202210.GA20929@roeck-us.net> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2404 Lines: 64 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 25, 2017 at 01:22:10PM -0700, Guenter Roeck wrote: > On Tue, Apr 25, 2017 at 12:58:36PM -0700, Moritz Fischer wrote: > > On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote: > >=20 > > > Ah, I missed the "n" in various #ifndef statements. > > > > > > I can't really comment on how to solve that; I simply don't know. > > > Also, even with a dt property, it still would be necessary to have > > > a non-DT means to configure one or the other. Making whatever solution > > > backward compatible also seems tricky; I don't have a solution for th= at > > > problem either. > >=20 > > How does one do these things in a non-dt context? Platform data? I'd let >=20 > Platform data is out of favor. You'd probably want to use device properti= es > (see drivers/base/property.c). Question though is if this is considered > configuration, hardware description, or both. Presumably the watchdog > only makes sense if the reset signal is wired, and the alarm only makes > sense if the interrupt is wired, but what if both are wired ? To make things worse you can even remap the reset output to the INT pin (which my platform does). I'll look at device properties. Thanks for the pointer. >=20 > > the MFD select the 'mode'. Maybe being backwards compatible isn't > > possible in any case. Is there a rule somewhere that we guarantee you'll > > never have to change your CONFIG_FOO options? > >=20 >=20 > That would be nice, but no, there is no such rule. You can probably argue > that no published kernel configuration enables the watchdog flag, > so there is nothing to be concerned about. Alright, cool. Thanks Moritz PS: Haven't forgotten about the cros-ec-hwmon patch that I sent out ... --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY/7LIAAoJEL5CEHepFqovVpoH/1FwUNaM2zIcIphrC0jGHymw oM/daop21kfI7h0MDjgzGE4PJVyA0Xe4gFr+rVeO858Xvk9k3ZFR2cWYia3NhkWm xM0uo5mgFV1qNsd2fqg7j91319b6YKy0RBHSn/sFC91LEgu8/ssG/RucphUcL4pz Kmcfe8bbhmQ/xagp0VzwWyUu2ZRxo479zvy5uSyo7DI39PoCz/xuPgEAJROU8sqU 0oCDZkwT/zjKL0G7ZZFQ/hQg5QEs+3N1Rx68azGqS50sNteX6NxvZRJdowMu0tFX HWdaAuI8tBqMAiPwRBgO5ZXL8Rs4IbrqtvipsAqXbYdyVyhm6SGsc1hECTg0h6U= =dZxG -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--