linux-kernel - Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120807115140.GH24257@flint.arm.linux.org.uk>
Date:	Tue, 7 Aug 2012 12:51:40 +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 12:45:57PM +0100, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 12:36:52PM +0100, Russell King wrote:
> 
> > And, for those hard of thinking, I'll tell you exactly how invasive it
> > is.
> 
> > 1. You modify ioport.h to add the new type.
> 
> > Yes, it's really that damned simple.  Not invasive at all.
> 
> Your step 1 is the bit that strikes me as invasive here - that's not
> something I'd be touching in a stable release if I didn't have to, it's
> visible to half the kernel in an area where we clearly don't have ideal
> review of the code (otherwise we'd not have a problem here in the first
> place) which seems totally disproportionate to the benefit here.  We're
> talking about an issue which affects one device which is used only on
> Marvell systems here.
> 
> I think everyone agrees that this is the best route forward for future
> kernels.

For fuck sake Mark.  You are insane.

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.

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.

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.

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

commit ce7e4e11221dd7fbe82c8ad28d1875b0dfa20de4
Author: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Date:   Mon May 7 10:03:20 2012 +0100

    mfd: Fix wm831x register range passing for recent ARM updates

    The removal of mach/io.h from most ARM platforms also set the range of
    valid IO ports to be empty for most platforms when previously any 32
    bit integer had been valid. This makes it impossible to add IO resources
    as the added range is smaller than that of the root resource for IO ports.

    Since we're not really using IO memory at all fix this by defining our
    own root resource outside the normal tree and make that the parent of
    all IO resources. This also ensures we won't conflict with read IO ports
    if we ever run on a platform which happens to use them.

    Signed-off-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
    Signed-off-by: Samuel Ortiz <sameo@...ux.intel.com>


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