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>

At present this uclass has no tests. Add a simple one which checks the PWM
configuration, regulator and GPIO.

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

At present ofnode_read_fmap_entry() reads a flash map entry in a format
which is not supported by binman. To allow use to use binman-format
descriptions, update this function.

Also add a simple test.

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

Some devices have children and want to press an existing inactive child
into service when needed. Add a function to help with this.

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