Branch: refs/heads/master
  Home:   https://github.com/tianocore/edk2
  Commit: afdae789cd0d33c6f7debce2fc41f1af4946d869
      
https://github.com/tianocore/edk2/commit/afdae789cd0d33c6f7debce2fc41f1af4946d869
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/CpuDxe/CpuDxe.c

  Log Message:
  -----------
  ArmPkg/CpuDxe: Fix error handling in driver initialization

Failure to install the CPU arch protocol is a fatal error, so treat it
as such, rather than ignore it, even though we won't get very far if
this driver fails to dispatch - at least, we will get an error in a
DEBUG build rather than a mysterious failure due to unsatisfied DEPEXes.

Failure to install the idle loop event handler is not a fatal error, and
it should not cause the driver to exit with an error, as this will
unload the driver and keep the installed CPU arch protocol pointer
dangling. So keep the ASSERT() on the return value, but return
EFI_SUCCESS once we're past the point where the CPU arch protocol has
been installed.

Since the protocol is never uninstalled, make the CPU handle function
local, as there is no point in keeping its value around.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: e5b56d6ef9fb028957683fd546347edf5232a024
      
https://github.com/tianocore/edk2/commit/e5b56d6ef9fb028957683fd546347edf5232a024
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/CpuDxe/CpuDxe.c
    M ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c

  Log Message:
  -----------
  ArmPkg/CpuDxe: Use STATIC linkage where possible

Use static linkage for variables and routines that are not referenced
from other objects. This is generally preferred, because it gives the
compiler more freedom for optimization.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: 0422dd0669b9e6f50c4d07e3496a2173b8eb611f
      
https://github.com/tianocore/edk2/commit/0422dd0669b9e6f50c4d07e3496a2173b8eb611f
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/CpuDxe/CpuDxe.c
    M ArmPkg/Drivers/CpuDxe/CpuDxe.h
    M ArmPkg/Drivers/CpuDxe/Exception.c

  Log Message:
  -----------
  ArmPkg/CpuDxe: Remove rudimentary vector handoff logic

There is some fossilized code in the CpuDxe driver startup code that
permits a vector table to be inherited from the PEI stage, but this code
is essentially dead on ARM platforms, given that the VectorInfo argument
passed to InitializeCpuExceptionHandlers() is ignored, and no code
appears to exist that would result in the gEfiVectorHandoffTableGuid
configuration table ever being populated.

Also, due to prior refactoring, the code that disables and re-enables
IRQs and FIQs is completely pointless, and can simply be removed. That,
in turn, allows the CPU arch protocol parameter to be dropped from the
prototype of InitializeExceptions().

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: fb7497cbf9dc6c1b20976dd0abe724166c463a56
      
https://github.com/tianocore/edk2/commit/fb7497cbf9dc6c1b20976dd0abe724166c463a56
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/CpuDxe/CpuDxe.c
    M ArmPkg/Drivers/CpuDxe/CpuDxe.inf

  Log Message:
  -----------
  ArmPkg/CpuDxe: Replace DEPEX on h/w protocol with event notification

Currently, ArmPkg's CpuDxe DEPEXes on the hardware interrupt protocol,
to ensure that it is not dispatched before the GIC driver. This way, the
CpuDxe driver is guaranteed not to enable interrupts on the CPU side
before the GIC driver has had the opportunity to configure the
interrupts on the distribution side.

However, this prevents the GIC driver from using any of the CPU arch
protocol interfaces, such as mapping memory, which it may need to do on
platforms where the GIC MMIO regions are not mapped yet when the driver
is started.

So instead, use a protocol notification on the hardware interrupt
protocol, which is installed by the GIC driver (as well as other
existing interrupt controller drivers for platforms that do not
implement a GIC) after it starts up and deasserts and disables all
incoming interrupts. Manipulate the interrupt state as usual only after
this notification has been received. Before that, keep track of the
caller's intent regarding the interrupt enabled state in a shadow
variable, but do not actually enable interrupt delivery to the CPU just
yet.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: 387fcf4fa19cd0f90363683d492b5b6fb31c0844
      
https://github.com/tianocore/edk2/commit/387fcf4fa19cd0f90363683d492b5b6fb31c0844
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/ArmGicDxe/ArmGicCommonDxe.c
    M ArmPkg/Drivers/ArmGicDxe/ArmGicDxe.h
    M ArmPkg/Drivers/ArmGicDxe/ArmGicDxe.inf
    M ArmPkg/Drivers/ArmGicDxe/ArmGicV2Dxe.inf
    M ArmPkg/Drivers/ArmGicDxe/ArmGicV3Dxe.inf

  Log Message:
  -----------
  ArmPkg/ArmGicDxe: Replace CpuArch registration event with DEPEX

Instead of relying on a protocol notification event to register the core IRQ
interrupt handler with CPU arch protocol once it becomes available, use
a DEPEX to ensure that the GIC driver is not dispatched at all until the
CPU arch protocol has turned up.

This will allow the GIC driver to use other CPU arch protocol methods,
such as the ones needed to map the GIC MMIO regions at driver startup.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: e68e7846497ebeebab078a4986b97ccc1054ebba
      
https://github.com/tianocore/edk2/commit/e68e7846497ebeebab078a4986b97ccc1054ebba
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/ArmGicDxe/GicV3/ArmGicV3Dxe.c

  Log Message:
  -----------
  ArmPkg/ArmGicDxe: Avoid pointless repeated iteration over GIC frames

The GIC DXE driver only runs on the boot CPU, and so there is really no
point in iterating over all the redistributor frames every time an
interrupt is enabled, disabled or its state tested. Instead, do this
only at load time.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: 3c4c7a0fc98552a7a3f7866f06a49b2b4b8fa565
      
https://github.com/tianocore/edk2/commit/3c4c7a0fc98552a7a3f7866f06a49b2b4b8fa565
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/ArmGicDxe/GicV3/ArmGicV3Dxe.c

  Log Message:
  -----------
  ArmPkg/ArmGicDxe: Remove pointless passing around of MMIO addresses

The GIC distributor and redistributor addresses that are passed into the
interrupt enable and disable routines are always the same, so just use
the global variables directly.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: c558a3b18b45348670e00bc3e7644d39c701fce3
      
https://github.com/tianocore/edk2/commit/c558a3b18b45348670e00bc3e7644d39c701fce3
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmPkg/Drivers/ArmGicDxe/ArmGicCommonDxe.c
    M ArmPkg/Drivers/ArmGicDxe/GicV2/ArmGicV2Dxe.c
    M ArmPkg/Drivers/ArmGicDxe/GicV3/ArmGicV3Dxe.c

  Log Message:
  -----------
  ArmPkg/ArmGicDxe: Map GIC MMIO regions before use

The GIC driver itself has intimate knowledge of the hardware, and so it
is the best suited to create the mappings of the MMIO control regions,
in case they have not been mapped yet by the platform code.

So call in the the CPU arch protocol to map the CPU interface,
distributor and redistributor regions as they are discovered by the GIC
driver startup code.

Note that creating these mappings has no effect if the regions in
question have already been mapped with the correct attributes.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: 43233ff9f88e5c9b88228810f7725bade4cdfecf
      
https://github.com/tianocore/edk2/commit/43233ff9f88e5c9b88228810f7725bade4cdfecf
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-01-30 (Thu, 30 Jan 2025)

  Changed paths:
    M ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c

  Log Message:
  -----------
  ArmVirtPkg/ArmVirtQemu: Reduce MMIO region mapped by default

Currently, the ArmVirtQemu startup code maps a 128 MiB of MMIO space, as
it knows that the UART, GIC and RTC live there. Now that the GIC driver
maps its MMIO registers itself, there is no need for this region to
cover its MMIO space. And there are other regions here that don't need
to be mapped by default: the only ones that need to be mapped are the
UARTS, the RTC, the fw_cfg MMIO interface and the virtio-mmio regions,
all of which live in a 32 MiB window starting at address 0x900_0000.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


Compare: https://github.com/tianocore/edk2/compare/b64f735867ea...43233ff9f88e

To unsubscribe from these emails, change your notification settings at 
https://github.com/tianocore/edk2/settings/notifications


_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits

Reply via email to