public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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:

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox