Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948321AbdDYT6r (ORCPT ); Tue, 25 Apr 2017 15:58:47 -0400 Received: from mail.kernel.org ([198.145.29.136]:59904 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1176113AbdDYT6l (ORCPT ); Tue, 25 Apr 2017 15:58:41 -0400 MIME-Version: 1.0 In-Reply-To: <20170425165824.GA10024@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> From: Moritz Fischer Date: Tue, 25 Apr 2017 12:58:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/2] DS1374 Watchdog fixes To: Guenter Roeck 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1459 Lines: 37 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 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? > > > > > 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