Casey Connolly <casey.connolly@linaro.org> says:

This series implements various improvements to Linux header
compatibility, largely in preparation for a full port of Linux CCF but
many of these changes would also be helpful when porting other drivers.

Beside the basic header/compat stuff there are a few larger patches:

Patch 1 adds the "%pOF" format specifier to vsprintf, this behaves the
same as it does in Linux printing the name of the ofnode, but notably it
expects an ofnode pointer rather than a device_node.

Patch 2 adds an option to skip doing a full DM scan pre-relocation.
Some platforms like Qualcomm don't actually need devices to be probed
prior to relocation, it is also quite slow to scan the entire FDT before
caches are up. This option gets us to main loop 30-50% faster.

Unfortunately it isn't possible to totally skip DM since U-Boot will
panic if it can't find a serial port, but the serial uclass code will
bind the serial port itself by reading /chosen/stdout-path, however any
dependencies like clocks won't be found so this should only be enabled
if the serial driver gracefully handles missing clocks.

Patch 3 adds [k]strdup_const(), this works the same as the Linux version
saving a small amount of memory by avoiding duplicating strings stored
in .rodata, this is particularly useful for CCF.

Patch 4 adds 64-bit versions of some 32-bit ofnode utilities functions,
making it possible to parse 64-bit arrays.

Patch 6 provides a simple implementation of kref, this will be used
by CCF.

Patch 9 adds devm_krealloc() support to devres, it relies on storing
allocation sizes in the devres struct which will add a small overhead.

Link: https://lore.kernel.org/r/20260401-casey-ccf-compat-v2-0-414d5b7f040b@linaro.org

These are similar to their Linux counterparts, adding helpers
for reading arrays of 64-bit values with of_access and fdtdec
implementations.

Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

Rework dev_phys_to_bus() and dev_bus_to_phys() to respect the size
of the area specified in dma-ranges DT property. The area outside
of ranges is remapped 1:1, while the area in the ranges is remapped
according to the description in the dma-ranges property.

Adjust the test to test the area within the remapped range, not area
outside the remapped range, which was incorrect.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>

Pointer size cannot be assumed to be 32-bit, so use uintptr_t instead of
uint32_t.

Fixes the below build warning on 64-bit builds:
drivers/serial/atmel_usart.c: In function ‘atmel_serial_probe’:
drivers/serial/atmel_usart.c:275:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  275 |         priv->usart = (atmel_usart3_t *)plat->base_addr;

Signed-off-by: Robert Marko <robert.marko@sartura.hr>

Move the arch specific atmel_serial.h header from AT91 to the generic
include/dm/platform_data.

This will be used for support on Microchip LAN969x.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>

The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c8c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).

This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.

Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Prepare v2026.01-rc3

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>

%s/programmaticaly/programmatically/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Introduce UCLASS-based extension board support to enable more
standardized and automatic loading of extension board device tree
overlays in preparation for integration with bootstd and pxe_utils.

Several #if CONFIG_IS_ENABLED are used in cmd/extension_board.c to ease the
development but don't worry they are removed later in the series.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>