public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>,
	sameo@linux.intel.com, rpurdie@rpsys.net, bryan.wu@canonical.com,
	linux-kernel@vger.kernel.org, Bergmann Arnd <arnd@arndb.de>
Subject: Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM
Date: Tue, 7 Aug 2012 16:54:45 +0100	[thread overview]
Message-ID: <20120807155445.GO16861@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120807134750.GI24257@flint.arm.linux.org.uk>

On Tue, Aug 07, 2012 at 02:47:50PM +0100, Russell King wrote:

> If you want to be constructive, then actually take a bloody look at my
> suggestion, try it out and report back whether it works.  Stop attacking
> my proposal in whatever weak ways you can, especially in ways that I've
> already dismissed as being totally irrelevant.

I have looked at your suggestion, and I have repeatedly agreed that your
suggestion is the best suggestion going forwards.  I don't think there
is any way in which I could be clearer on that.

> > My concern there (and that of others who've looked at adding a new
> > resource type) is that this value can also be written as

> >   #define IORESOURCE_FOO (IORESOURCE_IO | IORESOURCE_MEM)

> > and the selection of values chosen for the resource types clearly looks
> > like it's supposed to be interpreted as a bitmask for some reason.  This
> > is the main reason nobody touched the code already, it sets off alarm
> > bells from a code review point of view.

> Sigh.  Here we go a fucking again.  I've already covered this.  But
> in case you haven't read, here it is again.

> And that combination is illegal today.  But the amount of code which
> the value will be exposed to is limited to _just_ the platform code,
> which, for the parts affeced, I'm the author of.  And I've read it
> before creating the patch to make sure it will work as I expect it
> do.

Well, I guess we have to agree to disagree on that.  I'm just very much
more conservative than you about what I'd be willing to put into a
stable release - my instincts on this are very strongly towards avoiding
any possibility of introducing unintended side effects and one way of
doing that is minimising the scope of any change.  Even where things
should be correct and look correct minimising the risk of exposing any
latent bugs (including those in systems derived from the stable release)
is a major consideration for me with any sort of stable fix.  Clearly
any code that's affected is buggy but having people be able to trust
stable releases is a very big factor.

This is all that we're disagreeing on, everyone including me agrees that
your change is clearly the best change going forwards but I'm much more
paranoid about stable releases than you are.

> > You've only asked this once that I've seen, in the mail where you posted
> > your patch (which is a helpful step forward, thanks!) which very recent.
> > It's possible that you've asked this elsewhere, though I did just scan
> > through a good chunk of the mails and didn't see the question.

> Twice I asked.  The first time was with the IORESOURCE_FOO mail, which
> you had time to read, and reply to - and your reply was yet another
> "why we can't do it this way" whinge.  Yes, you had time to read it,
> you had time to answer it with reasons why not, but not to give any
> useful information back.

Hrm, if you're referring to <20120807111331.GC24257@flint.arm.linux.org.uk>
I don't actually seem to be able to see the question in your mail.

> Instead, you'll notice that many of my replies have been outlining
> solutions to the problem, and *actually* contain patches to address
> the issue.  Yours?  All whinges about why not.

The main reason I haven't send any patches was that by the time we were
satisfied that this was OK people were already sending code changes so
it seemed like that was in hand (and indeed you have sent a patch for
this).

> > As I keep saying I don't think there's been any disagreement that adding
> > one or more new resource types is the best approach going forward, the
> > only issues have been around what happens in stable and someone having
> > the time to add the new resource type.

> "someone having the time to add the new resource type" ?  Oh for fuck sake
> Mark, what the hell are you talking about?  How long does it take to apply
> a bloody patch?

It's the bit with confirming that we're OK not treating the resource
types as a bitmask that's time consuming; until this thread nobody had
gone through and checked that this would be OK.

  reply	other threads:[~2012-08-07 15:54 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-05 16:32 [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM Haojian Zhuang
2012-08-05 16:32 ` [PATCH 1/5] mfd: use IORESOURCE_MEM in 88pm860x backlight Haojian Zhuang
2012-08-05 16:32 ` [PATCH 2/5] mfd: use IORESOUCE_MEM in 88pm860x leds driver Haojian Zhuang
2012-08-05 16:32 ` [PATCH 3/5] mfd: use IORESOURCE_MEM in 88pm860x regulator Haojian Zhuang
2012-08-05 16:32 ` [PATCH 4/5] mfd: avoid to return failure in 88pm860x Haojian Zhuang
2012-08-05 16:32 ` [PATCH 5/5] ARM: mmp: enable 88pm860x in ttc dkb Haojian Zhuang
2012-08-06 14:30 ` [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM Mark Brown
2012-08-06 14:42   ` Haojian Zhuang
2012-08-06 15:46     ` Mark Brown
2012-08-06 15:56       ` Haojian Zhuang
2012-08-06 15:58         ` Mark Brown
2012-08-06 19:22           ` Russell King
2012-08-06 19:53             ` Mark Brown
2012-08-06 21:31               ` Russell King
2012-08-06 22:00                 ` Mark Brown
2012-08-07  1:47                   ` Haojian Zhuang
2012-08-07  7:58                     ` Russell King
2012-08-07  8:24                     ` Benjamin Herrenschmidt
2012-08-07 10:38                     ` Mark Brown
2012-08-07 11:13                       ` Russell King
2012-08-07 11:28                         ` Mark Brown
2012-08-07 11:31                           ` Russell King
2012-08-07 11:36                             ` Russell King
2012-08-07 11:45                               ` Mark Brown
2012-08-07 11:51                                 ` Russell King
2012-08-07 12:58                                   ` Mark Brown
2012-08-07 13:47                                     ` Russell King
2012-08-07 15:54                                       ` Mark Brown [this message]
2012-08-07 15:22                                   ` Geert Uytterhoeven
2012-08-07 15:44                                     ` Russell King
2012-08-07 16:48                                       ` Mark Brown
2012-08-07 20:51                                     ` Arnd Bergmann
2012-08-07 11:38                             ` Mark Brown
2012-08-07 11:44                               ` Russell King
2012-08-07 12:11                                 ` Russell King
2012-08-07 13:25                                   ` Mark Brown
2012-08-07 14:28                                     ` Arnd Bergmann
2012-08-07 14:41                                       ` Russell King
2012-08-07 16:36                                       ` Mark Brown
2012-08-07  8:22                 ` Benjamin Herrenschmidt
2012-08-07  8:28                   ` Russell King
2012-08-07 11:28                     ` Arnd Bergmann
2012-08-07 11:32                       ` Russell King
2012-08-07 11:34                         ` Arnd Bergmann
2012-08-07 11:35                       ` Mark Brown
2012-08-07 11:41                         ` Russell King
2012-08-07 15:45                           ` Alan Cox
2012-08-07 15:50                             ` Russell King

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=20120807155445.GO16861@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=arnd@arndb.de \
    --cc=bryan.wu@canonical.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=rpurdie@rpsys.net \
    --cc=sameo@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox