From: Robin Murphy <robin.murphy@arm.com>
To: Jose Marinho <jose.marinho@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Jeremy Linton <Jeremy.Linton@arm.com>,
James Morse <James.Morse@arm.com>,
Rob Herring <Rob.Herring@arm.com>, Will Deacon <will@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Hanjun Guo <guohanjun@huawei.com>,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-acpi@vger.kernel.org,
Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: Re: [PATCH 1/3 v2] Documentation/arm64: Update ARM and arch reference
Date: Tue, 6 Jun 2023 12:50:44 +0100 [thread overview]
Message-ID: <c9b8469e-6e94-2e55-9b39-986f4eb581d3@arm.com> (raw)
In-Reply-To: <20230606093528.1494344-2-jose.marinho@arm.com>
On 2023-06-06 10:35, Jose Marinho wrote:
> This patch clarifies that both Armv8 and v9 are in scope, not
> just Armv8 systems.
> Also, ARM is re-written as Arm.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jeremy Linton <Jeremy.Linton@arm.com>
> Cc: James Morse <James.Morse@arm.com>
> Cc: Rob Herring <Rob.Herring@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Hanjun Guo <guohanjun@huawei.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-acpi@vger.kernel.org
>
> Signed-off-by: Jose Marinho <jose.marinho@arm.com>
> Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
> ---
> Documentation/arm64/arm-acpi.rst | 41 ++++++++++++++++----------------
> 1 file changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst
> index 47ecb9930dde..1cafe38fc7f9 100644
> --- a/Documentation/arm64/arm-acpi.rst
> +++ b/Documentation/arm64/arm-acpi.rst
> @@ -1,40 +1,41 @@
> -=====================
> -ACPI on ARMv8 Servers
> -=====================
> +===================
> +ACPI on Arm systems
> +===================
>
> -ACPI can be used for ARMv8 general purpose servers designed to follow
> -the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
> +ACPI can be used for Armv8 and Armv9 systems designed to follow
> +the Arm SBSA (Server Base System Architecture) [0] and SBBR (Server
> Base Boot Requirements) [1] specifications. Please note that the SBBR
> can be retrieved simply by visiting [1], but the SBSA is currently only
> available to those with an ARM login due to ARM IP licensing concerns.
>
> -The ARMv8 kernel implements the reduced hardware model of ACPI version
> +
> +The Arm kernel implements the reduced hardware model of ACPI version
> 5.1 or later. Links to the specification and all external documents
> it refers to are managed by the UEFI Forum. The specification is
> available at http://www.uefi.org/specifications and documents referenced
> by the specification can be found via http://www.uefi.org/acpi.
>
> -If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
> +If an Arm system does not meet the requirements of the BSA and BBR,
> or cannot be described using the mechanisms defined in the required ACPI
> specifications, then ACPI may not be a good fit for the hardware.
>
> While the documents mentioned above set out the requirements for building
> -industry-standard ARMv8 servers, they also apply to more than one operating
> +industry-standard Arm systems, they also apply to more than one operating
> system. The purpose of this document is to describe the interaction between
> -ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
> +ACPI and Linux only, on an Arm system -- that is, what Linux expects of
> ACPI and what ACPI can expect of Linux.
>
>
> -Why ACPI on ARM?
> +Why ACPI on Arm?
> ----------------
> Before examining the details of the interface between ACPI and Linux, it is
> useful to understand why ACPI is being used. Several technologies already
> exist in Linux for describing non-enumerable hardware, after all. In this
> section we summarize a blog post [2] from Grant Likely that outlines the
> -reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
> +reasoning behind ACPI on Arm systems. Actually, we snitch a good portion
> of the summary text almost directly, to be honest.
>
> -The short form of the rationale for ACPI on ARM is:
> +The short form of the rationale for ACPI on Arm is:
>
> - ACPI’s byte code (AML) allows the platform to encode hardware behavior,
> while DT explicitly does not support this. For hardware vendors, being
> @@ -47,7 +48,7 @@ The short form of the rationale for ACPI on ARM is:
>
> - In the enterprise server environment, ACPI has established bindings (such
> as for RAS) which are currently used in production systems. DT does not.
> - Such bindings could be defined in DT at some point, but doing so means ARM
> + Such bindings could be defined in DT at some point, but doing so means Arm
> and x86 would end up using completely different code paths in both firmware
> and the kernel.
>
> @@ -108,7 +109,7 @@ recent version of the kernel.
>
> Relationship with Device Tree
> -----------------------------
> -ACPI support in drivers and subsystems for ARMv8 should never be mutually
> +ACPI support in drivers and subsystems for Arm should never be mutually
> exclusive with DT support at compile time.
>
> At boot time the kernel will only use one description method depending on
> @@ -121,11 +122,11 @@ time).
>
> Booting using ACPI tables
> -------------------------
> -The only defined method for passing ACPI tables to the kernel on ARMv8
> +The only defined method for passing ACPI tables to the kernel on Arm
> is via the UEFI system configuration table. Just so it is explicit, this
> means that ACPI is only supported on platforms that boot via UEFI.
>
> -When an ARMv8 system boots, it can either have DT information, ACPI tables,
> +When an Arm system boots, it can either have DT information, ACPI tables,
> or in some very unusual cases, both. If no command line parameters are used,
> the kernel will try to use DT for device enumeration; if there is no DT
> present, the kernel will try to use ACPI tables, but only if they are present.
> @@ -448,7 +449,7 @@ ASWG
> ----
> The ACPI specification changes regularly. During the year 2014, for instance,
> version 5.1 was released and version 6.0 substantially completed, with most of
> -the changes being driven by ARM-specific requirements. Proposed changes are
> +the changes being driven by Arm-specific requirements. Proposed changes are
> presented and discussed in the ASWG (ACPI Specification Working Group) which
> is a part of the UEFI Forum. The current version of the ACPI specification
> is 6.1 release in January 2016.
> @@ -456,7 +457,7 @@ is 6.1 release in January 2016.
> Participation in this group is open to all UEFI members. Please see
> http://www.uefi.org/workinggroup for details on group membership.
>
> -It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification
> +It is the intent of the Arm ACPI kernel code to follow the ACPI specification
> as closely as possible, and to only implement functionality that complies with
> the released standards from UEFI ASWG. As a practical matter, there will be
> vendors that provide bad ACPI tables or violate the standards in some way.
> @@ -470,12 +471,12 @@ likely be willing to assist in submitting ECRs.
>
> Linux Code
> ----------
> -Individual items specific to Linux on ARM, contained in the Linux
> +Individual items specific to Linux on Arm, contained in the Linux
> source code, are in the list that follows:
>
> ACPI_OS_NAME
> This macro defines the string to be returned when
> - an ACPI method invokes the _OS method. On ARM64
> + an ACPI method invokes the _OS method. On Arm64
Super-nit: that one should probably be just "Arm" as well, but then this
whole section appears to be erroneous - I don't see anything in mainline
obviously setting ACPI_OS_NAME to anything other than the ACPICA default
of "Microsoft Windows NT", and there is no "acpi_os=" parameter - so it
seems futile to worry about the trivialities within.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> systems, this macro will be "Linux" by default.
> The command line parameter acpi_os=<string>
> can be used to set it to some other value. The
next prev parent reply other threads:[~2023-06-06 11:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 9:35 [PATCH 0/3 v2] Update ACPI documentation for Arm systems Jose Marinho
2023-06-06 9:35 ` [PATCH 1/3 v2] Documentation/arm64: Update ARM and arch reference Jose Marinho
2023-06-06 11:50 ` Robin Murphy [this message]
2023-06-19 12:22 ` Wilczynski, Michal
2023-06-20 6:51 ` Hanjun Guo
2023-06-06 9:35 ` [PATCH 2/3 v2] Documentation/arm64: Update references in arm-acpi Jose Marinho
2023-06-06 11:56 ` Robin Murphy
2023-06-06 9:35 ` [PATCH 3/3 v2] Documentation/arm64: Update ACPI tables from BBR Jose Marinho
2023-06-06 13:37 ` [PATCH 0/3 v2] Update ACPI documentation for Arm systems Sudeep Holla
2023-06-06 23:54 ` Jeremy Linton
2023-06-07 11:02 ` Hanjun Guo
2023-06-14 17:18 ` Catalin Marinas
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=c9b8469e-6e94-2e55-9b39-986f4eb581d3@arm.com \
--to=robin.murphy@arm.com \
--cc=James.Morse@arm.com \
--cc=Jeremy.Linton@arm.com \
--cc=Rob.Herring@arm.com \
--cc=Samer.El-Haj-Mahmoud@arm.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=guohanjun@huawei.com \
--cc=jose.marinho@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).