<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/arch/arm64/kernel/acpi.c, branch update-toolchain</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/arch/arm64/kernel/acpi.c?h=update-toolchain</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/arch/arm64/kernel/acpi.c?h=update-toolchain'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2024-07-11T18:10:02Z</updated>
<entry>
<title>Merge branch 'for-next/vcpu-hotplug' into for-next/core</title>
<updated>2024-07-11T18:10:02Z</updated>
<author>
<name>Catalin Marinas</name>
<email>catalin.marinas@arm.com</email>
</author>
<published>2024-07-11T18:10:02Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=4f3a6c4de7d932be94cde2c52ae58feeec9c9dbf'/>
<id>urn:sha1:4f3a6c4de7d932be94cde2c52ae58feeec9c9dbf</id>
<content type='text'>
* for-next/vcpu-hotplug: (21 commits)
  : arm64 support for virtual CPU hotplug (ACPI)
  irqchip/gic-v3: Fix 'broken_rdists' unused warning when !SMP and !ACPI
  arm64: Kconfig: Fix dependencies to enable ACPI_HOTPLUG_CPU
  cpumask: Add enabled cpumask for present CPUs that can be brought online
  arm64: document virtual CPU hotplug's expectations
  arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled.
  arm64: arch_register_cpu() variant to check if an ACPI handle is now available.
  arm64: psci: Ignore DENIED CPUs
  irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs
  irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
  arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
  arm64: acpi: Move get_cpu_for_acpi_id() to a header
  ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
  ACPI: scan: switch to flags for acpi_scan_check_and_detach()
  ACPI: processor: Register deferred CPUs from acpi_processor_get_info()
  ACPI: processor: Add acpi_get_processor_handle() helper
  ACPI: processor: Move checks and availability of acpi_processor earlier
  ACPI: processor: Fix memory leaks in error paths of processor_add()
  ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add()
  ACPI: processor: Drop duplicated check on _STA (enabled + present)
  cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER
  ...
</content>
</entry>
<entry>
<title>ACPI: Add acpi=nospcr to disable ACPI SPCR as default console on ARM64</title>
<updated>2024-07-04T15:33:13Z</updated>
<author>
<name>Liu Wei</name>
<email>liuwei09@cestc.cn</email>
</author>
<published>2024-06-25T03:05:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=f5a4af3c752704272e9094466e66e21d4ee4e414'/>
<id>urn:sha1:f5a4af3c752704272e9094466e66e21d4ee4e414</id>
<content type='text'>
For varying privacy and security reasons, sometimes we would like to
completely silence the _serial_ console, and only enable it when needed.

But there are many existing systems that depend on this _serial_ console,
so add acpi=nospcr to disable console in ACPI SPCR table as default
_serial_ console.

Signed-off-by: Liu Wei &lt;liuwei09@cestc.cn&gt;
Suggested-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Suggested-by: Will Deacon &lt;will@kernel.org&gt;
Suggested-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Hanjun Guo &lt;guohanjun@huawei.com&gt;
Reviewed-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Link: https://lore.kernel.org/r/20240625030504.58025-1-liuwei09@cestc.cn
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled.</title>
<updated>2024-06-28T17:38:32Z</updated>
<author>
<name>Jonathan Cameron</name>
<email>Jonathan.Cameron@huawei.com</email>
</author>
<published>2024-05-29T13:34:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=9d0873892f4d4bf62a351897e91e5169b4c6f4aa'/>
<id>urn:sha1:9d0873892f4d4bf62a351897e91e5169b4c6f4aa</id>
<content type='text'>
In order to move arch_register_cpu() to be called via the same path
for initially present CPUs described by ACPI and hotplugged CPUs
ACPI_HOTPLUG_CPU needs to be enabled.

The protection against invalid IDs in acpi_map_cpu() is needed as
at least one production BIOS is in the wild which reports entries
in DSDT (with no _STA method, so assumed enabled and present)
that don't match MADT.

Tested-by: Miguel Luis &lt;miguel.luis@oracle.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Link: https://lore.kernel.org/r/20240529133446.28446-18-Jonathan.Cameron@huawei.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: FFH: Move ACPI specific code into drivers/acpi/arm64/</title>
<updated>2024-06-13T09:18:40Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2024-06-05T13:14:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=7a7a1cac3c2f5e3c859efb295bad3469e09e6f8f'/>
<id>urn:sha1:7a7a1cac3c2f5e3c859efb295bad3469e09e6f8f</id>
<content type='text'>
The ACPI FFH Opregion code can be moved out of arm64 arch code as
it just uses SMCCC. Move all the ACPI FFH Opregion code into
drivers/acpi/arm64/ffh.c

Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Hanjun Guo &lt;guohanjun@huawei.com&gt;
Link: https://lore.kernel.org/r/20240605131458.3341095-4-sudeep.holla@arm.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: acpi: Honour firmware_signature field of FACS, if it exists</title>
<updated>2024-04-18T15:17:33Z</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw@amazon.co.uk</email>
</author>
<published>2024-03-11T13:04:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=fbaad243b5368f19c1e96dc9d914eefaebcb6ecc'/>
<id>urn:sha1:fbaad243b5368f19c1e96dc9d914eefaebcb6ecc</id>
<content type='text'>
If the firmware_signature changes then OSPM should not attempt to resume
from hibernate, but should instead perform a clean reboot. Set the global
swsusp_hardware_signature to allow the generic code to include the value
in the swsusp header on disk, and perform the appropriate check on resume.

Signed-off-by: David Woodhouse &lt;dwmw@amazon.co.uk&gt;
Acked-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt;
Link: https://lore.kernel.org/r/20240412073530.2222496-3-dwmw2@infradead.org
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: acpi: Fix possible memory leak of ffh_ctxt</title>
<updated>2023-02-24T14:21:49Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2023-02-23T13:57:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=1b561d3949f8478c5403c9752b5533211a757226'/>
<id>urn:sha1:1b561d3949f8478c5403c9752b5533211a757226</id>
<content type='text'>
Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version
and conduit checks fail and -EOPNOTSUPP is returned without freeing the
allocated memory.

Fix the same by moving the allocation after the SMCCC version and
conduit checks.

Fixes: 1d280ce099db ("arm64: Add architecture specific ACPI FFH Opregion callbacks")
Cc: &lt;stable@vger.kernel.org&gt; # 6.2.x
Cc: Will Deacon &lt;will@kernel.org&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Reported-by: Dan Carpenter &lt;error27@gmail.com&gt;
Suggested-by: Dan Carpenter &lt;error27@gmail.com&gt;
Link: https://lore.kernel.org/r/202302191417.dAl9NuE8-lkp@intel.com/
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Link: https://lore.kernel.org/r/20230223135742.2952091-1-sudeep.holla@arm.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: Add architecture specific ACPI FFH Opregion callbacks</title>
<updated>2022-11-14T18:09:07Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2022-11-10T13:45:05Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=1d280ce099db396e092cac1aa9bf2ea8beee6d76'/>
<id>urn:sha1:1d280ce099db396e092cac1aa9bf2ea8beee6d76</id>
<content type='text'>
FFH Operation Region space can be used to trigger SMC or HVC calls,
using the Arm SMC Calling Convention (SMCCC). The choice of conduit
(SMC or HVC) is based on what the kernel choose based on PSCI as with
any other users of SMCCC within the kernel.

Function identifiers only in the SMCCC SiP Service, OEM Service and FF-A
specific call range are allowed in FFH Opregions.

Offset can be either 0(32 bit calling convention) or 1(64 bit calling
convention). The length must be set with the range applicable based
on the value of the offset.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>arm64: mm: Convert to GENERIC_IOREMAP</title>
<updated>2022-06-27T11:22:31Z</updated>
<author>
<name>Kefeng Wang</name>
<email>wangkefeng.wang@huawei.com</email>
</author>
<published>2022-06-07T12:50:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=f23eab0bfaefb3319c7de90c9c632bebf53a03bc'/>
<id>urn:sha1:f23eab0bfaefb3319c7de90c9c632bebf53a03bc</id>
<content type='text'>
Add hook for arm64's special operation when ioremap(), then
ioremap_wc/np/cache is converted to use ioremap_prot() from
GENERIC_IOREMAP, update the Copyright and kill the unused
inclusions.

Reviewed-by: Anshuman Khandual &lt;anshuman.khandual@arm.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Kefeng Wang &lt;wangkefeng.wang@huawei.com&gt;
Link: https://lore.kernel.org/r/20220607125027.44946-6-wangkefeng.wang@huawei.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: Simplify checking for populated DT</title>
<updated>2021-12-06T16:12:53Z</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2021-10-29T14:40:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=b6363fe7b5135bfb5aea03f414148b3c2417702e'/>
<id>urn:sha1:b6363fe7b5135bfb5aea03f414148b3c2417702e</id>
<content type='text'>
Use of the of_scan_flat_dt() function predates libfdt and is discouraged
as libfdt provides a nicer set of APIs. Rework dt_scan_depth1_nodes to
use libfdt calls directly, and rename it to dt_is_stub() to reflect
exactly what it checking.

Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Link: https://lore.kernel.org/r/20211029144055.2365814-1-robh@kernel.org
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>Revert "ACPI: Add memory semantics to acpi_os_map_memory()"</title>
<updated>2021-09-23T18:39:36Z</updated>
<author>
<name>Jia He</name>
<email>justin.he@arm.com</email>
</author>
<published>2021-09-23T03:35:57Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=12064c1768439fa0882547010afae6b52aafa7af'/>
<id>urn:sha1:12064c1768439fa0882547010afae6b52aafa7af</id>
<content type='text'>
This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.

The memory semantics added in commit 437b38c51162 causes SystemMemory
Operation region, whose address range is not described in the EFI memory
map to be mapped as NormalNC memory on arm64 platforms (through
acpi_os_map_memory() in acpi_ex_system_memory_space_handler()).

This triggers the following abort on an ARM64 Ampere eMAG machine,
because presumably the physical address range area backing the Opregion
does not support NormalNC memory attributes driven on the bus.

 Internal error: synchronous external abort: 96000410 [#1] SMP
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
 Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[...snip...]
 Call trace:
  acpi_ex_system_memory_space_handler+0x26c/0x2c8
  acpi_ev_address_space_dispatch+0x228/0x2c4
  acpi_ex_access_region+0x114/0x268
  acpi_ex_field_datum_io+0x128/0x1b8
  acpi_ex_extract_from_field+0x14c/0x2ac
  acpi_ex_read_data_from_field+0x190/0x1b8
  acpi_ex_resolve_node_to_value+0x1ec/0x288
  acpi_ex_resolve_to_value+0x250/0x274
  acpi_ds_evaluate_name_path+0xac/0x124
  acpi_ds_exec_end_op+0x90/0x410
  acpi_ps_parse_loop+0x4ac/0x5d8
  acpi_ps_parse_aml+0xe0/0x2c8
  acpi_ps_execute_method+0x19c/0x1ac
  acpi_ns_evaluate+0x1f8/0x26c
  acpi_ns_init_one_device+0x104/0x140
  acpi_ns_walk_namespace+0x158/0x1d0
  acpi_ns_initialize_devices+0x194/0x218
  acpi_initialize_objects+0x48/0x50
  acpi_init+0xe0/0x498

If the Opregion address range is not present in the EFI memory map there
is no way for us to determine the memory attributes to use to map it -
defaulting to NormalNC does not work (and it is not correct on a memory
region that may have read side-effects) and therefore commit
437b38c51162 should be reverted, which means reverting back to the
original behavior whereby address ranges that are mapped using
acpi_os_map_memory() default to the safe devicenGnRnE attributes on
ARM64 if the mapped address range is not defined in the EFI memory map.

Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
Signed-off-by: Jia He &lt;justin.he@arm.com&gt;
Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
