[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo4y9HQB-OcX8XwpXHW=xCvDQOJZgokG5iMqg705XZnevg@mail.gmail.com>
Date: Tue, 17 Jun 2014 10:05:33 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Jiang Liu <jiang.liu@...ux.intel.com>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Thomas Gleixner <tglx@...utronix.de>,
Grant Likely <grant.likely@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Randy Dunlap <rdunlap@...radead.org>,
Yinghai Lu <yinghai@...nel.org>,
"x86@...nel.org" <x86@...nel.org>, Len Brown <lenb@...nel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Tony Luck <tony.luck@...el.com>,
Joerg Roedel <joro@...tes.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [RFC Patch V2 03/16] ACPI, x86/PCI: Move resource_to_addr() to
acpi generic
On Mon, Jun 16, 2014 at 11:29 PM, Jiang Liu <jiang.liu@...ux.intel.com> wrote:
> From: Yinghai Lu <yinghai@...nel.org>
>
> Rui Wang reported ioapic hot-add does not work on his machine
> that _CRS have MEMORY_FIXED.
> He also proposed to expose resource_to_addr() and use it for ioapic.
>
> We should move it to acpi generic, as ioapi.c current is in
s/ioapi.c/ioapic.c/
> drivers/pci/.
>
> Or should move it to acpica?
>
> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
> Signed-off-by: Jiang Liu <jiang.liu@...ux.intel.com>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 0bdacc5e26a3..e91deebf0930 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -424,6 +424,52 @@ void acpi_dev_free_resource_list(struct list_head *list)
> }
> EXPORT_SYMBOL_GPL(acpi_dev_free_resource_list);
>
> +acpi_status acpi_mem_addr_resource_to_address64(struct acpi_resource *resource,
> + struct acpi_resource_address64 *addr)
> +{
> + acpi_status status;
> + struct acpi_resource_memory24 *memory24;
> + struct acpi_resource_memory32 *memory32;
> + struct acpi_resource_fixed_memory32 *fixed_memory32;
> +
> + memset(addr, 0, sizeof(*addr));
> + switch (resource->type) {
> + case ACPI_RESOURCE_TYPE_MEMORY24:
> + memory24 = &resource->data.memory24;
> + addr->resource_type = ACPI_MEMORY_RANGE;
> + addr->minimum = memory24->minimum;
> + addr->address_length = memory24->address_length;
> + addr->maximum = addr->minimum + addr->address_length - 1;
> + return AE_OK;
> + case ACPI_RESOURCE_TYPE_MEMORY32:
> + memory32 = &resource->data.memory32;
> + addr->resource_type = ACPI_MEMORY_RANGE;
> + addr->minimum = memory32->minimum;
> + addr->address_length = memory32->address_length;
> + addr->maximum = addr->minimum + addr->address_length - 1;
> + return AE_OK;
> + case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
> + fixed_memory32 = &resource->data.fixed_memory32;
> + addr->resource_type = ACPI_MEMORY_RANGE;
> + addr->minimum = fixed_memory32->address;
> + addr->address_length = fixed_memory32->address_length;
> + addr->maximum = addr->minimum + addr->address_length - 1;
> + return AE_OK;
> + case ACPI_RESOURCE_TYPE_ADDRESS16:
> + case ACPI_RESOURCE_TYPE_ADDRESS32:
> + case ACPI_RESOURCE_TYPE_ADDRESS64:
> + status = acpi_resource_to_address64(resource, addr);
> + if (ACPI_SUCCESS(status) &&
> + (addr->resource_type == ACPI_MEMORY_RANGE ||
> + addr->resource_type == ACPI_IO_RANGE) &&
> + addr->address_length > 0) {
> + return AE_OK;
> + }
> + break;
> + }
> + return AE_ERROR;
> +}
There's already very similar-looking code in acpi/resource.c, e.g.,
acpi_dev_resource_address_space() and acpi_dev_resource_memory(). Can
you use that existing code instead of adding new code that's mostly a
duplication?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists