On Mon, Nov 21, 2011 at 03:51:20PM +0800, Huang Ying wrote:
> On Fri, 2011-11-18 at 17:25 +0800, Rafael J. Wysocki wrote:
> > On Friday, November 18, 2011, Huang Ying wrote:
> > > Take a look at ARM ioremap implementation. It appears that RAM can be
> > > ioremaped on ARM. But this changes should be harmless for ARM too.
> > > Because ioremap implementation is different between different
> > > architecture, maybe we should use #ifdef CONFIG_X86, #endif to enclose
> > > the code?
I think you're wrong there.
void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
unsigned long offset, size_t size, unsigned int mtype, void *caller)
{
...
/*
* Don't allow RAM to be mapped - this causes problems with ARMv6+
*/
if (WARN_ON(pfn_valid(pfn)))
return NULL;
While we don't exhaustively check, this catches most offenders trying to
use ioremap() on system RAM.
> > Well, that would be a bit hackish, wouldn't it?
> >
> > If the code is going to work on all architectures that _may_ use it in the
> > future (x86, ARM, ia64 so far), there's no reason to change it. My question
> > was whether or not you double checked that.
>
> Take a look at the page_is_ram() implementation and ioremap()
> implementation for ARM and ia64. It appears that the patch should work
> on these architecture. Add Tony and Russell to loop to confirm it.
Even though I've not heard of anyone wanting to use ACPI on ARM, I'm not
worried at all about this. However, it does look harmless for ARM even
if someone wanted to use ACPI (and in any case kmapping RAM is much better
than ioremapping it.)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
