Let's introduce the Generic System Interconnect subsystem based on
the counterpart Linux framework which is used to vote for bandwidth
across multiple SoC busses.

Documentation for the Linux Generic System Interconnect Subsystem can
be found at [1].

Each bus endpoints are materialised as "nodes" which are linked together,
and the DT will specify a pair of nodes to enable and set a bandwidth
on the route between those endpoints.

The hardware resources that provide those nodes and provides the way
to vote for the bandwidth are called "providers".

The Interconnect uclass code is heavily based on the Linux one, with
some small differences:
- nodes are allocated as udevices instead of Linux idr_alloc()
- tag management is minimal, only normal xlate is supported
- getting nodes states at probe is not implemented
- providers are probed on demand while the nodes links are traversed
- nodes are populated on bind
- id management is simplified, static IDs and dynamics IDs can be used
- identical consume API as Linux, only implementation differs

Fully tested with associated DM test suite.

[1] https://docs.kernel.org/driver-api/interconnect.html

Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-1-e8a82720da5d@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

We have a large number of library symbols that should not be prompted
for by the user really but rather selected by the platform (or SoC) as
needed. To start with however, make these depend on !COMPILE_TEST.

Signed-off-by: Tom Rini <trini@konsulko.com>

Add new i3c driver to U-Boot drivers.

Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>

At the moment, we don't have a common API for working with
SM, only the smc_call() function. This approach is not generic
and difficult to configure and maintain.

This patch adds UCLASS_SM with the generic API:

- sm_call()
- sm_call_write()
- sm_call_read()

These functions operate with struct pt_regs, which describes
Secure Monitor arguments.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20230921081346.22157-2-avromanov@salutedevices.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

The Kconfig for this is currently inside a particular board. Move it into
the correct place and allow use in SPL, so that video can be used there
if needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Add a new simple uclass for extcon. Currently all setup is done
in the probe. Uclass struct and ops are empty for now.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add helper functions for atmel Static Memory Controller. The functions
are required to configure SMC. This file is inherited from the work
done by Boris Brezillon for Linux

Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>

The FWU Multi Bank Update feature supports updating firmware images
to one of multiple sets(also called banks) of images. The firmware
images are clubbed together in banks, with the system booting images
from the active bank. Information on the images such as which bank
they belong to is stored as part of the metadata structure, which is
stored on the same storage media as the firmware images on a dedicated
partition.

At the time of update, the metadata is read to identify the bank to
which the images need to be flashed(update bank). On a successful
update, the metadata is modified to set the updated bank as active
bank to subsequently boot from.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

This new class of device will provide fuzzing inputs from a fuzzing
engine.

Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This uclass is intended to manage IOMMUs on systems where the
IOMMUs are not in bypass mode by default.  In that case U-Boot
cannot ignore the IOMMUs if it wants to use devices that need
to do DMA and sit behind such an IOMMU.

This initial IOMMU uclass implementation does not implement and
device ops and is intended for IOMMUs that have a bypass mode
that does not require address translation.  Support for IOMMUs
that do require address translation is planned and device ops
will be defined when support for such IOMMUs will be added.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>