No user of the legacy LED API anymore (except Sunxi with the PinePhone
but that is now a Sunxi-specific implementation), so let's remove
anything related.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.

Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.

To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.

Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().

Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmware if necessary.

Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-3-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>

This driver provides an interface to access the functions of the system
controller on the Microchip PolarFire SoC.
This driver includes functions to use the system controller to read
the device serial number.

Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Neha Malcom Francis <n-francis@ti.com> says:

This series implements a driver for the BIST (Built-In Self Test) module
for K3 devices. The BIST driver must ideally support triggering of BIST
tests, both PBIST (Memory BIST) and LBIST (Logic BIST) on a core. Both
tests are destructive in nature. Please see links [1] and [2] for
further information regarding the two.

At boot up, BIST is executed by hardware for the MCU domain
automatically as part of HW POST. So BIST has been checked only for the
MCU domain when U-Boot comes up in the usual U-Boot to Linux boot flow.
To facilitate the use-case where some safe firmware is intended to be
run on a safe core, it is best to have triggered the BIST tests on that
core. As an example, we take triggering the BIST tests on the MAIN R52_x
cores. The triggering patch is kept as DONOTMERGE.

The general procedure for triggering BIST on a core is:
	1. Power on the core under test following a sequence
	2. Trigger the BIST test
	3. Reset the core under test following a sequence

BIST tests are triggered from A72 SPL where the DM (Device Manager
firmware that handles power management) is already up and can perform
these power sequences for us.

Boot logs (with LOG_DEBUG and CONFIG_K3_BIST enabled) and DT node kept (already
merged to ti-k3-dts-next [3]):
https://gist.github.com/nehamalcom/3fed504d038b54e3e05ba3874d73d603

[1] https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/sdl/sdl_docs/userguide/j721e/modules/pbist.html#introduction
[2] https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/sdl/sdl_docs/userguide/j721e/modules/lbist.html#introduction
[3] https://lore.kernel.org/all/175205725858.918402.3771835070085533874.b4-ty@ti.com/

Link: https://lore.kernel.org/r/20250716062156.2564297-1-n-francis@ti.com

Add a driver for the BIST module that support triggering of both PBIST
(Memory BIST) and LBIST (Logic BIST) tests. Also expose the relevant
operations and functions that would be required for an end user to
trigger the tests.

Signed-off-by: Neha Malcom Francis <n-francis@ti.com>

As no platforms use this driver anymore and it's not been converted from
to DM_I2C for use, remove it.

Fixes: ed7fe2bee12a ("ppc: Remove xpedite boards")
Signed-off-by: Tom Rini <trini@konsulko.com>

This driver has not been converted to DM_I2C and the last platform that
used it was removed as well. Remove the driver.

Fixes: 4bbcec08ebec ("arm: Remove mx6dlarm2 board")
Signed-off-by: Tom Rini <trini@konsulko.com>

Tom Rini <trini@konsulko.com> says:

This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.

Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

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

Add K3_FUSE config option to add and enable fuse sub-system
implementation function calls.

Signed-off-by: Harsha Vardhan V M <h-vm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>