The original bootcount methods do not provide an interface to DM and
rely on a static configuration for I2C devices (e.g. bus, chip-addr,
etc. are configured through defines statically).  On a modern system
that exposes multiple devices in a DTS-configurable way, this is less
than optimal and a interface to DM-based devices will be desirable.

This adds a simple driver that is DM-aware and configurable via DTS.
If ambiguous (i.e. multiple bootcount-devices are present) the
/chosen/u-boot,bootcount-device property can be used to select one
bootcount device.

Initially, this provides support for the following DM devices:
 * RTC devices
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

UCLASS_USB_DEV_GENERIC was meant for USB devices connected to host
controllers, not gadget devices.
Adding a new UCLASS for gadget devices alone.

Also move the generic DM code for USB gadgets in a separate file for
clarity.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

This is uclass for Hardware Spinlocks.
It implements two mandatory operations: lock and unlock
and one optional relax operation.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NPatrice Chotard <patrice.chotard@st.com>

The comment in uclass-id.h states that
    "U-Boot uclasses start here - in alphabetical order"
but the subsequent list is not sorted alphabetically.
This reestablishes order.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Sandbox i2c works using emulation drivers which are currently children of
the i2c device:

	rtc_0: rtc@43 {
		reg = <0x43>;
		compatible = "sandbox-rtc";
		emul {
			compatible = "sandbox,i2c-rtc";
		};
	};

In this case the emulation device is attached to i2c bus on address 0x43
and provides the Real-Time-Clock (RTC) functionality.

However this is not ideal, since every device on an I2C bus has a child
device. This is only really the case for sandbox, but we want to avoid
special-case code for sandbox.

A better approach seems to be to add a separate node on the bus, an
'emulation parent'. This can be given a bogus address (such as 0xff) and
hides all the emulators away. Then we can use a phandle to point from the
device to the correct emualtor, and only on sandbox. The code to find an
emulator does not interfere with normal i2c operation.

Add a new UCLASS_I2C_EMUL_PARENT uclass which allows finding an emulator
given a bus, and finding a bus given an emulator. This will be used in a
follow-on patch.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is currently at the top in the space for internal use. But this
uclass is used outside driver model and test code. Move it into the
correct alpha order.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.

The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.

[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdfSigned-off-by: NTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Adds a uclass to interface with a TEE (Trusted Execution Environment).

A TEE driver is a driver that interfaces with a trusted OS running in
some secure environment, for example, TrustZone on ARM cpus, or a
separate secure co-processor etc.

The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.

The over all design is based on the TEE subsystem in the Linux kernel,
tailored for U-Boot.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NIgor Opaniuk <igor.opaniuk@linaro.org>
Signed-off-by: NJens Wiklander <jens.wiklander@linaro.org>

Since there is no canonical "board device" that can be used in board
files, it is difficult to use DM function for board initialization in
these cases.

Hence, add a uclass that implements a simple "board device", which can
hold devices not suitable anywhere else in the device tree, and is also
able to read encoded information, e.g. hard-wired GPIOs on a GPIO
expander, read-only memory ICs, etc. that carry information about the
hardware.

The devices of this uclass expose methods to read generic data types
(integers, strings, booleans) to encode the information provided by the
hardware.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMario Six <mario.six@gdsys.cc>

We might want to access data stored onto one wire EEPROMs.
Create a framework to provide a consistent API.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
[eugen.hristev@microchip.com: reworked patch]
Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>

We might want to use 1-Wire devices connected on boards such as EEPROMs in
U-Boot.

Provide a framework to be able to do that.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
[eugen.hristev@microchip.com: reworked]
Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>

This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.
Signed-off-by: NTien Fong Chee <tien.fong.chee@intel.com>

Some devices offer a text-based OSD (on-screen display) that can be
programmatically controlled (i.e. text displayed on).

Add a uclass to support such devices.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMario Six <mario.six@gdsys.cc>

Add test infrastructure and tests for the AXI uclass.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMario Six <mario.six@gdsys.cc>

Add a uclass for AXI (Advanced eXtensible Interface) busses, and a
driver for the gdsys IHS AXI bus on IHS FPGAs.
Signed-off-by: NMario Six <mario.six@gdsys.cc>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This is a uclass for Shared memory manager drivers.

A Shared Memory Manager driver implements an interface for allocating
and accessing items in the memory area shared among all of the
processors.
Signed-off-by: NRamon Fried <ramon.fried@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: NTom Rini <trini@konsulko.com>

Commit 286ede65 ("drivers: core: Add translation in live tree case") made
dev_get_addr always use proper bus translations for addresses read from
the device tree. But this leads to problems with certain busses, e.g.
I2C busses, which run into an error during translation, and hence stop
working.

It turns out that of_translate_address() and fdt_translate_address()
stop the address translation with an error when they're asked to
translate addresses for busses where #size-cells == 0 (comment from
drivers/core/of_addr.c):

 * Note: We consider that crossing any level with #size-cells == 0 to mean
 * that translation is impossible (that is we are not dealing with a value
 * that can be mapped to a cpu physical address). This is not really specified
 * that way, but this is traditionally the way IBM at least do things

To fix this case, we check in both the live-tree and non-live tree-case,
whether the bus of the device whose address is about to be translated
has size-cell size zero. If this is the case, we just read the address
as a plain integer and return it, and only apply bus translations if the
size-cell size if greater than zero.
Signed-off-by: NMario Six <mario.six@gdsys.cc>
Signed-off-by: NMartin Fuzzey <mfuzzey@parkeon.com>
Reported-by: NMartin Fuzzey <mfuzzey@parkeon.com>
Fixes: 286ede65 ("drivers: core: Add translation in live tree case")
Reviewed-by: NSimon Glass <sjg@chromium.org>

This patch provides
* a uclass for EFI drivers
* a EFI driver for block devices

For each EFI driver the uclass
* creates a handle
* adds the driver binding protocol

The uclass provides the bind, start, and stop entry points for the driver
binding protocol.

In bind() and stop() it checks if the controller implements the protocol
supported by the EFI driver. In the start() function it calls the bind()
function of the EFI driver. In the stop() function it destroys the child
controllers.

The EFI block driver binds to controllers implementing the block io
protocol.

When the bind function of the EFI block driver is called it creates a
new U-Boot block device. It installs child handles for all partitions and
installs the simple file protocol on these.

The read and write functions of the EFI block driver delegate calls to the
controller that it is bound to.

A usage example is as following:

U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and
exposes a handle with the block IO protocol. It calls ConnectController.

Now the EFI block driver installs the partitions with the simple file
protocol.

iPXE uses the simple file protocol to load Grub or the Linux Kernel.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: add comment on calloc len]
Signed-off-by: NAlexander Graf <agraf@suse.de>

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: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

This adds a new uclass id and block interface type for NVMe.
Signed-off-by: NZhikang Zhang <zhikang.zhang@nxp.com>
Signed-off-by: NWenbin Song <wenbin.song@nxp.com>
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Signed-off-by: NJon Nettleton <jon@solid-run.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add some tests which check the behaviour of uclass_first_device() and
uclass_next_device() when probing of a device fails.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The PHY framework provides a set of APIs to control a PHY. This API is
derived from the linux version of the generic PHY framework.
Currently the API supports init(), deinit(), power_on, power_off() and
reset(). The framework provides a way to get a reference to a phy from the
device-tree.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This is a simple uclass for Watchdog Timers. It has four operations:
start, restart, reset, stop. Drivers must implement start, restart and
stop operations, while implementing reset is optional: It's default
implementation expires watchdog timer in one clock tick.
Signed-off-by: NMaxim Sloyko <maxims@google.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

If the system is running PSCI firmware, the System Reset function
(func ID: 0x80000009) is supposed to be handled by PSCI, that is,
the SoC/board specific reset implementation should be moved to PSCI.
U-Boot should call the PSCI service according to the arm-smccc
manner.

The arm-smccc is supported on ARMv7 or later.  Especially, ARMv8
generation SoCs are likely to run ARM Trusted Firmware BL31.  In
this case, U-Boot is a non-secure world boot loader, so it should
not be able to reset the system directly.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This reverts commit 3edc0c25, reversing
changes made to bb135a01.

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: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Series-changes: 2
- Use CONFIG_DM_SCSI instead of mix of DM_SCSI and DM_SATA
  Ceva sata has never used sata commands that's why keep it in
  SCSI part only.
- Separate scsi_scan() for DM_SCSI and do not change cmd/scsi.c
- Extend platdata

Series-changes: 3
- Fix scsi_scan return path
- Fix header location uclass-internal.h
- Add scsi_max_devs under !DM_SCSI
- Add new header device-internal because of device_probe()
- Redesign block device creation algorithm
- Use device_unbind in error path
- Create block device with id and lun numbers (lun was there in v2)
- Cleanup dev_num initialization in block device description
  with fixing parameters in blk_create_devicef
- Create new Kconfig menu for SATA/SCSI drivers
- Extend description for DM_SCSI
- Fix Kconfig dependencies
- Fix kernel doc format in scsi_platdata
- Fix ahci_init_one - vendor variable

Series-changes: 4
- Fix Kconfig entry
- Remove SPL ifdef around SCSI uclass
- Clean ahci_print_info() ifdef logic

Many SoCs allow power to be applied to or removed from portions of the SoC
(power domains). This may be used to save power. This API provides the
means to control such power management hardware.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Some uclass ids are out of order. Per the comments, sort them
in alphabetical order.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

A reset controller is a hardware module that controls reset signals that
affect other hardware modules or chips.

This patch defines a standard API that connects reset clients (i.e. the
drivers for devices affected by reset signals) to drivers for reset
controllers/providers. Initially, DT is the only supported method for
connecting the two.

The DT binding specification (reset.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/reset/reset.txt.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>

A mailbox is a hardware mechanism for transferring small message and/or
notifications between the CPU on which U-Boot runs and some other device
such as an auxilliary CPU running firmware or a hardware module.

This patch defines a standard API that connects mailbox clients to mailbox
providers (drivers). Initially, DT is the only supported method for
connecting the two.

The DT binding specification (mailbox.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This started as 'ahci' and was renamed to 'disk' during code review. But it
seems that this is too generic. Now that we have a 'blk' uclass, we can use
that as the generic piece, and revert to ahci for this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Qualcom processors use proprietary bus to talk with PMIC devices -
SPMI (System Power Management Interface).
On wiring level it is similar to I2C, but on protocol level, it's
multi-master and has simple autodetection capabilities.
This commit adds simple uclass that provides bus read/write interface.
Signed-off-by: NMateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

Add a uclass for block devices. These provide block-oriented data access,
supporting reading, writing and erasing of whole blocks.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NStephen Warren <swarren@nvidia.com>

Implement a DMA uclass so that the devices like ethernet, spi,
mmc etc can offload the data transfers from/to the device and
memory.
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NJagan Teki <jteki@openedev.com>

Add a uclass ID for a disk controller. This can be used by AHCI/SATA or
other controller types. There are no operations and no interface so far,
but it is possible to probe a SATA device.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add a uclass for the northbridge / SDRAM controller found on some older
Intel chipsets.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

It seems likely that at some point we will want a generic interrupt uclass.
But this is a big undertaking as it involves unifying code across multiple
architectures.

As a first step, create a simple IRQ uclass and a driver for x86. This can
be generalised later as required.

Adjust pirq_init() to probe this driver, which has the effect of creating
routing tables and setting up the interrupt routing. This is a start
towards making interrupts fit better with driver model.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>