Re: [PATCH 6 of 7] x86: use early_ioremap in __acpi_map_table

["Yinghai Lu" <yhlu.kernel@gmail.com>]

On Fri, Sep 12, 2008 at 2:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
>> Yinghai Lu wrote:
>> > void __iomem *__init_refok
>> > acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> > {
>> >         if (phys > ULONG_MAX) {
>> >                 printk(KERN_ERR PREFIX "Cannot map memory that high\n");
>> >                 return NULL;
>> >         }
>> >         if (acpi_gbl_permanent_mmap)
>> >                 /*
>> >                 * ioremap checks to ensure this is in reserved space
>> >                 */
>> >                 return ioremap((unsigned long)phys, size);
>> >         else
>> >                 return __acpi_map_table((unsigned long)phys, size);
>> > }
>> > EXPORT_SYMBOL_GPL(acpi_os_map_memory);
>> >
>> > void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
>> > {
>> >         if (acpi_gbl_permanent_mmap) {
>> >                 iounmap(virt);
>> >         }
>> > }
>> > EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>> >
>> > just let acpi_os_unmap_memory to call __acpi_unmap_table...
>> >
>>
>> That was my first attempt.  Unfortunately a lot of the acpi code seems
>> pretty sloppy about unmapping its tables, and basically relies on
>> __acpi_map_table's current behaviour of removing the previous mapping
>> when creating the new mapping.
>
> could we just emit a WARN_ON_ONCE() warning when we have to remove a
> previous mapping, so that the ACPI code can be fixed eventually?

could be some code is shared between early and permanent, and later
may not need unmap.

anyway those code need to be cleanup, to double check if some fix-map
is overwrited unexpected..

YH