[efi] Use driver name only from driver binding handles in debug messages

Some non-driver handles may have an installed component name protocol.
In particular, iPXE itself installs these protocols on its SNP device
handles, to simplify the process of delegating GetControllerName()
from our single-instance driver binding protocol to whatever child
controllers the relevant EFI driver may have installed.

For non-driver handles, the device path is more useful as debugging
information than the driver name.  Limit the use of the component name
protocols to handles with a driver binding protocol installed, so that
we will end up using the device path for non-driver handles such as
the SNP device.

Continue to prefer the driver name to the device path for handles with
a driver binding protocol installed, since these will generally map to
things we are likely to conceptualise as drivers rather than as
devices.

Note that we deliberately do not use GetControllerName() to attempt to
get a human-readable name for a controller handle.  In the normal
course of events, iPXE is likely to disconnect at least some existing
drivers from their controller handles.  This would cause the name
obtained via GetControllerName() to change.  By using the device path
instead, we ensure that the debug message name remains the same even
when the driver controlling the handle is changed.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

src/interface/efi/efi_debug.c

@@ -623,12 +623,6 @@ struct efi_handle_name_type {
 
 /** EFI handle name types */
 static struct efi_handle_name_type efi_handle_name_types[] = {
-	/* Driver name (for driver image handles) */
-	EFI_HANDLE_NAME_TYPE ( &efi_component_name2_protocol_guid,
-			       efi_driver_name2 ),
-	/* Driver name (via obsolete original ComponentName protocol) */
-	EFI_HANDLE_NAME_TYPE ( &efi_component_name_protocol_guid,
-			       efi_driver_name ),
 	/* Driver name (for driver binding handles) */
 	EFI_HANDLE_NAME_TYPE ( &efi_driver_binding_protocol_guid,
 			       efi_binding_name2 ),