Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1954127AbdDYUWW (ORCPT ); Tue, 25 Apr 2017 16:22:22 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:36325 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033572AbdDYUWO (ORCPT ); Tue, 25 Apr 2017 16:22:14 -0400 Date: Tue, 25 Apr 2017 13:22:10 -0700 From: Guenter Roeck To: Moritz Fischer Cc: 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: <20170425202210.GA20929@roeck-us.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2145 Lines: 52 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: > > > 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 that > > problem either. > > How does one do these things in a non-dt context? Platform data? I'd let Platform data is out of favor. You'd probably want to use device properties (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 ? > 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? > 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. Guenter > > > > > > > The idea was to fix what's broken currently (this patchset) and then refactor. > > > > > But if you prefer I can do all in one go instead. > > > > > > > > > > > > > It just seemed a waste to me to change/fix a function which is going to > > > > be removed in a subsequent patch (I seem to recall that there was a fix > > > > to the ioctl function). > > > > > > > > > > I'd say that it depends on whether you want to backport the fixes to the > > > stable kernels. Backporting the full rework is probably riskier. > > I suck at communicating these days. But yeah. That was basically my > concern when I split it up into 'Fixes' and 'Rework'. > > Mostly since the rework might take a couple of rounds of review, while the > fix can unbrick stuff (might still need review of course) > > Cheers, > > Moritz