Re: [PATCH 1/3 v2] Documentation/arm64: Update ARM and arch reference

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 6/6/2023 11:35 AM, 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@xxxxxxx>
> Cc: Jeremy Linton <Jeremy.Linton@xxxxxxx>
> Cc: James Morse <James.Morse@xxxxxxx>
> Cc: Rob Herring <Rob.Herring@xxxxxxx>
> Cc: Will Deacon <will@xxxxxxxxxx>
> Cc: Jonathan Corbet <corbet@xxxxxxx>
> Cc: Hanjun Guo <guohanjun@xxxxxxxxxx>
> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> Cc: linux-doc@xxxxxxxxxxxxxxx
> Cc: linux-acpi@xxxxxxxxxxxxxxx
>
> Signed-off-by: Jose Marinho <jose.marinho@xxxxxxx>
> Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@xxxxxxx>
> ---
>  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.

Not part of this patch, but while at it maybe fix the  http://www.uefi.org/workinggroup
that doesn't work - it returns 404.


>  
> -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
>                         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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux