From: Hanjun Guo <hanjun.guo at linaro.org>
To: devel@acpica.org
Subject: Re: [Devel] [PATCH v7 13/15] ACPI / processor: Add acpi_map_madt_entry().
Date: Tue, 31 May 2016 13:05:37 +0000 [thread overview]
Message-ID: <574D8C09.3030608@linaro.org> (raw)
In-Reply-To: 1464129345-18985-14-git-send-email-ddaney.cavm@gmail.com
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
On 2016/5/25 6:35, David Daney wrote:
> From: David Daney <david.daney(a)cavium.com>
>
> Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
> (before kmalloc is usable).
>
> Add acpi_map_madt_entry() which, indirectly, uses
> early_memremap()/early_memunmap() to access the table and parse out
> the mpidr. The existing implementation of map_madt_entry() is
> modified to take a pointer to the MADT as a parameter and the callers
> adjusted.
>
> Signed-off-by: David Daney <david.daney(a)cavium.com>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++----
> include/acpi/processor.h | 1 +
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 33a38d6..9125d7d 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -108,13 +108,12 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
> return -EINVAL;
> }
>
> -static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> +static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
> + int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
> - struct acpi_table_madt *madt;
>
> - madt = get_madt_table();
> if (!madt)
> return phys_id;
>
> @@ -145,6 +144,25 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> return phys_id;
> }
>
> +phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id)
> +{
> + struct acpi_table_madt *madt = NULL;
> + acpi_size tbl_size;
> + phys_cpuid_t rv;
> +
> + acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt,
> + &tbl_size);
> + if (!madt)
> + return PHYS_CPUID_INVALID;
> +
> + rv = map_madt_entry(madt, 1, acpi_id);
Just nit-pick, pass 1 here means we need to define an acpi processor
device object in DSDT (see function map_gicc_mpidr(),
device_declaration), it would be fine for x2apic and gic mode,
but not for lapic mode, since the function name is acpi_map_madt_entry
which is general for all architecture, it will confuse people I think.
How about rename acpi_map_madt_entry() to acpi_map_madt_gicc_entry()?
It's only used for AMR64 to get mpidrs from GICC entries using acpi_id,
other than that, it's good to me.
Thanks
Hanjun
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <hanjun.guo@linaro.org>
To: David Daney <ddaney.cavm@gmail.com>,
Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org,
devel@acpica.org
Cc: linux-kernel@vger.kernel.org,
Robert Richter <rrichter@cavium.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v7 13/15] ACPI / processor: Add acpi_map_madt_entry().
Date: Tue, 31 May 2016 21:05:13 +0800 [thread overview]
Message-ID: <574D8C09.3030608@linaro.org> (raw)
In-Reply-To: <1464129345-18985-14-git-send-email-ddaney.cavm@gmail.com>
On 2016/5/25 6:35, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
> (before kmalloc is usable).
>
> Add acpi_map_madt_entry() which, indirectly, uses
> early_memremap()/early_memunmap() to access the table and parse out
> the mpidr. The existing implementation of map_madt_entry() is
> modified to take a pointer to the MADT as a parameter and the callers
> adjusted.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++----
> include/acpi/processor.h | 1 +
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 33a38d6..9125d7d 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -108,13 +108,12 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
> return -EINVAL;
> }
>
> -static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> +static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
> + int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
> - struct acpi_table_madt *madt;
>
> - madt = get_madt_table();
> if (!madt)
> return phys_id;
>
> @@ -145,6 +144,25 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> return phys_id;
> }
>
> +phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id)
> +{
> + struct acpi_table_madt *madt = NULL;
> + acpi_size tbl_size;
> + phys_cpuid_t rv;
> +
> + acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt,
> + &tbl_size);
> + if (!madt)
> + return PHYS_CPUID_INVALID;
> +
> + rv = map_madt_entry(madt, 1, acpi_id);
Just nit-pick, pass 1 here means we need to define an acpi processor
device object in DSDT (see function map_gicc_mpidr(),
device_declaration), it would be fine for x2apic and gic mode,
but not for lapic mode, since the function name is acpi_map_madt_entry
which is general for all architecture, it will confuse people I think.
How about rename acpi_map_madt_entry() to acpi_map_madt_gicc_entry()?
It's only used for AMR64 to get mpidrs from GICC entries using acpi_id,
other than that, it's good to me.
Thanks
Hanjun
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <hanjun.guo@linaro.org>
To: David Daney <ddaney.cavm@gmail.com>,
Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org,
devel@acpica.org
Cc: linux-kernel@vger.kernel.org,
Robert Richter <rrichter@cavium.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v7 13/15] ACPI / processor: Add acpi_map_madt_entry().
Date: Tue, 31 May 2016 13:05:13 +0000 [thread overview]
Message-ID: <574D8C09.3030608@linaro.org> (raw)
In-Reply-To: <1464129345-18985-14-git-send-email-ddaney.cavm@gmail.com>
On 2016/5/25 6:35, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
> (before kmalloc is usable).
>
> Add acpi_map_madt_entry() which, indirectly, uses
> early_memremap()/early_memunmap() to access the table and parse out
> the mpidr. The existing implementation of map_madt_entry() is
> modified to take a pointer to the MADT as a parameter and the callers
> adjusted.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++----
> include/acpi/processor.h | 1 +
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 33a38d6..9125d7d 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -108,13 +108,12 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
> return -EINVAL;
> }
>
> -static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> +static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
> + int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
> - struct acpi_table_madt *madt;
>
> - madt = get_madt_table();
> if (!madt)
> return phys_id;
>
> @@ -145,6 +144,25 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> return phys_id;
> }
>
> +phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id)
> +{
> + struct acpi_table_madt *madt = NULL;
> + acpi_size tbl_size;
> + phys_cpuid_t rv;
> +
> + acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt,
> + &tbl_size);
> + if (!madt)
> + return PHYS_CPUID_INVALID;
> +
> + rv = map_madt_entry(madt, 1, acpi_id);
Just nit-pick, pass 1 here means we need to define an acpi processor
device object in DSDT (see function map_gicc_mpidr(),
device_declaration), it would be fine for x2apic and gic mode,
but not for lapic mode, since the function name is acpi_map_madt_entry
which is general for all architecture, it will confuse people I think.
How about rename acpi_map_madt_entry() to acpi_map_madt_gicc_entry()?
It's only used for AMR64 to get mpidrs from GICC entries using acpi_id,
other than that, it's good to me.
Thanks
Hanjun
WARNING: multiple messages have this Message-ID (diff)
From: hanjun.guo@linaro.org (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 13/15] ACPI / processor: Add acpi_map_madt_entry().
Date: Tue, 31 May 2016 21:05:13 +0800 [thread overview]
Message-ID: <574D8C09.3030608@linaro.org> (raw)
In-Reply-To: <1464129345-18985-14-git-send-email-ddaney.cavm@gmail.com>
On 2016/5/25 6:35, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
> (before kmalloc is usable).
>
> Add acpi_map_madt_entry() which, indirectly, uses
> early_memremap()/early_memunmap() to access the table and parse out
> the mpidr. The existing implementation of map_madt_entry() is
> modified to take a pointer to the MADT as a parameter and the callers
> adjusted.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++----
> include/acpi/processor.h | 1 +
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 33a38d6..9125d7d 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -108,13 +108,12 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
> return -EINVAL;
> }
>
> -static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> +static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
> + int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
> - struct acpi_table_madt *madt;
>
> - madt = get_madt_table();
> if (!madt)
> return phys_id;
>
> @@ -145,6 +144,25 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> return phys_id;
> }
>
> +phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id)
> +{
> + struct acpi_table_madt *madt = NULL;
> + acpi_size tbl_size;
> + phys_cpuid_t rv;
> +
> + acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt,
> + &tbl_size);
> + if (!madt)
> + return PHYS_CPUID_INVALID;
> +
> + rv = map_madt_entry(madt, 1, acpi_id);
Just nit-pick, pass 1 here means we need to define an acpi processor
device object in DSDT (see function map_gicc_mpidr(),
device_declaration), it would be fine for x2apic and gic mode,
but not for lapic mode, since the function name is acpi_map_madt_entry
which is general for all architecture, it will confuse people I think.
How about rename acpi_map_madt_entry() to acpi_map_madt_gicc_entry()?
It's only used for AMR64 to get mpidrs from GICC entries using acpi_id,
other than that, it's good to me.
Thanks
Hanjun
next prev reply other threads:[~2016-05-31 13:05 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 22:35 [PATCH v7 00/15] ACPI NUMA support for ARM64 David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 01/15] acpi, numa: Use pr_fmt() instead of printk David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 02/15] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug() David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 03/15] acpi, numa: remove duplicate NULL check David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 04/15] acpi, numa: Move acpi_numa_arch_fixup() to ia64 only David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 05/15] acpi, numa: move acpi_numa_slit_init() to drivers/acpi/numa.c David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 06/15] arm64, numa: rework numa_add_memblk() David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 07/15] arm64, numa: Cleanup NUMA disabled messages David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-27 7:58 ` Dennis Chen
2016-05-27 7:58 ` Dennis Chen
2016-05-27 7:58 ` Dennis Chen
2016-05-31 12:28 ` Hanjun Guo
2016-05-31 12:28 ` [Devel] " Hanjun Guo
2016-05-31 12:28 ` Hanjun Guo
2016-05-31 12:28 ` Hanjun Guo
2016-05-24 22:35 ` [PATCH v7 08/15] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init() David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 09/15] acpi, numa: move bad_srat() and srat_disabled() to drivers/acpi/numa.c David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 10/15] acpi, numa: remove unneeded acpi_numa=1 David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 11/15] acpi, numa: Move acpi_numa_memory_affinity_init() to drivers/acpi/numa.c David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 12/15] acpi, numa, srat: Improve SRAT error detection and add messages David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` [PATCH v7 13/15] ACPI / processor: Add acpi_map_madt_entry() David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-25 14:42 ` Catalin Marinas
2016-05-25 14:42 ` Catalin Marinas
2016-05-25 14:42 ` Catalin Marinas
2016-05-31 13:05 ` Hanjun Guo [this message]
2016-05-31 13:05 ` [Devel] " Hanjun Guo
2016-05-31 13:05 ` Hanjun Guo
2016-05-31 13:05 ` Hanjun Guo
2016-05-24 22:35 ` [PATCH v7 14/15] arm64, acpi, numa: NUMA support based on SRAT and SLIT David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-05-25 14:42 ` Catalin Marinas
2016-05-25 14:42 ` Catalin Marinas
2016-05-25 14:42 ` Catalin Marinas
2016-05-27 8:04 ` Dennis Chen
2016-05-27 8:04 ` Dennis Chen
2016-05-27 8:04 ` Dennis Chen
2016-05-27 8:04 ` Dennis Chen
2016-08-15 15:35 ` Catalin Marinas
2016-08-15 15:35 ` Catalin Marinas
2016-08-15 15:35 ` Catalin Marinas
2016-08-15 22:55 ` David Daney
2016-08-15 22:55 ` David Daney
2016-08-15 22:55 ` David Daney
2016-08-15 22:55 ` David Daney
2016-08-16 11:58 ` Hanjun Guo
2016-08-16 11:58 ` [Devel] " Hanjun Guo
2016-08-16 11:58 ` Hanjun Guo
2016-08-16 11:58 ` Hanjun Guo
2016-05-24 22:35 ` [PATCH v7 15/15] acpi, numa: Enable ACPI based NUMA on ARM64 David Daney
2016-05-24 22:35 ` David Daney
2016-05-24 22:35 ` David Daney
2016-06-09 19:47 ` Matthias Brugger
2016-06-09 19:47 ` Matthias Brugger
2016-06-09 19:47 ` Matthias Brugger
2016-06-17 2:04 ` Hanjun Guo
2016-06-17 2:04 ` Hanjun Guo
2016-06-17 2:04 ` Hanjun Guo
2016-06-17 2:04 ` Hanjun Guo
2016-06-03 22:07 ` [PATCH v7 00/15] ACPI NUMA support for ARM64 Rafael J. Wysocki
2016-06-03 22:07 ` Rafael J. Wysocki
2016-06-03 22:07 ` Rafael J. Wysocki
2016-06-10 10:20 ` Robert Richter
2016-06-10 10:20 ` Robert Richter
2016-06-10 10:20 ` Robert Richter
2016-06-10 10:20 ` Robert Richter
2016-06-10 10:26 ` Robert Richter
2016-06-10 10:26 ` Robert Richter
2016-06-10 10:26 ` Robert Richter
2016-06-10 10:26 ` Robert Richter
2016-06-10 13:51 ` Rafael J. Wysocki
2016-06-10 13:51 ` Rafael J. Wysocki
2016-06-10 13:51 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574D8C09.3030608@linaro.org \
--to=devel@acpica.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.