Hi Hanjun,
> ---------- Forwarded message ----------
> From: Hanjun Guo <hanjun.guo(a)linaro.org>
> Date: 14 January 2015 at 10:05
> Subject: [Linaro-acpi] [PATCH v7 17/17] Documentation: ACPI for ARM64
From: Graeme Gregory <graeme.gregory(a)linaro.org>
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
> Reviewed-by: Suravee Suthikulpanit <Suravee.Suthikulpanit(a)amd.com>
Reviewed-by: Yi Li <phoenix.liyi(a)huawei.com>
> Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org>
> Signed-off-by: Al Stone <al.stone(a)linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
> ---
> Documentation/arm64/arm-acpi.txt | 327
> +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 327 insertions(+)
> create mode 100644 Documentation/arm64/arm-acpi.txt
Thanks for including previous feedback. This version looks good to us.
Reviewed-by: Ashwin Chaugule <ashwinc(a)codeaurora.org>
Sign-offs on the other patches in this series should follow shortly.
Thanks,
Ashwin
--
Qualcomm Innovation Center, Inc
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
ACPI 5.1 has some major changes for ARM platform and the following
tables which are essential for ARM platforms:
1) MADT table updates for GIC v2/v3.
2) FADT updates for PSCI
3) GTDT for arch timer
This patch set is the ARM64 ACPI core patches covered MADT, FADT
and GTDT, platform board specific drivers are not covered by this
patch set.
We first introduce acpi.c and its related head file which are needed
by ACPI core, and then get RSDP to extract all the ACPI boot-time tables.
When all the boot-time tables (FADT, MADT, GTDT) are ready, then
parse them to init the sytem when booted. Specifically,
a) we use FADT to init PSCI and use PSCI to boot SMP;
b) Use MADT for GIC init and SMP init;
c) GTDT for arch timer init.
This patch set is based on 3.17-rc4 and was tested by Graeme on Juno
and FVP base model boot with ACPI only OK, if you want to test them,
you can pull from acpi-5.1-v5 branch in leg/acpi repo:
git://git.linaro.org/leg/acpi/acpi.git
Updates since v4:
- ACPI uasge doc for ARM64 was updated a lot by Al
- Collect some ACKs from Grant, Olof, Mark
- address some comments from Olof and Catalin since last version
Updates since v3:
- Compile out sleep.c on ARM64 when ACPI enabled
- refactor the GIC init code to address the comments from Marc and
Arnd
- refactor the SMP init code to fix some logic problem when PSCI is
not present, also address some of Grant and Lorenzo's comments
- reorder the patch series and move ACPI table changes to the front
of patch set
- rebase on top of 3.17-rc4
Updates since v2:
- Refactor the code to make SMP/PSCI init with less sperated init
path by Tomasz
- make ACPI depend on EXPERT
- Address lots of comments from Catalin, Sudeep, Geoff
- Add Juno device ACPI driver patches for review
Updates since v1:
- Set ACPI default off on ARM64 suggested by Olof;
- Rebase the patch set on top of linux-next branch/linux-pm tree which
includes the ACPICA for full ACPI 5.1 support.
- Update the document as suggested;
- Adress lots of comments from Mark, Sudeep, Randy, Naresh, Olof, Geoff
and more...
Al Stone (3):
ARM64 / ACPI: Get RSDP and ACPI boot-time tables
ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to
enable ACPI
ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on
ARM64
Ashwin Chaugule (1):
ACPI / table: Add new function to get table entries
Graeme Gregory (4):
ARM64 / ACPI: Introduce sleep-arm.c
ARM64 / ACPI: If we chose to boot from acpi then disable FDT
ARM64 / ACPI: Enable ARM64 in Kconfig
Documentation: ACPI for ARM64
Hanjun Guo (8):
ARM64: Move the init of cpu_logical_map(0) before
unflatten_device_tree()
ARM64 / ACPI: Make PCI optional for ACPI on ARM64
ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
ACPI / table: Print GIC information when MADT is parsed
ARM64 / ACPI: Parse MADT for SMP initialization
ACPI / processor: Make it possible to get CPU hardware ID via GICC
ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
ARM64 / ACPI: Parse GTDT to initialize arch timer
Tomasz Nowicki (2):
ACPI / table: Count matched and successfully parsed entries without
specifying max entries
ARM64 / ACPI: Add GICv2 specific ACPI boot support
Documentation/arm64/arm-acpi.txt | 323 ++++++++++++++++++++++++++++++
Documentation/kernel-parameters.txt | 3 +-
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/acenv.h | 18 ++
arch/arm64/include/asm/acpi.h | 99 ++++++++++
arch/arm64/include/asm/cpu_ops.h | 1 +
arch/arm64/include/asm/pci.h | 11 ++
arch/arm64/include/asm/psci.h | 3 +-
arch/arm64/include/asm/smp.h | 5 +-
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi.c | 356 ++++++++++++++++++++++++++++++++++
arch/arm64/kernel/cpu_ops.c | 4 +-
arch/arm64/kernel/psci.c | 78 +++++---
arch/arm64/kernel/setup.c | 25 ++-
arch/arm64/kernel/smp.c | 2 +-
arch/arm64/kernel/time.c | 7 +
drivers/acpi/Kconfig | 6 +-
drivers/acpi/Makefile | 6 +-
drivers/acpi/bus.c | 3 +
drivers/acpi/internal.h | 5 +
drivers/acpi/processor_core.c | 37 ++++
drivers/acpi/sleep-arm.c | 28 +++
drivers/acpi/tables.c | 115 +++++++++--
drivers/clocksource/arm_arch_timer.c | 117 +++++++++--
drivers/irqchip/irq-gic.c | 106 ++++++++++
drivers/irqchip/irqchip.c | 3 +
include/linux/acpi.h | 5 +
include/linux/clocksource.h | 6 +
include/linux/irqchip/arm-gic-acpi.h | 31 +++
include/linux/pci.h | 37 +++-
30 files changed, 1353 insertions(+), 91 deletions(-)
create mode 100644 Documentation/arm64/arm-acpi.txt
create mode 100644 arch/arm64/include/asm/acenv.h
create mode 100644 arch/arm64/include/asm/acpi.h
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/acpi.c
create mode 100644 drivers/acpi/sleep-arm.c
create mode 100644 include/linux/irqchip/arm-gic-acpi.h
--
1.7.9.5
Back in September 2014, a meeting was held at Linaro Connect where we
discussed what issues remained before the arm64 ACPI core patches could
be merged into the kernel, creating the TODO list below. I should have
published this list sooner; I got focused on trying to resolve some of
the issues instead.
We have made some progress on all of these items. But, I want to make
sure we haven't missed something. Since this list was compiled by only
the people in the room at Connect, it is probable we have. I, for one,
do not yet claim omniscience.
So, I want to ask the ARM and ACPI communities:
-- Is this list correct?
-- Is this list complete?
Below is what we currently know about; very brief notes on status are
included. The TL;DR versions of the TODO list and the current status
can be found at:
https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/CoreUpstreamNotes
and I'll do my best to kept that up to date.
Thanks. Any and all feedback is greatly appreciated.
TODO List for ACPI on arm64:
============================
1. Define how Aarch64 OS identifies itself to firmware.
* Problem:
* _OSI method is demonstrably unreliable. On x86 Linux claims to
be Windows
* Proposal to use _OSC method as replacement is complicated and
creates an explosion of combinations
* Solution:
* Draft and propose OS identification rules to ABST and ASWG for
inclusion in ACPI spec.
* Draft and propose recommended practice for current ACPI 5.1 spec
platforms.
* Status: Little progress, still under investigation
2. Linux must choose DT booting by default when offered both ACPI and
DT on arm64
* DONE
3. Linux UEFI/ACPI testing tools must be made available
* Problem:
* Hardware/Firmware vendors do not have tools to test Linux
compatibility.
* Common problems go undetected if not tested for.
* Solution:
* Port FWTS tool and LuvOS distribution to AArch64
* Make LuvOS images readily available
* Require hardware vendors to actively test against old and new
kernels.
* Status: LuvOS and FWTS ported to arm64 and running; patches being
mainlined; additional test cases being written.
4. Set clear expectations for those providing ACPI for use with Linux
* Problem:
* Hardware/Firmware vendors can and will create ACPI tables that
cannot be used by Linux without some guidance
* Kernel developers cannot determine whether the kernel or firmware
is broken without knowing what the firmware should do
* Solution: document the expectations, and iterate as needed.
Enforce when we must.
* Status: initial kernel text available; AMD has offered to make
their guidance document generic; firmware summit planned for
deeper discussions.
5. Demonstrate the ACPI core patches work
* Problem: how can we be sure the patches work?
* Solution: verify the patches on arm64 server platforms
* Status:
* ACPI core works on at least the Foundation model, Juno, APM
Mustang, and AMD Seattle
* FWTS results will be published as soon as possible
6. How does the kernel handle_DSD usage?
* Problem:
* _DSD defines key-value properties in the DT style. How do we
ensure _DSD bindings are well defined?
* How do we ensure DT and _DSD bindings remain consistent with
each other?
* Solution: public documentation for all bindings, and a process
for defining them
* Status: proposal to require patch authors to point at public
binding documentation; kernel Documentation/devicetree/bindings
remains the default if no other location exists; UEFI forum has
set up a binding repository.
7. Why is ACPI required?
* Problem:
* arm64 maintainers still haven't been convinced that ACPI is
necessary.
* Why do hardware and OS vendors say ACPI is required?
* Status: Al & Grant collecting statements from OEMs to be posted
publicly early in the new year; firmware summit for broader
discussion planned.
8. Platform support patches need review
* Problem: the core Aarch64 patches have been reviewed and are in
good shape, but there is not yet a good example of server platform
support patches that use them.
* Solution: Post *good* patches for multiple ACPI platforms
* Status: first version for AMD Seattle has been posted to the
public linaro-acpi mailing list for initial review (thanks,
Arnd), refined versions to be posted to broader lists after a
few iterations for basic cleanup
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone(a)linaro.org
-----------------------------------
This patch series introduce ACPI support for non-PCI AHCI platform driver.
Existing ACPI support for AHCI assumes the device controller is a PCI device.
Also, since there is no ACPI _HID/_CID for generic AHCI controller, the driver
could not use them for matching devices. Therefore, this patch introduces a mechanism
for drivers to match devices using ACPI _CLS method.
This patch series is rebased from:
http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v6
This topic was discussed earlier here (as part of introducing support for
AMD Seattle SATA controller):
http://marc.info/?l=linux-arm-kernel&m=141083492521584&w=2
Changes from RFC (https://lkml.org/lkml/2014/12/17/446)
* Remove #ifdef and make non-ACPI version of the acpi_match_device_cls
as inline. (per Arnd)
* Simplify logic to retrieve and evaluate _CLS handle. (per Hanjun)
Suravee Suthikulpanit (2):
ACPI / scan: Add support for ACPI _CLS device matching
ata: ahci_platform: Add ACPI _CLS matching
drivers/acpi/scan.c | 63 +++++++++++++++++++++++++++++++++++++++++
drivers/ata/Kconfig | 2 +-
drivers/ata/ahci_platform.c | 3 ++
include/acpi/acnames.h | 1 +
include/linux/acpi.h | 12 +++++++-
include/linux/device.h | 1 +
include/linux/mod_devicetable.h | 6 ++++
7 files changed, 86 insertions(+), 2 deletions(-)
--
1.9.3
From: Al Stone <ahs3(a)redhat.com>
The following patches are pretty much the same core as used for the Seattle
topic branch. There are a few additional APM X-Gene specific patches.
These are not final by any stretch of the imagination. As with the Seattle
patches, there is much work to be done for PCI (especially since the Mustang
hardware is a very special case), and it is a known the the network card does
not yet work properly.
So why commit these patches? Simply put, to record the current progress
and make visible the current work on Mustang.
This kernel does boot and run, and PCI does seem to work. As noted, the
NIC is not yet correct but this is being investigated and may be firmware
related, not kernel.
Al Stone (3):
Fix arm64 compilation error in PNP code
clocksource: arm_arch_timer: fix system hang
arm64/pci/acpi: initial support for ACPI probing of PCI
Graeme Gregory (2):
acpi: add arm to the platforms that use ioremap
tty: SBSA compatible UART
Hanjun Guo (1):
ARM64 / ACPI: Introduce some PCI functions when PCI is enabled
Kyle McMartin (1):
arm64: don't set READ_IMPLIES_EXEC for EM_AARCH64 ELF objects
Mark Salter (17):
ahci_xgene: add errata workaround for ATA_CMD_SMART
arm64: use EFI as last resort for reboot and poweroff
acpi: fix acpi_os_ioremap for arm64
arm64: add parking protocol support
sata/xgene: support acpi probing
xgene: add support for ACPI-probed serial port
Revert "ahci_xgene: Skip the PHY and clock initialization if already
configured by the firmware."
arm64: add sev to parking protocol
arm64: avoid need for console= to enable serial console
xgene acpi network - first cut
acpi: add utility to test for device dma coherency
arm64: [NOT FOR UPSTREAM] fix dma_ops for ACPI and PCI devices
arm64/pci: replace weak raw pci ops with settable ops
arm64/acpi/pci: add support for parsing MCFG table
arm64/acpi/pci: provide hook for MCFG fixups
PCI: xgene: Provide fixup for ACPI MCFG support
iommu/arm-smmu: fix NULL dereference with ACPI PCI devices
Mika Westerberg (2):
ACPI: Add support for device specific properties
ACPI: Allow drivers to match using Device Tree compatible property
Rafael J. Wysocki (2):
Driver core: Unified device properties interface for platform firmware
Driver core: Unified interface for firmware node properties
arch/arm64/Kconfig | 6 +
arch/arm64/Makefile | 1 +
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/elf.h | 3 +-
arch/arm64/include/asm/pci.h | 57 +++
arch/arm64/include/asm/smp.h | 5 +
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/acpi.c | 54 +-
arch/arm64/kernel/cpu_ops.c | 4 +
arch/arm64/kernel/efi.c | 11 +
arch/arm64/kernel/pci.c | 108 ++--
arch/arm64/kernel/process.c | 6 +
arch/arm64/kernel/setup.c | 22 +
arch/arm64/kernel/smp_parking_protocol.c | 110 ++++
arch/arm64/mm/dma-mapping.c | 103 ++++
arch/arm64/pci/Makefile | 2 +
arch/arm64/pci/mmconfig.c | 431 ++++++++++++++++
arch/arm64/pci/pci.c | 375 ++++++++++++++
drivers/acpi/Makefile | 1 +
drivers/acpi/internal.h | 6 +
drivers/acpi/osl.c | 6 +-
drivers/acpi/property.c | 567 ++++++++++++++++++++
drivers/acpi/scan.c | 120 ++++-
drivers/acpi/utils.c | 26 +
drivers/ata/ahci_xgene.c | 30 +-
drivers/base/Makefile | 2 +-
drivers/base/property.c | 625 +++++++++++++++++++++++
drivers/clocksource/arm_arch_timer.c | 9 +-
drivers/iommu/arm-smmu.c | 8 +-
drivers/irqchip/irq-gic-v3.c | 10 +
drivers/irqchip/irq-gic.c | 10 +
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 77 ++-
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 68 ++-
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 1 +
drivers/of/base.c | 102 +++-
drivers/pci/host/pci-xgene.c | 144 ++++++
drivers/pnp/resource.c | 2 +
drivers/tty/Kconfig | 6 +
drivers/tty/Makefile | 1 +
drivers/tty/sbsauart.c | 355 +++++++++++++
drivers/tty/serial/8250/8250_dw.c | 9 +
include/acpi/acpi_bus.h | 27 +
include/acpi/acpi_io.h | 6 +
include/asm-generic/vmlinux.lds.h | 7 +
include/linux/acpi.h | 106 +++-
include/linux/irqchip/arm-gic.h | 2 +
include/linux/of.h | 44 ++
include/linux/property.h | 107 ++++
48 files changed, 3670 insertions(+), 118 deletions(-)
create mode 100644 arch/arm64/kernel/smp_parking_protocol.c
create mode 100644 arch/arm64/pci/Makefile
create mode 100644 arch/arm64/pci/mmconfig.c
create mode 100644 arch/arm64/pci/pci.c
create mode 100644 drivers/acpi/property.c
create mode 100644 drivers/base/property.c
create mode 100644 drivers/tty/sbsauart.c
create mode 100644 include/linux/property.h
--
1.9.3
Update for 11 Jan 2015:
Back in September 2014, a meeting was held at Linaro Connect where we
discussed what issues remained before the arm64 ACPI core patches could
be merged into the kernel, creating the TODO list below. I should have
published this list sooner; I got focused on trying to resolve some of
the issues instead.
We have made some progress on all of these items. But, I want to make
sure we haven't missed something. Since this list was compiled by only
the people in the room at Connect, it is probable we have. I, for one,
do not yet claim omniscience.
So, I want to ask the ARM and ACPI communities:
-- Is this list correct?
-- Is this list complete?
Below is what we currently know about; very brief notes on status are
included. The TL;DR versions of the TODO list and the current status
can be found at:
https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/CoreUpstreamNotes
and I'll do my best to kept that up to date.
Thanks. Any and all feedback is greatly appreciated.
Changes since 14 Dec 2014:
-- v6 of ACPI core patches posted
-- Good progress in _OSI investigation, started preparing RFC for the
mailing lists
-- Precise definition of kernel behavior when defaulting to DT and/or
using acpi=force being discussed again
-- FWTS now runs and results posted after each merge of leg-kernel
(includes ACPI) with Linus' tree (i.e., each -rc).
-- ACPI on arm64 kernel document updated, under extensive discussion on
the lists; starting coordination with SBBR content.
-- Firmware Summit: planned for 26 Mar 2015, San Jose, CA, at the ARM
office; mailing list (with archives) now up and running; updated
agenda being prepared
-- Merged items "Demonstrate the ACPI core patches work", and "Platform
support patches need review" because of their similarity.
-- Further discussions have occurred regarding "Why ACPI?"; Grant has
a blog post explaining this better, and we will add that to kernel
document
-- Further discussion on the usage of _DSD has occurred, but much more
is needed
TODO List for ACPI on arm64:
============================
1. Define how Aarch64 OS identifies itself to firmware
* Problem:
* _OSI method is demonstrably unreliable. On x86, Linux claims to
be Windows.
* Proposal to use _OSC method as replacement is complicated and
creates an explosion of combinations
* Solution:
* Draft and propose OS identification rules to ABST and ASWG for
inclusion in ACPI spec.
* Draft and propose recommended practice for current ACPI 5.1 spec
platforms.
* Status: Good progress in _OSI investigation, started preparing RFC
for the mailing lists; general agreement to deprecate _OSI
completely
2. Linux must choose DT booting by default when offered both ACPI and
DT on arm64
* Status: DONE, but being revisited for possible algorithmic change
3. Linux UEFI/ACPI testing tools must be made available
* Problem:
* Hardware/Firmware vendors do not have tools to test Linux
compatibility.
* Common problems go undetected if not tested for.
* Solution:
* Port FWTS tool and LuvOS distribution to AArch64
* Make LuvOS images readily available
* Require hardware vendors to actively test against old and new
kernels.
* Status:
* LuvOS and FWTS ported to arm64; patches in mainline; additional
test cases being written.
* CI loop set up to run FWTS on Foundation model for each -rc
merge of Linus' tree into leg-kernel.
* AMD Seattle results pending updated kernel patches.
* LuvOS details at https://wiki.linaro.org/LEG/Engineering/luvOS
4. Set clear expectations for those providing ACPI for use with Linux
* Problem:
* Hardware/Firmware vendors can and will create ACPI tables that
cannot be used by Linux without some guidance
* Kernel developers cannot determine whether the kernel or
firmware is broken without knowing what the firmware should do
* Solution: document the expectations, and iterate as needed.
Enforce when we must.
* Status: kernel text updated and under heavy discussion, AMD has
made their guidance document available, and starting to coordinate
content with SBBR; firmware summit date and location seems firm,
agenda being updated.
5. Platform support patches need verification and review
* Problem: the core Aarch64 patches have been reviewed and are in
good shape, but there is not yet a good example of server platform
support patches that use them.
* Solution: post *good* patches for multiple ACPI platforms,
demonstrating that both the core patches work, and that the use of
the ACPI core makes sense.
* Status:
* ACPI core works on at least the Foundation model, Juno, APM
Mustang, and AMD Seattle
* FWTS results for the Foundation model have been posted
* First version for AMD Seattle has been posted to the public
linaro-acpi mailing list for initial review, refined versions to
be posted to broader lists after a few iterations for basic
cleanup
6. How does the kernel handle_DSD usage?
* Problem:
* _DSD defines key-value properties in the DT style. How do we
ensure _DSD bindings are well defined?
* How do we ensure DT and _DSD bindings remain consistent with
each other?
* Solution: public documentation for all bindings, and a process for
defining them
* Status: proposal to require patch authors to point at public
binding documentation; kernel Documentation/devicetree/bindings
remains the default if no other location exists; UEFI forum has
set up a binding repository. Discussion continues.
7. Why is ACPI required?
* Problem:
* arm64 maintainers still haven't been convinced that ACPI is
necessary.
* Why do hardware and OS vendors say ACPI is required?
* Solution: discussions between those who want ACPI and arm64
maintainers
* Status: Grant has provided a blog post at
http://www.secretlab.ca/archives/151. Al will roll that content
into the kernel documentation, also.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
On 2015年01月08日 17:26, Ashok Kumar wrote:
> On Thu, Jan 08, 2015 at 04:00:37PM +0800, Hanjun Guo wrote:
>> On 2015???01???07??? 21:32, Ashok Kumar wrote:
>>> Also provided pcibus_to_node and cpumask_of_pcibus
>>> based on x86.
>>>
>>> Signed-off-by: Ashok Kumar <ashoks(a)broadcom.com>
>>> ---
>>> Hanjun,
>>> This patch is based on your acpi numa patchset and leg-kernel.
>>> Tested it on qemu using generic pci host controller.
>>> could you add this to your set of patches if it is fine?
>>> Thanks!
>>
>> sure, I will. thanks for your patch!
>>
>> I already fixed the call trace of early_ioremap memory
>> leak, will send another version.
> Hanjun,
>
> Thanks!
>
> I just noticed the call to numa_add_memblk in acpi_numa_memory_affinity_init should use ma->length
> as the second param. The syntax of numa_add_memblk is numa_add_memblk(u32 nid, u64 base, u64 size).
>
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> index 44de133..b5fc732 100644
> --- a/arch/arm64/kernel/acpi_numa.c
> +++ b/arch/arm64/kernel/acpi_numa.c
> @@ -147,7 +147,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> goto out_err_bad_srat;
> }
>
> - if (numa_add_memblk(node, start, end) < 0)
> + if (numa_add_memblk(node, start, ma->length) < 0)
Good catch! I didn't notice Ganapat updated the numa_add_memblk()
API for ARM64.
> goto out_err_bad_srat;
>
> node_set(node, numa_nodes_parsed);
>
> Ganapat,
> Is it possible to change the info prints of numa_add_memblk_to like below
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 7bead6a..f293182 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -194,7 +194,7 @@ static int __init numa_add_memblk_to(int nid, u64 start, u64 end,
> }
>
> pr_info("NUMA: Adding memblock %d [0x%llx - 0x%llx] on node %d\n",
> - mi->nr_blks, start, end, nid);
> + mi->nr_blks, start, end - 1, nid);
I think this is reasonable, 0x60000000 is belong to another
block I think.
Thanks
Hanjun