u-boot.git/drivers/Makefile, branch v2019.01-rc2

spl: drivers: Link usb common library to SPL if USB gadget is enabled

2018-12-14T16:59:09Z

Some drivers might need to access common USB functions such as usb_get_maximum_speed() or usb_get_dr_mode(). Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini

spl: fix build failure with !CONFIG_SPL_PCI_SUPPORT

2018-12-12T17:14:23Z

Building U-Boot with CONFIG_PCI and CONFIG_DM_PCI enabled, but CONFIG_SPL_PCI_SUPPORT disabled, results in following linker error: lib/built-in.o: In function `fdtdec_get_pci_bar32': lib/fdtdec.c:305: undefined reference to `dm_pci_read_bar32' fdtdec.c:305:(.text.fdtdec_get_pci_bar32+0x24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dm_pci_read_bar32' This is because reference to dm_pci_read_bar32() remains in lib/fdtdec.c while SPL build does not descend into drivers/pci directory in drivers/Makefile if CONFIG_SPL_PCI_SUPPORT is not enabled. Fix this by applying appropriate #define guards in lib/fdtdec.c. It looks like ns16550.c has the same problem, so fixed that too. To simplify this, CONFIG_SPL_PCI_SUPPORT is renamed to CONFIG_SPL_PCI (enables use of CONFIG_IS_ENABLED() macro). Suggested-by: Vignesh R Signed-off-by: Sekhar Nori Reviewed-by: Lokesh Vutla Reviewed-by: Tom Rini

blk: Rework guard around part_init call

2018-12-12T17:14:22Z

The function part_init() will only be built when we have both CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to this function with both of these tests now. Cc: Simon Glass Cc: Philipp Tomsich Cc: Michal Simek Cc: York Sun Cc: Prabhakar Kushwaha Cc: Mingkai Hu Cc: Stefan Roese Cc: Marek Behún Cc: Vanessa Maegima Cc: Eugen Hristev Cc: Adam Ford Cc: Jagan Teki Cc: Tom Warren Cc: Stephen Warren Cc: Vitaly Andrianov Signed-off-by: Tom Rini Reviewed-by: Simon Glass

dm: Add Hardware Spinlock class

2018-12-07T04:26:32Z

This is uclass for Hardware Spinlocks. It implements two mandatory operations: lock and unlock and one optional relax operation. Signed-off-by: Benjamin Gaignard Reviewed-by: Simon Glass Reviewed-by: Patrice Chotard

spl: Support hash, input, pch, pci, rtc, tpm in SPL

2018-11-26T13:25:33Z

At present these subsystems are only supported in U-Boot proper but it is sometimes necessary to support them in SPL, or even TPL. Update the Kconfig and Makefile to support this. Also adjust GPIO so that it can be used in TPL if required. Reviewed-by: Tom Rini Signed-off-by: Simon Glass

dm: Add a new uclass driver for VirtIO transport devices

2018-11-14T17:16:27Z

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.pdf Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng Reviewed-by: Simon Glass

Add UCLASS_TEE for Trusted Execution Environment

2018-10-07T14:47:38Z

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: Simon Glass Tested-by: Igor Opaniuk Signed-off-by: Jens Wiklander

Merge branch 'master' of git://git.denx.de/u-boot-spi

2018-10-02T21:01:46Z

This is the PR for SPI-NAND changes along with few spi changes. [trini: Re-sync changes for ls1012afrwy_qspi*_defconfig] Signed-off-by: Tom Rini

Merge git://git.denx.de/u-boot-dm

2018-09-30T22:16:51Z

drivers: Add board uclass

2018-09-29T17:49:35Z

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: Simon Glass Signed-off-by: Mario Six