Messages in this thread | | | Date | Tue, 7 Aug 2012 16:50:02 +0100 | From | Russell King <> | Subject | Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM |
| |
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:
| |