On Sat, Mar 09, 2013 at 10:44:33PM -0800, Yinghai Lu wrote:
> In 32bit we will find table with phys address during 32bit flat mode
> in head_32.S, because at that time we don't need set page table to
> access initrd.
>
> For copying we could use early_ioremap() with phys directly before mem mapping
> is set.
>
> To keep 32bit and 64bit consistent, use phys_addr for all.
>
> Signed-off-by: Yinghai Lu <ying...@kernel.org>
> Cc: Rafael J. Wysocki <r...@sisk.pl>
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/acpi/osl.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index d66ae0e..54bcc37 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -615,7 +615,7 @@ void __init acpi_initrd_override_find(void *data, size_t
> size)
> table->signature, cpio_path, file.name, table->length);
>
> all_tables_size += table->length;
> - acpi_initrd_files[table_nr].data = file.data;
> + acpi_initrd_files[table_nr].data = (void *)__pa(file.data);
> acpi_initrd_files[table_nr].size = file.size;
> table_nr++;
> }
> @@ -624,7 +624,7 @@ void __init acpi_initrd_override_find(void *data, size_t
> size)
> void __init acpi_initrd_override_copy(void)
> {
> int no, total_offset = 0;
> - char *p;
> + char *p, *q;
>
> if (!all_tables_size)
> return;
> @@ -654,12 +654,20 @@ void __init acpi_initrd_override_copy(void)
> arch_reserve_mem_area(acpi_tables_addr, all_tables_size);
>
> for (no = 0; no < ACPI_OVERRIDE_TABLES; no++) {
> + /*
> + * have to use unsigned long, otherwise 32bit spit warning
> + * and it is ok to unsigned long, as bootloader would not
> + * load initrd above 4G for 32bit kernel.
> + */
> + unsigned long addr = (unsigned long)acpi_initrd_files[no].data;
I can't say I like this. It's stuffing phys_addr_t into void *. It
might work okay but the code is a bit misleading / confusing. "void
*" shouldn't contain a physical address. Maybe the alternatives are
uglier, I don't know. If you can think of a reasonable way to not do
this, it would be great.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
