The existing uninstall call was passing the wrong handle (parent object,
not the correct child object) and additionally passing the address
of a pointer to the interface to be removed rather than the pointer
itself, so always failed with EFI_NOT_FOUND.
While it might seem attractive to ASSERT to ensure that the uninstall
proceeds as expected, uninstallation of protocol interfaces is allowed
to fail under the UEFI model. An ASSERT could therefore result in a
sequence of events which is perfectly valid - or at least is out of
the control of this driver - resulting in an ASSERT() failure.
Cc: Michael Brown <mc...@ipxe.org>
Cc: Maciej Rabeda <maciej.rab...@linux.intel.com>
Cc: Jiaxin Wu <jiaxin...@intel.com>
Signed-off-by: Mike Beaton <mjsbea...@gmail.com>
xyz
---
NetworkPkg/HttpBootDxe/HttpBootImpl.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
index b4c61925b9..f78eef4a83 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
@@ -77,11 +77,19 @@ HttpBootUninstallCallback (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
+ EFI_HANDLE ControllerHandle;
+
if (Private->HttpBootCallback == &Private->LoadFileCallback) {
+ if (!Private->UsingIpv6) {
+ ControllerHandle = Private->Ip4Nic->Controller;
+ } else {
+ ControllerHandle = Private->Ip6Nic->Controller;
+ }
+
gBS->UninstallProtocolInterface (
- Private->Controller,
+ ControllerHandle,
&gEfiHttpBootCallbackProtocolGuid,
- &Private->HttpBootCallback
+ Private->HttpBootCallback
);
Private->HttpBootCallback = NULL;
}
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117470): https://edk2.groups.io/g/devel/message/117470
Mute This Topic: https://groups.io/mt/105371091/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
