Re: [PATCH 2/2] ACPICA: support Generic Address Structure bit_offset in acpi_read/write

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Friday, November 18, 2011, Thomas Renninger wrote:
> On Thursday 17 November 2011 21:27:40 Rafael J. Wysocki wrote:
> > On Thursday, November 17, 2011, Huang Ying wrote:
> ... 
> > > page_is_ram() is used by x86 ioremap implementation to exclude RAM
> > > range.  So I think it can be used here.
> > 
> > Except that ACPI is not going to be x86-specific any more in the (near?)
> > future.  Have you taken that into consideration?
> This is about the NVS ram resource registering/requesting problem?
> I had an idea to make the resource management more fine grained.
> There already is a possibility to pass "flags" to request_mem_region macro:
> include/linux/ioport.h:
> #define __request_mem_region(start,n,name, excl) __request_region(&iomem_resource, (start), (n), (name), excl)
> #define request_muxed_region(start,n,name)    __request_region(&ioport_resource, (start), (n), (name), IORESOURCE_MUXED)
> ...
> 
> 
> The idea is to e.g. flag memory with:
>   MEM_NVS
>   MEM_RESERVED
>   (MEM_PCI?)
>   other archs may have other memory flags
>   ...
> once it got detected/initialized at early boot.
> 
> and then have something like:
> request_specific_mem_region(start, n, name, (MEM_NVS | MEM_RESERVED))
> for apei (or others allowed to access NVS mem) which is only successful
> if the requested memory region has been marked as NVS/RESERVED memory.
> 
> This is nothing I have time for right now, therefore don't get
> the mail wrong: I don't object to adding any other working solution
> discussed here.
> Just an idea how this could be solved in a cleaner way,
> also re-usable for others.
> 
> What do you think?

That sounds like a good idea in principle, it would save us from some ugly
hacks here and there I think. :-)

Thanks,
Rafael