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] [day] [month] [year] [list]

Date:	Tue, 7 Aug 2012 20:51:25 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	sameo@...ux.intel.com, rpurdie@...ys.net, bryan.wu@...onical.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM

On Tuesday 07 August 2012, Geert Uytterhoeven wrote:
>Don't you need an extra file in /proc, too (cfr. /proc/ioports and /proc/iomem)?
>
> And as Arnd pointed out, if resources will be used for various new buses,
> "IORESOURCE_FOO" or "IORESOURCE_OTHER" is a bit vague.
> What about conflicts where one driver means i2c addresses and another
> one means gpio addresses? The resource system will reject them?

The platform code currently only inserts the resources of type IO or
MEM. For the new type, we would not insert them to any resource
tree and they consequently are not available in any /proc file.

No driver should ever try to request access to those resources either.
The only thing we do with them is attach them to a platform device
in the mfd driver and take them out of it again in the child driver.

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