Message-ID: <20120807134750.GI24257@flint.arm.linux.org.uk>
Date:	Tue, 7 Aug 2012 14:47:50 +0100
From:	Russell King <rmk@....linux.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Haojian Zhuang <haojian.zhuang@...il.com>, sameo@...ux.intel.com,
	rpurdie@...ys.net, bryan.wu@...onical.com,
	linux-kernel@...r.kernel.org, Bergmann Arnd <arnd@...db.de>
Subject: Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM

On Tue, Aug 07, 2012 at 01:58:20PM +0100, Mark Brown wrote:
> 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.

Well, stop causing frustration at this end.  Yes, you're the cause of my
frustration, because you're doing everything you possibly can to give
reasons why not without even looking at the facts.  And you continue to
do so at the bottom of this mail.

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.

As far as I'm concerned, your arguments so far against my proposal are
all completely and utterly petty, and that's putting it mildly.

> 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.

> > 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.

Right, thank you, finally you've said something constructive at last.
But I'm all out of patience with you to create a patch; you've wasted
all my good will away through your petty arguments.

> > 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.

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.

Maybe you should be the one to take a step back and look at the quality
of your replies in this thread.  Because none of them have been
constructive.

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.

> > 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.

"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?

So yet again, this is another bloody whinge from you about why not.

So I'm wasting my time on this thread.  Someone else can fix the other
driver in the way I've outlined.  I've shown you how.  I've shown you
that there's agreement from other people for my approach.  There isn't
an issue with -stable with this approach.  There isn't an issue with
-rc.

All it needs is for someone to do the search and replace on the relevant
drivers.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists