Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Michael D Kinney [Tue, 22 Oct 2019 23:50:32 +0000 (16:50 -0700)]
SecurityPkg: Change EFI_D_INFO to DEBUG_INFO
Update DEBUG() macro to use DEBUG_INFO to address PatchCheck.py error.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Add the UefiFileHandleLib to the [Components] section of the
MdePkg DSC file to support full build testing of the MdePkg.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Peter Jones [Fri, 20 Sep 2019 18:45:07 +0000 (14:45 -0400)]
OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE
Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
tests check if it's defined or not. Additionally, in UefiPayloadPkg as
well as some other trees, we define it as FALSE in the .dsc file.
This patch changes all of the Ovmf platforms to explicitly define it as
FALSE by default, and changes all of the checks to test if the value is
TRUE.
Signed-off-by: Peter Jones <pjones@redhat.com>
Message-Id: <20190920184507.909884-1-pjones@redhat.com>
[lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373]
[lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Sami Mujawar [Fri, 18 Oct 2019 09:49:20 +0000 (10:49 +0100)]
DynamicTablesPkg: Arm SRAT Table Generator
The SRAT generator uses the configuration manager protocol
to obtain the affinity information for the GICC, GIC ITS,
Memory, Generic Initiator, etc. and generates the SRAT table.
The table generator supports ACPI 6.3, SRAT table revision 3.
The ACPI and PCI device handles of the Generic Initiator
Affinity structures are represented using tokens. The
generator invokes the configuration manager protocol
interfaces and requests for objects referenced by tokens
to get the device handle information.
The Configuration Manager object definition for the GICC has
been updated to include the Proximity Domain, Clock Domain
and associated flag information. Similarly the Configuration
Manager object for the GIC ITS has been updated to include
the Proximity Domain information. These changes should not
impact any existing implementations as the new fields have
been added towards the end of the Configuration Manager
Objects.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Ard Biesheuvel [Tue, 15 Oct 2019 11:07:42 +0000 (13:07 +0200)]
DynamicTablesPkg: include ARM intrinsics library to fix 32-bit build
DynamicTablesPkg can be built for ARM as well as for AARCH64, but on
the former, doing so will result in a build failure due to the lack
of 64-bit division helpers provided by the ArmPkg intrinsics library.
So add the missing reference, for both ARM and AARCH64 (which may
start relying on intrinsics due to future changes)
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2269 Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Tested-by: Sami Mujawar <sami.mujawar@arm.com>
Rabeda, Maciej [Mon, 14 Oct 2019 12:37:28 +0000 (20:37 +0800)]
NetworkPkg/SnpDxe: Add PCD to remove ExitBootServices event from SNP driver.
Patch addresses Bugzilla #1974.
During ExitBootServices stage, drivers should not call any
functions known to use Memory Allocation Services. One of such
functions (as per UEFI spec) is UNDI->Shutdown().
Since UNDI drivers during ExitBootServices phase are expected
to put the adapter to such a state that it will not perform any DMA
operations, there is no need to interface UNDI by SNP driver during
that phase.
Finally, since ExitBootServices event notification function in SNP
only calls UNDI->Shutdown() and Stop() functions, there is no need
to create this event at all. Adding PCD to control creation of event
reacting to ExitBootServices() call so that systems with UNDIs relying
on SNP to call their Shutdown() and Stop() can still work.
Change-Id: Idd76f26d2e8ff7cf88b2d75e2d524c74211f2e89 Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Maciej Rabeda <maciej.rabeda@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Catch WM mouse events and expose them via the SimplePointer protocol.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Marvin Haeuser <mhaeuser@outlook.de>
Ashish Singhal [Tue, 15 Oct 2019 17:20:47 +0000 (01:20 +0800)]
MdeModulePkg/XhciPei: Fix Aligned Page Allocation
Add support for allocating aligned pages at an alignment higher
than 4K. The new function allocated memory taking into account
the padding required and then frees up unused pages before mapping
it.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Ashish Singhal [Tue, 15 Oct 2019 17:20:46 +0000 (01:20 +0800)]
MdeModulePkg/XhciDxe: Fix Aligned Page Allocation
While allocating pages aligned at an alignment higher than
4K, allocate memory taking into consideration the padding
required for that alignment. The calls to free pages takes
care of this already.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Add NULL library resolution of CompilerIntrinsicsLib and
BaseStackCheckLib for AARCH64 as well as ARM in order to
fix "undefined reference to `memcpy'" build errors.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
commit a7e2d20193e853020a1415c25b53280955055394 introduces the code to
get PcdTpm2AcpiTableRev in the driver entry point. This PCD is designed as
DynamicHii or DynamicHiiEx PCD. So, this PCD depends on Variable service.
To make sure PcdTpm2AcpiTableRev value be got, add Variable service as Depex.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: jiewen Yao <jiewen.yao@intel.com>
BaseTools: Fix an incremental build issue caused by macro in #include
When c/h file use macro after #include, for example,
In this case, GenMake is not able to create a healthy dependency for the c
file. GenMake used to add $(FORCE_REBUILD) dependency in the c file, this
guarantee the c file is always compiled in incremental build. But, this
function is broken since 05217d210e8da37b47d0be58ec363f7af2fa1c18 which
enable /MP for MSVC compiler, in order to compile multiple c files in one
command multi-processing. The fix here is adding '$(FORCE_REBUILD)' back to
retain the original function.
Line number 1728 and 978 are the code pieces which handle this logic.
Signed-off-by: Derek Lin <derek.lin2@hpe.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Similar to what we now do for OVMF, we need to consider the possibility
that PlatformBootManagerWaitCallback () may be called with a
PcdPlatformBootTimeOut that was set to zero, in which case the call should
simply return.
We also change the initial timeout variable name to make the code explicit.
Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-3-pete@akeo.ie>
Independently of how we decide to address other aspects of the regression
introduced with commit 2de1f611be06ded3a59726a4052a9039be7d459b, it doesn't
make much sense to call for a progress update if PcdPlatformBootTimeOut is
zero.
PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero)
should be considered to indicate that a platform is not interested in
displaying a progress report, so we alter PlatformBootManagerWaitCallback
to behave that way.
We also change one variable name to make the code more explicit.
Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-2-pete@akeo.ie>
Commit 2de1f611be06ded3a59726a4052a9039be7d459b introduced a regression
whereas platforms that did set PcdPlatformBootTimeOut to 0 are now getting
an unexpected call to PlatformBootManagerWaitCallback().
This patch also ensures that, if PcdPlatformBootTimeOut is 0xFFFF we don't
call PlatformBootManagerWaitCallback() with a zero argument as doing so
would produce an unwarranted jump to full progress completion which is
likely to throw off users.
Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Liming Gao <liming.gao@intel.com>
The command used by multiple thread genffs feature in makefile
for testing if file exist is generated based on the toolchain family.
It should be based on the OS type.
Laszlo Ersek [Mon, 7 Oct 2019 12:05:28 +0000 (14:05 +0200)]
UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detection
- If a platform boots such that the boot CPU count is smaller than
PcdCpuMaxLogicalProcessorNumber, then the platform cannot use the "fast
AP detection" logic added in commit 6e1987f19af7. (Which has been
documented as a subset of use case (2) in the previous patch.)
Said logic depends on the boot CPU count being equal to
PcdCpuMaxLogicalProcessorNumber. If the equality does not hold, the
platform either has to wait too long, or risk missing APs due to an
early timeout.
- The platform may not be able to use the variant added in commit 0594ec417c89 either. (Which has been documented as use case (1) in the
previous patch.)
See commit 861218740d6d. When OVMF runs on QEMU/KVM, APs may check in
with the BSP in arbitrary order, plus the individual AP may take
arbitrarily long to check-in. If "NumApsExecuting" falls to zero
mid-enumeration, APs will be missed.
Allow platforms to specify the exact boot CPU count, independently of
PcdCpuMaxLogicalProcessorNumber. In this mode, the BSP waits for all APs
to check-in regardless of timeout. If at least one AP fails to check-in,
then the AP enumeration hangs forever. That is the desired behavior when
the exact boot CPU count is known in advance. (A hung boot is better than
an AP checking-in after timeout, and executing code from released
storage.)
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Laszlo Ersek [Thu, 10 Oct 2019 09:07:39 +0000 (11:07 +0200)]
UefiCpuPkg/MpInitLib: expand comment on initial AP enumeration
Before adding another AP enumeration mode, clarify the documentation on
the current logic. No functional changes.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
image handle.
But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
Compilers have not flagged it because EFI_HANDLE (the type of
"ImageHandle") is unfortunately specified as (VOID*), and
(EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
Hand the entry point function's "ImageHandle" parameter to
ReserveResourceInGcd(). This fixes an actual bug.
Cc: Benjamin You <benjamin.you@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
(This patch is unrelated to the rest of this series; its purpose is to
enable building the UefiPayloadPkg DSC files with GCC.)
When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the
DEBUG target, the compiler reports that "Entry32" may be used
uninitialized in ParseAcpiInfo(), in the XSDT branch.
Code inspection proves the compiler right. In the XSDT branch, the code
from the RSDT branch must have been duplicated, and "Entry32" references
were replaced with "Entry64" -- except where "MmCfgHdr" is assigned.
Fix this bug by introducing a helper variable called "Signature", so that
we have to refer to "Entry32" or "Entry64" only once per loop body.
Cc: Benjamin You <benjamin.you@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
that every firmware volume is processed only once (every driver in every
firmware volume should be discovered only once). For this, the functions
use a linked list.
In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
those firmware volumes that have been processed is the EFI_HANDLE on which
the DXE or SMM firmware volume protocol is installed. In the
StandaloneMmPkg core however, the key is the address of the firmware
volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
(EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
EFI_HANDLE just happens to be specified as (VOID*), and therefore the
conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
(The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
conversion.)
We should not exploit this circumstance. Represent the key type faithfully
instead.
This is a semantic fix; there is no change in operation.
ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
The EDK 1 Shell (available at <https://github.com/tianocore/edk-Shell>)
has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
edk2's UefiShellLib has no choice but to work around.
Improve the explanation in the code. Also, document the implicit
EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
dereferencing ParentHandle, with an explicit cast.
In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory
Can Not Be Saved".
The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
called "FileHandle", and correctly passes the de-referenced (*FileHandle)
to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.
However, FileBufferSave() passes SHELL_FILE_HANDLE to ShellCloseFile(),
not the expected (SHELL_FILE_HANDLE*). Correct it.
This fixes an actual bug that has remained hidden for two reasons:
- pointer-to-VOID converts from/to any pointer-to-object type silently,
- the bug is on an error path which has likely never fired in practice.
Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
However, their parameter lists say EFI_HANDLE.
Spell out the right type in the parameter lists.
In practice, this change is a no-op (because, quite regrettably, both
EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of (VOID*)).
Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
and destructor functions that implement the following pattern:
HiiRemovePackages (gHiiHandle);
The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.
The DynamicCommand lib instances use a similar pattern, so they are
affected too.
NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.
Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
objects to ConvertAndConnectControllers(), and
ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.
This typo is masked because (VOID*) converts to and from any
pointer-to-object type silently.
Note that functionally speaking there is no problem, so this patch does
not change beavior, only cleans up the code.
Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
This change is a no-op in practice; it's a semantic improvement.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are all in Unload() functions, which are probably exercised
infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jian Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from
HiiAddPackages() and (b) is ultimately passed to HiiSetString() and
HiiUpdateForm(). The intermediate functions PopulateForm() and
CreateResolutionOptions() however take that parameter as an
(EFI_HII_HANDLE*).
There is no bug in practice (because the affected functions never try to
de-reference the "PackageList" parameter, they just pass it on), but the
function prototypes are semantically wrong. Fix that.
This could remain hidden so long because pointer-to-VOID silently converts
to/from any pointer-to-object type, and the UEFI spec mandates that
EFI_HII_HANDLE be a typedef to (VOID*).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
Fix the call in the notification function of
"EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".
This is an actual bug. The reason it's never been triggered is likely that
the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
itself has zero instances of that, for example.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
This is an actual bug. It must have remained hidden until now because it's
on an error path. Fix the UninstallMultipleProtocolInterfaces() call.
Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
The SockFreeFoo() callback function for NetbufFromExt() has to match the
NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument
(Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
SockFreeFoo() parameter list.
This change is a no-op in practice.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle"
parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE,
not (EFI_HANDLE*).
This patch fixes actual bugs. The issues have been dormant likely because
they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
driver is unloaded likely very infrequently.)
NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
NULL-check. Fix the type of "SnpHandle".
This patch is a no-op.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
The BootScriptInsert() and BootScriptLabel() functions take the in/out
parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to
S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively.
The callees take the in/out parameter "Position" as (VOID**). Add explicit
casts for clarity.
There is no change in functionality.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MdeModulePkg/PiSmmCore: make type punning consistent
The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
(SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".
Apply the same cast in the counterpart function SmiHandlerUnRegister(),
which compares multiple "SmiHandler"s against the input "DispatchHandle".
This is a semantic cleanup; there is no functional change.
Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
calls.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()
Clean up two issues around FindFileEx():
- The "AprioriFile" parameter's type differs between the function
declaration and the function definition. The correct type is
(EFI_PEI_FILE_HANDLE*).
- "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
(*AprioriFile).
This is a semantic cleanup, there is no functional change.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration
EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.
This change is a semantic fix; functionally, it's a no-op.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug
The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in
natural language, but the field type in the structure definition itself is
wrong -- it should be EFI_EVENT, not (EFI_EVENT*).
This spec bug is likely unfixable for compatibility reasons, and so edk2
works it around already. We should clearly document the workaround.
Functionally, this patch is a no-op.
(I've also requested a non-normative (informative) clarification for the
PI spec: <https://mantis.uefi.org/mantis/view.php?id=2017>.)
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
order to fetch the device path from it, and then turn the device path into
PATH routing information.
The HiiConstructConfigHdr() function is called from
VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
"VarCleanupManually" in PlatformVarCleanup().
In that case, we create "Private->DriverHandle" as a new handle, and
install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
"Private->DriverHandle" to HiiAddPackages(), which consumes the device
path for routing purposes.
It follows that the "DriverHandle" argument passed to
HiiConstructConfigHdr() should be the same driver handle, for matching
routing.
Currently we pass "Private->HiiHandle", which is clearly a typo, because
it is the return value of HiiAddPackages(), and stands for the published
HII package list.
Therefore this patch addresses an actual bug.
The typo has not been flagged by compilers because the UEFI spec
regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
The same applies to gMmst->MmRegisterProtocolNotify().
"mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
nothing else.
This change is a no-op in practice; it's a semantic improvement.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE
HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
This change is a no-op in practice; it's a semantic improvement.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
(VOID**) converts silently to (VOID*), which is why the wrong cast is
masked.
Note that the *value* that is passed is alright -- therefore this patch
does not change behavior --, it's just semantically wrong to pass an
(EFI_HANDLE*) where an EFI_HANDLE is expected.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.
This change is a semantic fix; functionally, it's a no-op.
Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
"gTimerEvent" has type EFI_EVENT already, drop the superfluous cast.
Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop()
The 3rd and 4th parameters of the CloseProtocol() call are wrong.
Given that we're not dissociating a child controller from a parent
controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER
open, the 4th parameter (ControllerHandle) should equal the 1st parameter
(Handle).
It's unclear why this code hasn't crashed before.
Note that the patch doesn't fix the underlying driver model bug. I don't
understand what the loop in MmcDriverBindingStop() attempts to do. Is this
driver supposed to be a bus driver? It seems to create new handles, and to
append device path nodes. But it doesn't set up proper parent/child
protocol opens, and it doesn't close them.
- The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
IN OUT EFI_HANDLE *ChildHandle
- The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
IN EFI_HANDLE ChildHandle
Fix the DestroyChild() call in TcpFastbootTransportStop().
This is an actual bugfix; I don't know why the current code doesn't crash.
Perhaps the function is never reached in practice? (It could be tied to an
error path.)
This patch is unrelated to the rest of the series; it just makes sure that
"EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
SUPPORTED_ARCHITECTURES (in particular, X64).
Pete Batard [Wed, 25 Sep 2019 15:50:05 +0000 (23:50 +0800)]
MdeModulePkg/BdsDxe: Also call PlatformBootManagerWaitCallback on 0
The existing loop is set to call PlatformBootManagerWaitCallback every
second except the last one. We believe this is a mistake as it prevents
the called code from performing timeout expiration tasks such as, for
instance, ensuring that the last segment of a progress bar is displayed
before continuing (which is a current issue for the RPi3 platform).
Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
MdeModulePkg: Remove network related guid definitions from MdeModulePkg.dec
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2196
Network related guid definitions have been moved into NetworkPkg.dec.
So, they can be removed from MdeModulePkg.dec.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
EmbeddedPkg: convert Lauterbach README.txt to 7-bit safe Readme.md
This file contained what looked like windows 1250 encoded single
quotation marks. Convert them to regular 's. Rework the file to
markdown format and and rename it Readme.md while we're at it.
ArmPkg: ArmScmiDxe - convert .h to from 8859-x to 7-bit
A paragraph sign in a comment came from some ISO8859 encoding,
convert it to the word "section" to remain 7-bit safe, since we're
not actually doing anything special.
BaseTools: fix line endings in SetupGit.py Conf files
A file header license/copyright header copied around in commit 5b3e695d8ac5 ("BaseTools: add centralized location for git config files")
was missing a CR - add it in both faulty locations.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
While looking at encoding and line ending errors, I found this file
in fact simply points to a sourceforge page which no longer exists.
Since there is nothing more to say than "this is an import of
libfdt", let's just delete it.
Commit 0075ab2cec introduced an issue that causes an exception
when multiple workspace packages paths are specified. For example,
if edk2-platforms is used, the root directory will contain an edk
and edk2-platforms directory representing the respective
repositories.
In GenMake, the path to the package DEC file for a module is
discovered by getting the relative path of the INF to the
workspace root directory. Each directory in the relative path
is incrementally joined to the WORKSPACE directory. The file
list in the joined path is searched for a DEC file.
As an example, if the build command is used on a package outside
the edk2 repository, the INF file path is relative to the
edk2-platforms directory not edk2. This causes directory paths
to be built that do not exist. Commit 0075ab2cec replaced the
os.path.exists() call with a try except block that always fails
when os.listdir() is invoked to enumerate the list of files in
the built directory path on packages outside edk2.
This commit restores the original conditional statement which
avoids calling os.listdir() with an invalid directory path.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BaseTools: use stdint.h for GCC ProcessorBind.h typedefs
The AArch64 definitions of UINT64/INT64 differ from the X64 ones.
Since this is on the tool side, doing like X64 and picking the
definitions from stdint.h feels like a better idea than hardcoding
them. So copy the pattern from X64/ProcessorBind.h.
In binary model the same binary may have to support both
S3 enabled and disabled scenarios, however not all DXE
drivers linking PiDxeS3BootScriptLib can return error to
invoke library DESTRUCTOR for releasing resource.
To support this usage model below PCD is used to skip
S3BootScript functions when PCD set to FALSE:
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
Test: Verified on internal platform and S3BootScript
functions can be skipped by PCD during boot time.
BaseTools/LzmaCompress: Fix the option "d" dictionary size
The range of dictionary size is set from [0,30] to [0,27].
And update the help information for this.
The previous logic for processing the parameter dict size is incorrect.
Now fix the logic.
The option "d" is added at 6b80310f34199d1f62e45e40fa902734735091fa.
(https://bugzilla.tianocore.org/show_bug.cgi?id=2077)
This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the
ScsiDiskDxe driver.
Support is currently limited to the RPMB Well-known LUN for UFS devices.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Replacing "magic numbers" in the Peripheral Type check with defines for
the reserved range from IndustryStandard/Scsi.h
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Currently UfsPassThru only checks for 8 common LUNs. This adds a check
for the RPMB Well-known LUN and sets the corresponding bit-mask. Further
handling of the WLUN is already present in the driver.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
This patch implements the Security Protocol In and Security Protocol Out
commands in UefiScsiLib to prepare support for the Storage Security
Command Protocol.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
This patch is going to fix the lib order in static_library_files.lst.
This issue is introduced by commit 673d09a2dd.
Before 673d09a2dd, build tool apply build rule for the module's library
firstly and then apply build rule for module itself. Now, build tool
apply build rule for module self and then for its library. That behavior
impact the lib order in static_library_files.lst.
This patch is to call module's LibraryAutoGenList function
explicitly, where the applying build rule action for
library is triggered.
Cc: Liming Gao <liming.gao@intel.com> Cc: dann frazier <dann.frazier@canonical.com> Signed-off-by: Bob Feng <bob.c.feng@intel.com> Tested-by: dann frazier <dann.frazier@canonical.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
projects / mirror_edk2.git / log