Fixes possible resource leak in dm_test_tee() reported by Coverity.

Reported-by: Coverity (CID: 184175)
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

Compiling the overlay unit test fails with odroid-c2_defconfig showing
errors like:

    test/overlay/cmd_ut_overlay.c:29:8:
    error: unknown type name ‘fdt32_t’

Add the missing include.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add test which checks if a PCI device described in DT with an
entry and reg = <...> property, but without compatible string
results in a valid U-Boot PCI udevice with the udevice.node
populated with reference to this DT node. Also check if the
other PCI device without a DT node does not contain any bogus
udevice.node.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Peter originally sent a fix, but it breaks a number of other things.
This addresses the original reported issue in a different way.

That report was:

> U-Boot has 1 common buffer to send Ethernet frames, pointed to by
> net_tx_packet.  When sending to an IP address without knowing the MAC
> address, U-Boot makes an ARP request (using the arp_tx_packet buffer)
> to find out the MAC address of the IP addressr. When a matching ARP
> reply is received, U-Boot continues sending the frame stored in the
> net_tx_packet buffer.
>
> However, in the mean time, if U-Boot needs to send out any network
> packets (e.g. replying ping packets or ARP requests for its own IP
> address etc.), it will use the net_tx_packet buffer to prepare the
> new packet. Thus this buffer is no longer the original packet meant
> to be transmitted after the ARP reply. The original packet will be
> lost.

This instead uses the ARP tx buffer to send async replies in the case
where we are actively waiting for an ARP reply.

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>

Reported-by: Tran Tien Dat <peter.trantiendat@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

The target will respond to pings while doing other network handling.
Make sure that the response happens and is correct.

This currently corrupts the ongoing operation of the device if it
happens to be awaiting an ARP reply of its own to whatever serverip it
is attempting to communicate with. In the test, add an expectation that
the user operation (ping, in this case) will fail. A later patch will
address this problem.

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

This tests that ARP requests made to this target's IP address are
responded-to by the target when it is doing other networking operations.

This currently corrupts the ongoing operation of the device if it
happens to be awaiting an ARP reply of its own to whatever serverip it
is attempting to communicate with. In the test, add an expectation that
the user operation (ping, in this case) will fail. A later patch will
address this problem.

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

We have a method to return the last reset as a string for humans, but not
a method that allows it to be used programmatically. Add a new method that
returns the last reset as an enum.

Signed-off-by: Simon Glass <sjg@chromium.org>

Some comments are incorrect or missing pieces. Fix these and use logging
to print the error.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present the panel can be turned on but not off, and the brightness
cannot be controlled at run-time. Add a new API function to both the panel
and backlight uclasses to handle this. Enhance the PWM backlight driver
to deal with custom levels properly and allow the backlight to be turned
on and off.

Update the test to cover thes new features.

Signed-off-by: Simon Glass <sjg@chromium.org>