Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH 0/5] mfd: replace IORESOURCE_IO by IORESOURCE_MEM | Date | Tue, 7 Aug 2012 11:28:27 +0000 |
| |
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
| |