From: Moritz Fischer <mdf@kernel.org> To: Guenter Roeck <linux@roeck-us.net> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Moritz Fischer <moritz.fischer@ettus.com>, 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 Date: Tue, 25 Apr 2017 12:58:36 -0700 [thread overview] Message-ID: <CAJYdmePpHcYgjiCf=eWCkBBNBTTw4jW59_VNR6w44Yj_QDQqng@mail.gmail.com> (raw) In-Reply-To: <20170425165824.GA10024@roeck-us.net> 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
WARNING: multiple messages have this Message-ID (diff)
From: Moritz Fischer <mdf@kernel.org> To: Guenter Roeck <linux@roeck-us.net> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Moritz Fischer <moritz.fischer@ettus.com>, linux-watchdog@vger.kernel.org, wim@iguana.be, a.zummo@towertech.it, rtc-linux@googlegroups.com, alex.williams@ni.com Subject: [rtc-linux] Re: [PATCH 0/2] DS1374 Watchdog fixes Date: Tue, 25 Apr 2017 12:58:36 -0700 [thread overview] Message-ID: <CAJYdmePpHcYgjiCf=eWCkBBNBTTw4jW59_VNR6w44Yj_QDQqng@mail.gmail.com> (raw) In-Reply-To: <20170425165824.GA10024@roeck-us.net> 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 -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2017-04-25 19:58 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-24 22:05 [PATCH 0/2] DS1374 Watchdog fixes Moritz Fischer 2017-04-24 22:05 ` [rtc-linux] " Moritz Fischer 2017-04-24 22:05 ` [PATCH 1/2] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks Moritz Fischer 2017-04-24 22:05 ` [rtc-linux] " Moritz Fischer 2017-05-04 12:47 ` Alexandre Belloni 2017-05-04 12:47 ` [rtc-linux] " Alexandre Belloni 2017-04-24 22:05 ` [PATCH 2/2] rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL Moritz Fischer 2017-04-24 22:05 ` [rtc-linux] " Moritz Fischer 2017-05-04 12:47 ` Alexandre Belloni 2017-05-04 12:47 ` [rtc-linux] " Alexandre Belloni 2017-04-25 5:03 ` [PATCH 0/2] DS1374 Watchdog fixes Guenter Roeck 2017-04-25 5:03 ` [rtc-linux] " Guenter Roeck 2017-04-25 14:55 ` Moritz Fischer 2017-04-25 14:55 ` [rtc-linux] " Moritz Fischer 2017-04-25 16:17 ` Guenter Roeck 2017-04-25 16:17 ` [rtc-linux] " Guenter Roeck 2017-04-25 16:32 ` Alexandre Belloni 2017-04-25 16:32 ` [rtc-linux] " Alexandre Belloni 2017-04-25 16:58 ` Guenter Roeck 2017-04-25 16:58 ` [rtc-linux] " Guenter Roeck 2017-04-25 19:58 ` Moritz Fischer [this message] 2017-04-25 19:58 ` Moritz Fischer 2017-04-25 20:22 ` Guenter Roeck 2017-04-25 20:22 ` [rtc-linux] " Guenter Roeck 2017-04-25 20:34 ` Moritz Fischer 2017-04-25 20:34 ` [rtc-linux] " Moritz Fischer 2017-04-25 21:05 ` Guenter Roeck 2017-04-25 21:05 ` [rtc-linux] " Guenter Roeck
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAJYdmePpHcYgjiCf=eWCkBBNBTTw4jW59_VNR6w44Yj_QDQqng@mail.gmail.com' \ --to=mdf@kernel.org \ --cc=a.zummo@towertech.it \ --cc=alex.williams@ni.com \ --cc=alexandre.belloni@free-electrons.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-watchdog@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=moritz.fischer@ettus.com \ --cc=rtc-linux@googlegroups.com \ --cc=wim@iguana.be \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.