This function will be commonly used in block device drivers
in the succeeding patches.

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

Add a block driver which handles read/write for EFI block devices. This
driver actually already exists ('efi_block') but is not really suitable
for use as a real U-Boot driver:

- The operations do not provide a udevice
- The code is designed for running as part of EFI loader, so uses
    EFI_PRINT() and EFI_CALL().
- The bind method probes the device, which is not permitted
- It uses 'EFI' as its parent device

The new driver is more 'normal', just requiring its platform data be set
up in advance.

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

UCLASS_EFI_LOADER is used for devices created by applications and
drivers loaded by U-Boots UEFI implementation.

This patch provides a new uclass (UCLASS_EFI_MEDIA) to be used for devices
that provided by a UEFI firmware calling U-Boot as an EFI application.

If the two uclasses can be unified, is left to future redesign.

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

These names are better used for access to devices provided by an EFI
layer. Use EFI_LOADER instead here, since these are only available in
U-Boot's EFI_LOADER layer.

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

default n/no doesn't need to be specified. It is default option anyway.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>

It is useful to be able to iterate over block devices. Typically there
are fixed and removable devices. For security reasons it is sometimes
useful to ignore removable devices since they are under user control.

Add iterators which support selecting the block-device type.

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

As the deadline for migration to DM_USB, when using a USB host
controller has now gone two years past the deadline, enforce migration.
This is done by:

- Ensuring that all host controller options (other than the very legacy
  old MUSB ones) now select USB_HOST.  USB_HOST now enforces DM_USB and
  OF_CONTROL.
  - Remove other parts of Kconfig logic that had platforms pick DM_USB.
  - To keep Kconfig happy, have some select statements test for USB_HOST
    as well.
- Re-order some Kconfig entries and menus so that we can cleanly pick
  host or gadget roles.  For the various HCD options that have platform
  glue options, group them together and update dependencies in some
  cases.
- As SPL_DM_USB is not required, on platforms that had not yet enabled
  it, disable it.

Cc: Marek Vasut <marex@denx.de>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Samuel Holland <samuel@sholland.org>
Cc: FUKAUMI Naoki <naobsd@gmail.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Define LOG_CATEGORY for all uclass to allow filtering with
log command.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Fixes IDE issues found on the Malta board under Qemu:

1) DMA implied commands were sent to the controller in stead of the PIO
variants. The rest of the code is DMA free and written for PIO operation.

2) direct pointer access was used to read and write the registers instead
of the inb/inw/outb/outw functions/macros. Registers don't have to be
memory mapped and ATA_CURR_BASE() does not have to return an offset from
address zero.

3) Endian isues in ide_ident() and reading/writing data in general. Names
were corrupted and sizes misreported.

Tested malta_defconfig and maltael_defconfig to work again in Qemu.

Signed-off-by: Reinoud Zandijk <reinoud@NetBSD.org>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

At present when a file is bound to a host device it is always marked as
removeable. Arguably the device is removeable, since it can be unbound at
will. However while it is bound, it is not considered removable by the
user. Also it is useful to be able to model both fixed and removeable
devices for code that distinguishes them.

Add a -r flag to the 'host bind' command and plumb it through to provide
this feature.

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