lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ