This converts the IDE driver to driver model so that block read and
write are fully functional.

Fixes: b7c6baef ("x86: Convert MMC to driver model")
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

This returns 'ret' but the value is always zero. Update it to simply
return 0, for clarity.

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

Add a function to find the name of an interface type (e.g. "sata", "scsi")
from the interface type enum.

This is useful for generic code (not specific to SATA or SCSI, for
example) that wants to display the type of interface it is dealing with.

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

This adds a new uclass id and block interface type for NVMe.

Signed-off-by: Zhikang Zhang <zhikang.zhang@nxp.com>
Signed-off-by: Wenbin Song <wenbin.song@nxp.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Jon Nettleton <jon@solid-run.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Many devices support a child block device (e.g. MMC, USB). Add a
convenient way to get this device given the parent device.

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

The intention with block devices is that the device number (devnum field
in its descriptor) matches the alias of its parent device. For example,
with:

	aliases {
		mmc0 = "/sdhci@700b0600";
		mmc1 = "/sdhci@700b0400";
	}

we expect that the block devices for mmc0 and mmc1 would have device
numbers of 0 and 1 respectively.

Unfortunately this does not currently always happen. If there is another
MMC device earlier in the driver model data structures its block device
will be created first. It will therefore get device number 0 and mmc0
will therefore miss out. In this case the MMC device will have sequence
number 0 but its block device will not.

To avoid this, allow a device to request a device number and bump any
existing device number that is using it. This all happens during the
binding phase so it is safe to change these numbers around. This allows
device numbers to match the aliases in all circumstances.

Add a test to verify the behaviour.

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

At present this code is inline. Move it into a function to allow it to
be used elsewhere.

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

Sometimes it is useful to be able to find a block device without also
probing it. Add a function for this as well as the associated test.

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

This patch adds the flags parameter to device_remove() and changes all
calls to this function to provide the default value of DM_REMOVE_NORMAL
for "normal" device removal.

This is in preparation for the driver specific pre-OS (e.g. DMA
cancelling) remove support.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.

intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().

scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.

scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.

SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>