All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.