The description claims that the device is probed but it isn't.

Add the device_probe() call.

Also consolidate the iteration into one function.

Fixes: 8a5cbc065d ("dm: blk: Use uclass_find_first/next_device() in blk_first/next_device()")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>

Update the sandbox implementation to use UCLASS_HOST and adjust all
the pieces to continue to work:

- Update the 'host' command to use the new API
- Replace various uses of UCLASS_ROOT with UCLASS_HOST
- Disable test_eficonfig since it doesn't work (this should have a unit
  test to allow this to be debugged)
- Update the blk test to use the new API
- Drop the old header file

Unfortunately it does not seem to be possible to split this change up
further.

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

Create a block driver for the new HOST uclass. This handles attaching and
detaching host files.

For now the uclass is not used but this will be plumbed in with future
patches.

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

Sandbox supports block devices which can access files on the host machine.
At present there is no uclass for this. The devices are attached to the
root devic. The block-device type is therefore set to UCLASS_ROOT which
is confusing.

Block devices should be attached to a 'media' device instead, something
which handles access to the actual media and provides the block driver
for the block device.

Create a new uclass to handle this. It supports two operations, to attach
and detach a file on the host machine.

For now this is not fully plumbed in.

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

This function now finds its block-device child by looking for a child
device of the correct uclass (UCLASS_BLK). It cannot produce a device of
any other type, so drop the superfluous check.

Provide a version which does not probe the device, since that is often
needed when setting up the device's platdata.

Also fix up the function's comment.

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

Some tests access data in block devices and so cause the cache to fill
up. This results in memory being allocated.

Some tests check the malloc usage at the beginning and then again at the
end, to ensure there is no memory leak caused by the test. The block cache
makes this difficult, since the any test may cause entries to be allocated
or even freed, if the cache becomes full.

It is simpler to clear the block cache after each test. This ensures that
it will not introduce noise in tests which check malloc usage.

Add the logic to clear the cache, using the existing blkcache_invalidate()
function. Drop the duplicate code at the same time.

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

This is not used anymore. Drop it.

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

Use the correct SPL_TPL_ variable so that these features can be enabled in
TPL and VPL as needed.

Disable it by default in TPL to avoid any code-size increase. No boards
are actually using it since the Makefile rules don't allow including
drivers/block/ with TPL_DM enabled. It can be manually enabled as needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

At present we have functions called blk_dread(), etc., which take a
struct blk_desc * to refer to the block device. Add some functions which
use udevice instead, since this is more in keeping with how driver model
is supposed to work.

Update one of the tests to use this.

Note that it would be nice to update the functions in disk-uclass.c to use
these new functions. However they are not quite the same. For example,
disk_blk_read() adds the partition offset to 'start' when calling the
cache read/fill functions, but does not with part_blk_read(), which does
the addition itself. So as designed the code is duplicated.

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

blk_first_device_err/blk_next_device_err uses
uclass_first_device_err/uclass_next_device_err for device iteration.

Although the function names superficially match the return value from
uclass_first_device_err/uclass_next_device_err is never used
meaningfully, and uclass_first_device/uclass_next_device works equally
well for this purpose.

In the following patch the semantic of
uclass_first_device_err/uclass_next_device_err will be changed to be
based on uclass_first_device_check/uclass_next_device_check breaking
this sole user that uses uclass_next_device_err for iteration.

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>