[PATCH 1/2] mfd: max8925: request resource region
broonie at opensource.wolfsonmicro.com
Mon May 7 15:27:03 EDT 2012
On Mon, May 07, 2012 at 07:57:35PM +0100, Russell King - ARM Linux wrote:
> On Mon, May 07, 2012 at 11:37:29AM +0100, Mark Brown wrote:
> > So what you're saying is that it's nothing to do with zero and just
> > about plain conflicts - there's nothing magic about zero (which is what
> > Russell seemed to be suggesting)?
> You've totally missed my point if that's what you think I was saying.
I don't think I missed anything. I understood you were saying you think
this is a terrible idea; I had thought you were saying that it was an
even worse idea for a value of zero for some reason (ie, that that broke
> The resource system as it stands handles two types of resources:
> 1. MMIO resources, of type IORESOURCE_MEM, registered against the
> iomem_resource root resource
> 2. PCI/ISA IO resources, of type IORESOURCE_IO, registered against the
> ioport_resource root resource
> The two root resources are hard coded into the BUSY-marking request/release
There's also IRQ, DMA and BUS resource types defined, though not handled
> The problem comes if you start abusing IORESOURCE_IO - which has _always_
> meant "this is a PCI/ISA IO resource", and then you have someone adding
> calls to request_region() etc. That will make stuff look at the
> ioport_resource root, and it won't work.
Yes, the request_region() usage is totally broken - I hadn't realised
that the original patch was doing that. I had thought it was just
peering at the start of the address range and using that as the base
address for register I/O which is not wonderful but not actively broken
on the client side.
> In any case, if the resource tree is disconnected from the main two parent
> resources, then the resource probably shouldn't have either IORESOURCE_IO
> nor IORESOURCE_MEM set in it. It's neither of those two resource types.
There is something of a shortage of other options as things stand... I
guess using _BUS or something would at least eliminate the possibility
of confusion with the management code would be a quick, short term
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the linux-arm-kernel