From: Russell King <rmk@arm.linux.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
Arnd Bergmann <arnd@arndb.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
sameo@linux.intel.com, rpurdie@rpsys.net, bryan.wu@canonical.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM
Date: Tue, 7 Aug 2012 16:50:02 +0100 [thread overview]
Message-ID: <20120807155001.GL24257@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20120807164555.07c689e1@pyramind.ukuu.org.uk>
On Tue, Aug 07, 2012 at 04:45:55PM +0100, Alan Cox wrote:
> > #define IORESOURCE_TYPE_BITS 0x00001f00 /* Resource type */
> > #define IORESOURCE_IO 0x00000100
> > #define IORESOURCE_MEM 0x00000200
> > +#define IORESOURCE_FOO 0x00000300
>
> These are bit masks and checked as such in many places. This makes no
> sense at all.
Correct, but nowhere are they checked as masks in the platform
device/driver code nor the MFD driver code. Here's the relevant
extracts from the platform driver code:
struct resource *platform_get_resource(struct platform_device *dev,
unsigned int type, unsigned int num)
{
int i;
for (i = 0; i < dev->num_resources; i++) {
struct resource *r = &dev->resource[i];
if (type == resource_type(r) && num-- == 0)
return r;
}
return NULL;
}
...
if (resource_type(r) == IORESOURCE_MEM)
p = &iomem_resource;
else if (resource_type(r) == IORESOURCE_IO)
p = &ioport_resource;
This is modern code, written using the accessors provided in ioport.h.
resource_type() is defined as:
static inline unsigned long resource_type(const struct resource *res)
{
return res->flags & IORESOURCE_TYPE_BITS;
}
So, provided these don't leak outside of the platform and the affected
MFD drivers, what the rest of the kernel does doesn't matter.
> Moving to IO_RESOURCE_TYPE() being 0-31 values might be smart but its a
> massive all kernel change.
Only if we want to change the existing numbering _or_ propagate them
outside of platform devices etc, and when that happens that's the time
to start fixing stuff one subsystem at a time.
Of course, if the above helper was being used, we'd already be set.
I don't see that as a blocker to its local use, contained completely
within the MFD and platform device subsystems.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
prev parent reply other threads:[~2012-08-07 15:50 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-05 16:32 [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM Haojian Zhuang
2012-08-05 16:32 ` [PATCH 1/5] mfd: use IORESOURCE_MEM in 88pm860x backlight Haojian Zhuang
2012-08-05 16:32 ` [PATCH 2/5] mfd: use IORESOUCE_MEM in 88pm860x leds driver Haojian Zhuang
2012-08-05 16:32 ` [PATCH 3/5] mfd: use IORESOURCE_MEM in 88pm860x regulator Haojian Zhuang
2012-08-05 16:32 ` [PATCH 4/5] mfd: avoid to return failure in 88pm860x Haojian Zhuang
2012-08-05 16:32 ` [PATCH 5/5] ARM: mmp: enable 88pm860x in ttc dkb Haojian Zhuang
2012-08-06 14:30 ` [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM Mark Brown
2012-08-06 14:42 ` Haojian Zhuang
2012-08-06 15:46 ` Mark Brown
2012-08-06 15:56 ` Haojian Zhuang
2012-08-06 15:58 ` Mark Brown
2012-08-06 19:22 ` Russell King
2012-08-06 19:53 ` Mark Brown
2012-08-06 21:31 ` Russell King
2012-08-06 22:00 ` Mark Brown
2012-08-07 1:47 ` Haojian Zhuang
2012-08-07 7:58 ` Russell King
2012-08-07 8:24 ` Benjamin Herrenschmidt
2012-08-07 10:38 ` Mark Brown
2012-08-07 11:13 ` Russell King
2012-08-07 11:28 ` Mark Brown
2012-08-07 11:31 ` Russell King
2012-08-07 11:36 ` Russell King
2012-08-07 11:45 ` Mark Brown
2012-08-07 11:51 ` Russell King
2012-08-07 12:58 ` Mark Brown
2012-08-07 13:47 ` Russell King
2012-08-07 15:54 ` Mark Brown
2012-08-07 15:22 ` Geert Uytterhoeven
2012-08-07 15:44 ` Russell King
2012-08-07 16:48 ` Mark Brown
2012-08-07 20:51 ` Arnd Bergmann
2012-08-07 11:38 ` Mark Brown
2012-08-07 11:44 ` Russell King
2012-08-07 12:11 ` Russell King
2012-08-07 13:25 ` Mark Brown
2012-08-07 14:28 ` Arnd Bergmann
2012-08-07 14:41 ` Russell King
2012-08-07 16:36 ` Mark Brown
2012-08-07 8:22 ` Benjamin Herrenschmidt
2012-08-07 8:28 ` Russell King
2012-08-07 11:28 ` Arnd Bergmann
2012-08-07 11:32 ` Russell King
2012-08-07 11:34 ` Arnd Bergmann
2012-08-07 11:35 ` Mark Brown
2012-08-07 11:41 ` Russell King
2012-08-07 15:45 ` Alan Cox
2012-08-07 15:50 ` Russell King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120807155001.GL24257@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=bryan.wu@canonical.com \
--cc=haojian.zhuang@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rpurdie@rpsys.net \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.