Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM

[Arnd Bergmann <arnd@arndb.de>]

On Tuesday 07 August 2012, Russell King wrote:
> On Tue, Aug 07, 2012 at 06:22:22PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-08-06 at 22:31 +0100, Russell King wrote:
> > > 
> > > So, if we made this a numeric index, then we have 32 resource types
> > > to deal with, and no need to bugger around with re-using an existing
> > > type for something else.
> > > 
> > > This makes sense, MEM, IRQ and DMA are all mutually exclusive, as
> > > should be MEM and IO (because they can't coexist in two resource trees
> > > at the same time.)  BUS only gets used in a hand-full of places and
> > > not with any other flags.
> > > 
> > > So, looks like we can have 27 new resource types fairly easily.
> > 
> > Besides we can easily use a single IORESOURCE_OTHER for most things
> > really, if we prefer, make it IORESOURCE_IO | IORESOURCE_MEM and have
> > platform device avoid that combo...
> 
> That will work just the same way that I'm suggesting.  We can keep
> the existing bit-based numbers, and:
> 
> #define IORESOURCE_OTHER        0x00000300
> 
> and the platform code will avoid using the standard resource trees,
> because it does things correctly here:
> 
>                         if (resource_type(r) == IORESOURCE_MEM)
>                                 p = &iomem_resource;
>                         else if (resource_type(r) == IORESOURCE_IO)
>                                 p = &ioport_resource;
> 

I had not realized that we did this in platform_device_add(), which
means using IORESOURCE_IO in mfd is even more broken than I thought
previously.

I've looked through the code some more and your solution sounds
like the best option to get this sorted quickly. The entire
resource logic will probably come back to haunt us with ACPI 5.0
which adds region types for a number of new things (i2c, gpio,
ipmi, cmos, ...) and we might end up representing them
as resource. Or we might not.

If we introduce a new IORESOURCE_OTHER, I would actually prefer to
define it to 0x00000000 for purely aesthetic reasons, the effect
should be the same as using 0x00000300.

	Arnd