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]

Date:	Mon, 6 Aug 2012 23:00:32 +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 10:31:24PM +0100, Russell King wrote:

> So, the fact that platform devices will get any resource marked
> IORESOURCE_IO registered against ioport_resource isn't a problem
> then...

This is what providing a separate parent to ensure they're in a
different tree is there to fix.

> Anyway, given that this thread is broken, there's no way for me to find
> out what the _original_ issue is that you're talking about.  So I'm going
> to guess that it's come up because we're out of IORESOURCE bits.

No, that's not it.  What's happened is that Haojian has posted some
patching changing all the _IO resources to _MEM in the Marvell PMIC
drivers, I think because you yelled at him for using _IO when he
reported that the changes in ioport_resource broke things a few releases
ago.  Obviously this doesn't achieve a huge amount, it's a misplaced
cleanup.

> So, if we made this a numeric index, then we have 32 resource types
> to deal with, and no need to bugger around with re-using an existing
> type for something else.

This seems sensible, and I'm sure if that change were made people would
be delighed to use new resource types, but like I say nobody who's
motivated to do anything here seems to have the time to do anything
about it.

Whoever looks at this would need to do some detective work, it does seem
like there must have been a reason to use a bitmask here...
--
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/