When converting an IPv4 device path node to text, the
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL will produce the following string:

  IPv4(5.6.7.8,TCP,UDP,0x6,DHCP,1.2.3.4,9.10.11.12,255.255.255.0)

This string erroneously contains multiple protocols: TCP, UDP and 0x6.

Add the missing `break' statements in the dp_msging() function to fix this
and obtain the following expected string instead:

  IPv4(5.6.7.8,TCP,DHCP,1.2.3.4,9.10.11.12,255.255.255.0)

Fixes: aaf63429a112 ("efi_loader: add IPv4() to device path to text protocol")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Adriano Cordova <adrianox@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

The log category should be LOGC_EFI all over the EFI sub-system.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Implement Ipv4() node support in the device path to text protocol.

Signed-off-by: Adriano Cordova <adrianox@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

We largely do not need <common.h> in these files, so drop it. The only
exception here is that efi_freestanding.c needs <linux/types.h> and had
been getting that via <common.h>.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Use efi_alloc() to allocate memory.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

* Add the definitions for Ctrl() device path nodes.
* Implement Ctrl() nodes in the device path to text protocol.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

UEFI specification 2.9A requires to display the EUI-64 "in hexadecimal
format with byte 7 first (i.e., on the left) and byte 0 last".

This is in contrast to what the NVMe specification wants.
But it is what EDK II has been implementing.

Here is an example with the patch applied:

    qemu-system-aarch64 -machine virt -cpu cortex-a72 -nographic \
    -bios denx/u-boot.bin \
    -device nvme,id=nvme1,serial=9ff81223 \
    -device nvme-ns,bus=nvme1,drive=nvme1n0,eui64=0x123456789ABCDEF0 \
    -drive file=arm64.img,if=none,format=raw,id=nvme1n0

    => nvme scan
    => efidebug devices
    Device Path
    ====================
    /VenHw(…)/NVMe(0x1,f0-de-bc-9a-78-56-34-12)

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Ensure that the string we convert to UTF-16 is NUL terminated even
if the device path only contains end nodes.

Fixes: bd3d75bb0c58 ("efi_loader: multi part device paths to text")
Addresses-Coverity: 350434 ("Uninitialized scalar variable")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The UEFI specification concerning Uart() device path nodes has been
clarified:

Parity and stop bits can either both use keywords or both use
numbers but numbers and keywords should not be mixed.

Let's go for keywords as this is what EDK II does. For illegal
values fall back to numbers.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The printing of a file path node must properly handle:

* odd length of the device path node
* UTF-16 character only partially contained in device path node
* buffer overflow due to very long file path

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>