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 13:58:20 +0100	[thread overview]
Message-ID: <20120807125820.GD16861@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120807115140.GH24257@flint.arm.linux.org.uk>

On Tue, Aug 07, 2012 at 12:51:40PM +0100, Russell King wrote:

> For fuck sake Mark.  You are insane.

Please take a step back from the ad hominem remarks.

> How can:

> #define IORESOURCE_FOO 0x00000300

> in ioport.h be called "invasive" ?  The best chance of error is that the
> identifier is already in use.  So learn to use grep to check the whole
> sodding tree first to make sure that the identifier you're choosing to
> use isn't already in use somewhere.

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.

It may well be the case that the constants are only ever viewed as plain
old numbers in which case we're fine but it really doesn't seem too
clevr for stable.

> And in any case, I suspect you've lost the plot, because I suspect the
> driver you are referring to is wm831x, which has already had your solution
> patched into it by you back in May.

The urgent issue is for the Marvell PMIC drivers (drivers/mfd/88pm*)
which are also affected but have not had a fix implemented so have been
broken since v3.4.  The wm831x drivers should be updated to use the new
API too but don't now have an issue in stable right now.  There may be
others but presumably they're not even testing stable releases so again
probably not urgent.

> And you still haven't done me the curtesy of answering my repeated
> questions about WHAT BLOODY DRIVER you are referring to has the problem.

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.

> There is no point in discussing this any further unless you START answering
> some of the basic questions, rather than constantly trying to poke holes
> in a solution you did not invent.  (Do you suffer from not-invented-here
> syndrome?  Because you *are* showing all the signs of that.)

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.

  reply	other threads:[~2012-08-07 12:58 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 [this message]
2012-08-07 13:47                                     ` Russell King
2012-08-07 15:54                                       ` Mark Brown
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=20120807125820.GD16861@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