Re: [ACPI] [PATCH] 1/3 ACPI resource handling

[Bjorn Helgaas <bjorn_helgaas@hp.com>]

> 2) I'm not convinced that this buys a whole lot -- it just hides the code
> behind a macro (something that's not generally liked in the Linux world.)
> Would this procedure be called from more than one place?

I assume you're wondering about the value of this piece:

> -----Original Message-----
> From: Bjorn Helgaas [mailto:bjorn_helgaas@hp.com] 
> Sent: Tuesday, February 11, 2003 1:58 PM
> ...
>     2) Addition of acpi_resource_to_address64(), which copies
>        address16, address32, or address64 resources to an address64
>        structure, so you don't have to maintain three sets of code
>        that differ only in the size of the address they deal with.

If so, decode_acpi_resource() in drivers/hotplug/acpiphp_glue.c is a
good example of why acpi_resource_to_address64() is useful.
decode_acpi_resource() contains a switch to handle 16-, 32-,
and 64-bit addresses.

So does acpi_get_crs_addr() in arch/ia64/kernel/acpi.c.  So will
my code to support multiple IO port space on IA64 (unless we
have something like acpi_resource_to_address64()).

None of these places really cares whether the address is 16, 32,
or 64 bits; they just have to have code to use the correct structure
type.  I'm proposing that we hide that ugliness in one place, and
most places can just deal with address64 and be done with it.

Bjorn