Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754633Ab2HGNsI (ORCPT ); Tue, 7 Aug 2012 09:48:08 -0400 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:56379 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479Ab2HGNsG (ORCPT ); Tue, 7 Aug 2012 09:48:06 -0400 Date: Tue, 7 Aug 2012 14:47:50 +0100 From: Russell King To: Mark Brown Cc: Haojian Zhuang , sameo@linux.intel.com, rpurdie@rpsys.net, bryan.wu@canonical.com, linux-kernel@vger.kernel.org, Bergmann Arnd Subject: Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM Message-ID: <20120807134750.GI24257@flint.arm.linux.org.uk> References: <20120806220032.GD26698@opensource.wolfsonmicro.com> <20120807103851.GS16861@opensource.wolfsonmicro.com> <20120807111331.GC24257@flint.arm.linux.org.uk> <20120807112844.GZ16861@opensource.wolfsonmicro.com> <20120807113121.GD24257@flint.arm.linux.org.uk> <20120807113652.GA6282@flint.arm.linux.org.uk> <20120807114556.GC16861@opensource.wolfsonmicro.com> <20120807115140.GH24257@flint.arm.linux.org.uk> <20120807125820.GD16861@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120807125820.GD16861@opensource.wolfsonmicro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5094 Lines: 110 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/