Subject: Question of resource_size() implementation
From: Felipe Balbi <me@felipebalbi.com>
Reply-To: me@felipebalbi.com
To: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 30 Dec 2009 01:43:54 +0200
Message-ID: <1262130234.28789.112.camel@gandalf>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1408
Lines: 48

Hi all,

I'm wondering whether the +1 in resource_size() is actually necessary.
To illustrate the problem imagine we have two subsequent 4k memory areas
which should be passed to ioremap(). When passing those address spaces
to the drivers we will use struct resource and define something like:

#define MEM_AREA1_BASE	0x480ab000
#define MEM_AREA2_BASE	0x480ac000

struct resource my_device_resources = {
	{
		.start	= MEM_AREA1_BASE,
		.end	= MEM_AREA1_BASE + SZ_4K - 1,
		.flags	= IORESOURCE_MEM,
	},
	{
		.start	= MEM_AREA2_BASE,
		.end	= MEM_AREA2_BASE + SZ_4K - 1,
		.flags	= IORESOURCE_MEM,
	},
};

that -1 would cause us to pass the correct end for each area,
respectively 0x480abfff and 0x480acffff, right ?

But resource_size() is defined as:

static inline resource_size_t resource_size(const struct resource *res)
{
	return res->end - res->start + 1;
}

then we put +1 again and the end addresses would then become
respectively 0x480ac000 and 0x480ad0000. Wouldn't we then fail ioremap()
of the second area ? wouldn't it return -EBUSY ? Are we off-by-one
here ? Or is this all expected ?

I have to say, I didn't test this on real hw yet...

-- 
balbi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/