Add a new resource_len() function, so drivers can start using this

instead of driver-private code for a common idiom.  The call can be

useful with at least:
 - request_region(), release_region()

 - request_mem_region(), release_mem_region()

 - ioremap()
Candidate drivers include those using platform or PNP busses, and

maybe some others.  PCI already has a similar function.
This patch also updates a representative set of drivers in two

subsystems to use this call (SPI, and USB peripheral/gadget).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---

Despite comments that we have "needed" this for at least five years,

this is pure cleanup.  IMO it's appropriate for 2.6.25 and to simmer

with the rest of the MM soup for a while.
 drivers/spi/atmel_spi.c           |    2 +-

 drivers/spi/omap2_mcspi.c         |    7 +++----

 drivers/spi/spi_imx.c             |    5 ++---

 drivers/spi/spi_mpc83xx.c         |    2 +-

 drivers/spi/spi_s3c24xx.c         |    4 ++--

 drivers/spi/spi_txx9.c            |    2 +-

 drivers/spi/xilinx_spi.c          |    5 ++---

 drivers/usb/gadget/at91_udc.c     |   12 +++++-------

 drivers/usb/gadget/fsl_usb2_udc.c |    9 ++++-----

 drivers/usb/gadget/omap_udc.c     |    6 +++---

 include/linux/ioport.h            |    5 +++++

 11 files changed, 29 insertions(+), 30 deletions(-)
--- at91.orig/include/linux/ioport.h	2007-10-19 11:38:39.000000000 -0700

+++ at91/include/linux/ioport.h	2007-10-19 14:26:50.000000000 -0700

@@ -22,6 +22,11 @@ struct resource {

 	struct resource *parent, *sibling, *child;

 };
+static inline resource_size_t __pure resource_len(const struct resource *r)

+{

+	return r->end + 1 - r->start;

+}

+

 struct resource_list {

 	struct resource_list *next;

 	struct resource *res;

--- at91.orig/drivers/usb/gadget/at91_udc.c	2007-10-13 15:16:13.000000000 -0700

+++ at91/drivers/usb/gadget/at91_udc.c	2007-10-19 14:26:33.000000000 -0700

@@ -1656,9 +1656,7 @@ static int __init at91udc_probe(struct p

 	if...
[ message continues ]

On Wed, 24 Oct 2007 18:20:52 -0700
PCI also increasingly is using functions that allow the user to choose to

map a resource as a resource (eg pci_iomap). So is it better to have

functions request_mem_resource(res)  free_mem_resource(res) and similar

instead or as well ?
-

This was intended to be a minor band-aid.  ;)
We already have request_resource(), which does something

different than the request_*region() calls.  I think calls

with those names would complicate an already-too-strange

interface, adding oddball siblings to request_resource().
I'd hope that when those resource calls were defined they

made sense ... but to me, they don't do so today.  Consider

that the *typical* caller is given a "struct resource", and

then to claim the specified address space it must convert

it into a "start + length" representation before getting

back a *NEW* "struct resource" ... with identical contents,

other than the value of one all-but-undocumented flag bit.

Then, if it's I/O space the address is usable already; but

for memory space, it still needs an ioremap()...
Oh, and PCI has its own resource structs ("BAR") that don't

look or act the same as other resources.
So while I like the notion of starting to abolish that

conversion step, this wasn't an attempt to fix all the

bizarre behaviors of the resource API.
I could imagine a call taking a resource and returning

a "void __iomem *" to use for IO, which implicitly claims

the region (in either memory or i/o space) and does any

ioremap needed for memory space.  With a sibling call to

undo all that.  If that's the answer, someone else should

develop the patch and update drivers...
- Dave

-

With regards to resource reservation...  IMO we should mimic struct

pci_dev and add struct resource[] to struct device.
Just like we have pci_request_regions(), we should also be able to

easily to a dev_request_regions().  the implementation should be very

close to pci_request_region() and pci_release_region().
Then a dev_iomap() analogue to pci_iomap() should be pretty

straightforward to create.
	Jeff
-

One minor difficulty:  PCI has a limit on the number of BARs,
Wouldn't it be nicer to have PCI use those dev_*() calls?
Another minor nit:  addressing the various resource types.

The platform bus code has multiple lookup schemes. 
Calls like resource_iomap() might be more flexible, so that

lookup schemes can stay flexible.
- Dave

-

I figured that, in the absence of a true, defined BAR concept, the

struct device version would simply index into the discussed array of

struct resource.  That means any ordering or layout of resources should

work, presuming (the usual case) that both driver and platform agree on

the resource layout.
	Jeff
-

So you'd suggest having search utilities (as with platform_bus)

returning resource indices not resources?
Thing is, BARs are usually well defined, but when folk glue

resources together they use whatever order is convenient on

that particular platform.  And different platforms can have

different numbers and types of resources, etc.
- Dave
-

Far better I think that pci_ functions that take BAR values end up as

wrappers of the form
	pci_iomap(pdev, bar)

		return dev_iomap_resource(&pdev->resource[bar]);
-

I'm assuming you mean they should continue to work like they

do today:  return the resource.  Your pseudocode below shows
Sure, for PCI ... where the meaning of BARs is a fixed part of the

hardware spec, and it's not uncommon to skip a few.
But as I noted, that notion doesn't apply cleanly outside PCI;

indexes aren't necessarily portable between systems.  So any

such interface should discourage their use.
One issue with a dev_iomap() is that only memory resources

really need mapping ... but *all* of them need claiming.

(Modulo the detail that the iomap morphs i/o addresses too.)
The $SUBJECT function is a (minor) simplification for both

the mapping and claiming steps.
I think I'd rather see a dev_resource_claim() which combines

the request_{,mem_}region() semantics with mapping ... that

way drivers could save code, not just unify the two types

of register addressing.
- Dave
-