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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120806195352.GC16199@opensource.wolfsonmicro.com>
Date:	Mon, 6 Aug 2012 20:53:52 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Russell King <rmk@....linux.org.uk>
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 Mon, Aug 06, 2012 at 08:22:09PM +0100, Russell King wrote:
> On Mon, Aug 06, 2012 at 04:58:06PM +0100, Mark Brown wrote:

> > That's one reason why I've not attacked this problem myself, but frankly
> > I'm totally happy with using _IO here so I've not looked particularly
> > closely.

> NO.  This is stupid.  We've been here before, and I've said what I'm
> saying below before too.

> IORESOURCE_IO is for PCI/ISA IO resources.
> IORESOURCE_MEM is for _memory mapped_ IO resources.

> On ARM, we only have memory mapped IO resources, with the exception that
> if we have a real PCI/ISA bus, we give them IORESOURCE_IO resources.

> Never use IORESOURCE_IO for anything but PCI/ISA bus IO resources. Ever.

*sigh*  You must be aware that this isn't getting us anywhere.  As you
know the issues here aren't practical ones if we make sure the resource
trees are split (which is what Haojian should really be doing if he's
not done so already) and that the resource code is sadly difficult to
modify to support new resource types due to the full bitmask that
Haojian mentioned.  

Clearly nobody has the combination of time and interest to add a new
resource type and we do have actual systems running now (and for the
past several years) relying on this.

To be perfectly frank I have a hard time convincing myself that there's
any real problem with the current solution; obviously it's not what _IO
was originally intended for but having several different trees of
resources seems like a reasonable extension here and the effort involved
in any other changes seems disproportionately high.  I guess we could
formalise it by making an alias for _IO but I doubt that'd address the
concerns you have.
--
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/