APPEND_WRITE with data length zero is allowable according to the UEFI
specification.

The EDK2 interpretation of no access attributes is attributes = 0. As
the UEFI specification is vague in this respect let's stick to EDK2 here.

Fixes: commit 6d2f27c5fd60 ("efi_loader: variable: support APPEND_WRITE")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

We always have to return via EFI_EXIT() from EFIAPI functions.

Coverity reported an unreachable line and a resource leak.

Fixes: commit 6d2f27c5fd60 ("efi_loader: variable: support APPEND_WRITE")
Reported-by: Coverity Scan CID 253575, CID 184095
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Remove outdated TODO for efi_stri_coll(). efi_stri_coll() is already using
the Unicode capitalization table.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

If EFI_VARIABLE_APPEND_WRITE is specified in attributes at
efi_set_variable(), specified data will be appended to the variable's
original value. Attributes other than APPEND_WRITE should not be
modified.

With this patch, APPEND_WRITE test in 'variables' selftest will pass.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

DisconnectController() should never return EFI_NOT_FOUND.
If EFI_DRIVER_BINDING_PROTOCOL.Stop() fails, return EFI_DEVICE_ERROR.

If the driver handle does not expose the EFI_DRIVER_BINDING_PROTOCOL
return EFI_INVALID_PARAMETER.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Sandbox's "host" devices are currently described as UCLASS_ROOT udevice
with DEV_IF_HOST block device. As the current implementation of
efi_device_path doesn't support such a type, any "host" device
on sandbox cannot be seen as a distinct object.

For example,
  => host bind 0 /foo/disk.img

  => efi devices
  Scanning disk host0...
  Found 1 disks
  Device           Device Path
  ================ ====================
  0000000015c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
  0000000015c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)

  => efi dh
  Handle           Protocols
  ================ ====================
  0000000015c19970 Device Path, Device Path To Text, Device Path Utilities, Unicode Collation 2, HII String, HII Database, HII Config Routing
  0000000015c19ba0 Driver Binding
  0000000015c19c10 Simple Text Output
  0000000015c19c80 Simple Text Input, Simple Text Input Ex
  0000000015c19d70 Block IO, Device Path, Simple File System

As you can see here, efi_root (0x0000000015c19970) and host0 device
(0x0000000015c19d70) have the same representation of device path.

This is not only inconvenient, but also confusing since two different
efi objects are associated with the same device path and
efi_dp_find_obj() will possibly return a wrong result.

Solution:
Each "host" device should be given an additional device path node
of "vendor device path" to make it distinguishable.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

We do not support volume label changes. No parameter checks are needed
here.

When the info for as file is changed the buffer must always contain a file
name.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Check the parameters of EFI_FILE_PROTOCOL.GetInfo() to avoid possible NULL
dereference.

Check the buffer size for EFI_FILE_SYSTEM_INFO.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

We cannot determine the volume name in U-Boot. Instead of providing a dummy
volume name in case of EFI_FILE_SYSTEM_INFO and EFI_UNSUPPORTED in case of
EFI_FILE_SYSTEM_VOLUME_LABEL consistently return an empty string.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

The UEFI specification requires to implement version 2 of the
EFI_FILE_PROTOCOL. Provide the missing functions as stubs.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>