The virtio spec clearly states in "3.1.1 Driver Requirements: Device
Initialization" the sequence a client has to follow after device reset.
Because u-boot resets here again, it also needs to set the "acknowledge"
bit again even if this was done in virtio_uclass_child_post_bind already
once before.

Signed-off-by: Christian Pötzsch <christian.poetzsch@kernkonzept.com>
Signed-off-by: Adam Lackorzynski <adam@l4re.org>
[trini: Add VIRTIO_CONFIG_S_ACKNOWLEDGE flag check to the test]
Signed-off-by: Tom Rini <trini@konsulko.com>

%s/v1.0 complaint/v1.0 compliant/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

This name is a little confusing since it suggests that it sets up the
sibling block device. In fact it sets up a bootdev for it. Rename the
function to make this clearer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

If a driver cannot be bound, provide the driver name in the debug
message. Now the debug message may look like this:

    (virtio-pci.l#0): virtio-rng driver not configured

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

Sometimes virtio may rely on PCI, or at least that is what the
distro_bootcmd script suggests. Add this in.

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

If we detect the VIRTIO_F_IOMMU_PLATFORM transport feature for a device,
then expose it in the device features.

Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: https://android.googlesource.com/platform/external/u-boot/+/9693bd26bfcfe77d6a1295a561420e08c5daf019
Reviewed-by: Simon Glass <sjg@chromium.org>

At present virtio tries to attach QEMU services to a bootdev device, which
cannot work. Add a check for this.

Also use bootdev_setup_sibling_blk() to create the bootdev device, since
it allows the correct name to be used and bootdev_get_sibling_blk() to
work as expected.

The bootdev is not created on sandbox since it does have a real virtio
device and it is not possible to read blocks.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: a60f7a3e35b ("bootstd: Add a virtio bootdev")
Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>