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>
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>
The UefiShell*CommandsLib instances have constructor functions that do
something like:
gHiiHandle = HiiAddPackages (...);
...
ShellCommandRegisterCommandName (..., gHiiHandle, ...);
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>
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>
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>
In the following call tree:
PlatformInit ()
mInstalledPackages = HiiAddPackages ()
GopInstalled ()
PopulateForm (PackageList = mInstalledPackages)
CreateResolutionOptions (PackageList)
HiiSetString (PackageList
HiiUpdateForm (PackageList)
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>
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 NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD
take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*).
This patch fixes a real bug.
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.)
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
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>
The HandleProtocol() boot service takes an EFI_HANDLE, not an
(EFI_HANDLE*). Remove the bogus cast in the
InternalImageHandleToFvHandle() function.
This is a semantic cleanup; there is no change in behavior.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
- 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.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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).
No functional changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
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>
ShellBinPkg is generated for each edk2 stable tag release.
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2195
This PCD has been moved to NetworkPkg.dec file.
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2195
PcdTftpBlockSize is network related PCD. It should be defined in NetworkPkg.dec.
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
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>
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.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
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.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
A file header license/copyright header copied around in commit
5b3e695d8a ("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.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Laszlo Ersek
Pete Batard
Liming Gao
Leif Lindholm