arm64: dts: ti: Add support for AM6254atl SiP SK

This patch adds the dt for SK-AM62-SIP, which uses the existing
SK-AM62 board design with the new AM6254atl SiP. This changes the
location of memory node from the board dts to SoC level dtsi
(k3-am6254atl in our case).

Therefore this patch introduces the new 'k3-am625-sk-common.dtsi'
which represents the common hardware used for both 'am625-sk' and
'am6254atl-sk' boards with the inheritance hierarchy modified to:

k3-am625-sk.dts:

     k3-am62    k3-am62x-sk-common
        |            |
    k3-am625    k3-am625-sk-common
        |            |
        +-----+------+
              |
         k3-am625-sk

k3-am6254atl-sk.dts:

     k3-am62
        |
     k3-am625       k3-am62x-sk-common
        |                |
    k3-am6254atl    k3-am625-sk-common
        |                |
        +-------+--------+
                |
         k3-am6254atl-sk

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-5-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: 2517e476b819df986fa1fe53927c099032bb72dc ]

(cherry picked from commit 58cd89aff167661dbae0c9911282ea3f1b8212cc)

arm64: dts: ti: Introduce base support for AM6254atl SiP

This patch adds the top level dtsi for AM6254atl SiP which integrates
the existing AM625 SoC with 512MiB of DDR in a single package.

More information about the package can be found here:
https://www.ti.com/lit/ds/symlink/am625sip.pdf

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-4-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: 7c1d13a14e61ab33eec330cb6cabbddb37eecaa9 ]

(cherry picked from commit fa5a6a6e784bde78c6ec74eccd92d51fb9fd49e8)

arm64: dts: ti: k3-am62*: remove SoC dtsi from common dtsi

The k3-am62x-sk-common dtsi represents the common hardware used across
am62x EVMs which can be configured with various DDR sizes or none (with
DDR integrated in the package) based on the specific am62x SoC used.

Therefore this patch moves the memory node and the SoC specific k3-am625
dtsi out of sk-common and into the board dts files. No functional change
is intended from this patch. The device-tree inheritance is changed as
follows:

Before:

               k3-am62
                 ^
               k3-am625
                 ^
         k3-am62x-sk-common
                 ^
  am62x EVMs (k3-am625-sk, k3-am62-lp-sk)

After:

        k3-am62
          ^
        k3-am625    k3-am62x-sk-common
          ^              ^
  am62x EVMs (k3-am625-sk, k3-am62-lp-sk)

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-2-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: e0b9feca7329c495a76891d7766a781dea73787d ]

(cherry picked from commit 0b0edbbdf43bac6b28dd59c88647bd5e0b73ffea)

arm64: dts: ti: k3-am6*-boards: Add label to reserved-memory node

Add the label name 'reserved_memory' to the reserved-memory node in all
K3 AM6* board level dts files. This is done so that the node can be
referenced and extended to add more carveout entries as needed in future
refactoring patches.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-13-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: 4f1aee4723a796a92f17b23699dc861b582ddfd2 ]

(cherry picked from commit 58c447fe500d78f5adc373b4945d8317e11df072)

Merge patch series "boot: Support priority for global bootmeths"

Simon Glass <sjg@chromium.org> says:

At present global bootmeths always run first, before all other
bootmeths. Optimisations in the code take advantage of this, putting
them at the end, so they can be used once and then forgotten.

In some cases it is useful to run global bootmeths later in the boot.
For example, the EFI-bootmgr bootmeth may itself scan devices and the
network, so running it first can hold up the boot significantly for
boards not actually relying on EFI-bootmgr to boot.

This series introduces a new field in global bootmeths which indicates
the priority, using the same scheme as is used with bootdev hunters.
Thus it is possible to insert the EFI-bootmgr bootmeth just before the
hunter for network bootdevs is invoked.

Despite the simplicity of the concept and the relatively small series,
this is a fairly significant enhancement. It is also quite tricky to
implement, largely due to the way the original code was written, with
global bootmeths being a small, size-optimised add-on to the original
bootstd implementation.

For now we only allow each global bootmeth to run at most once, but this
implementation is written in a way that we could relax that if needed.
Then the bootmeth itself could decide whether to run at any particular
point in the bootflow iteration.

Link: https://lore.kernel.org/r/20251015154423.908468-1-sjg@chromium.org

boot: Run the EFI bootmgr just before network devices

At present the EFI bootmgr scans all devices in the system before
deciding which one to boot. Ideally it would use the bootstd iterator
for this, but in the meantime, give it a lower priority, so it runs
just before the network devices.

Note that if there are no hunted network devices hunted, then it will
run at the end, after all bootdevs are exhausted. In other words, it
will always run.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Run global bootmeths after all bootdevs are exhausted

When there are no more bootdevs we should still go through the global
bootmeths, since some may not have yet been used, if their priority has
not yet come up.

Add a final check for this at the end of the iterator.

Update the documentation to match the new behaviour of global bootmeths.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Don't change the method count after global bootmeths

At present before scanning global bootmeths, the iterator sets the
method count to the index of the first global bootmeth. Now that we
support scanning the global bootmeths multiple times, we must leave this
count alone.

Check against have_global and first_glob_method instead.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Implement a priority for global bootmeths

Allow bootmeths to select when they want to run, using the bootdev
priority. Provide a new bootmeth_glob_allowed() function which checks if
a bootmeth is ready to use.

Fix a comment in bootflow_system() which is a test for global bootmeths.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Only run global bootmeths once each

Use the methods_done flags to make sure that each global bootmeth is
only used once. For now this has no effect, since they are all processed
at the start.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Support rescanning the global bootmeths

Add the logic to scan through the global bootmeths for every new
bootdev, in preparation for allowing global bootmeths to select where in
the hunter ordering they go.

Use a new bootmeth_glob_allowed() function to check if a bootmeth is
allowed, ensuring that each can run at most once.

For now this has no actual effect, since the global bootmeths are
unconditionally processed at the start, with iter->methods_done being
updated to include all of them. Therefore when scanning again, no
unprocessed global bootmeths will be found.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Keep track of which bootmeths have been used

Add a bitfield which tracks when bootmeths have been used. This will be
needed when global bootmeths can be used later in the iteration.

Fix a missing bootflow_free() while here.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Add a flag for whether there are global bootmeths

The current 'doing_global' refers to being in the state of processing
global bootmeths. Since global bootmeths are currently used once at the
start, it becomes false once the last global bootmeth has been used.

In preparation for allowing bootmeths to run at other points in the
bootstd interation, add a new 'have_global' flag which tracks whether
there are any global bootmeths in the method_order[] list. It is set up
when iteration starts. Unlike doing_global which resets back to false
after the global bootmeths have been handled, once have_global is set to
true, it remains true for the entire iteration process. This provides a
quick check as to whether global-bootmeth processing is needed.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Update first_glob_method when dropping a bootmeth

For now we only support dropping non-global bootmeths from the
iteration. Update first_glob_method in that case and add a few checks
that things are correct.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Add a new test for global bootmeths

These have different behaviour from normal bootmeths and we are about to
enhance it. So add a test and also an extra check in bootflow_iter()

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Try all bootmeths on the final partition

At present, normally when one bootmeth fails on a partition, we move on
and try the next bootmeth. However, this was not the case for the final
partition due to a bug. Rework the logic so that all partitions are
treated the same.

Signed-off-by: Simon Glass <sjg@chromium.org>

Merge patch series "Add support for dynamic MMU configuration"

Anshul Dalal <anshuld@ti.com> says:

In U-Boot, TI only provides a single memory map for all k3 platforms, this
does not scale for devices where atf and optee lie outside the range 0x80000000
- 0x80080000 and 0x9e780000 - 0xa0000000 respectively.

There are also issues for devices with < 2GiB of memory (eg am62SiP with 512MiB
of RAM) as the maximum size for the first DRAM bank is hardcoded to 2GiB in the
current memory map. Furthermore the second DRAM bank is mapped even for devices
that only have a single bank.

Therefore this patch set adds the required functionality to create the MMU table
at runtime based on the device-tree.

The patch set has been build tested on all effected platforms but boot-tested
only on TI's K3 EVMs, the beagleplay and phytec's phycore-am6* platforms.

The following effected boards have not been boot tested:
 - verdin-am62
 - iot2050

Link: https://lore.kernel.org/r/20251017131540.3636067-1-anshuld@ti.com

arm: mach-k3: reserve space for page table entries

With the memory map configuration being done dynamically, reserve extra
space during U-Boot relocation to ensure we have enough for the fixups.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>

mach-k3: add carveouts for TFA and optee

K3 platforms have reserved memory regions for TFA and OPTEE which should
be unmapped for U-Boot. While other "no-map" memory regions like the
memory pools for remote cores should not be unmapped to allow U-Boot to
load firmware during remoteproc.

Therefore this patch adds the necessary fdt fixups to properly set the
load address for TFA/OPTEE and unmaps both by mmu_unmap_reserved_mem.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

mach-k3: add reserved memory fixups for next boot stage

The boot flow in K3 platforms requires the subsequent boot stages to be
aware of the memory reserved for previous boot binaries. In the regular
boot sequence of:

R5 SPL -> ATF -> OP-TEE -> A-core SPL -> U-Boot -> Kernel,

Both A-core SPL and U-Boot should be made aware of the memory reserved
for ATF and OP-TEE from their device-tree. Currently this information is
absent.

Therefore this patch adds the reserved-memory regions as part of
spl_perform_arch_fixups for the next stage's DT. This is called during
both R5 and A-core SPL which fixes up the DT for their respective next
stages: A-core SPL and U-Boot proper.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

spl: split spl_board_fixups to arch/board specific

The current spl_board_fixups API allows for modification of spl_image
before the SPL jumps to it. This can be used to modify the DT for the
next boot stage, however the current API only allows either the machine
arch or the board to use it.

This limits the utility of the API as there might be certain fixups that
should be applied to all boards sharing the same machine architecture
with others being board specific.

For TI's K3 specifically, this prevents us from performing architecture
level fixups since a lot of TI boards are already making use of the
spl_board_fixups API.

Therefore this patch splits the API into two to allow both board and the
architecture specific fixups. The order is kept as arch then board to
give board specific fixups the precedence.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

arm: armv8: mmu: add mmu_unmap_reserved_mem

For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
the MMU's page tables, done by mmu_setup.

Though this works well for simpler platforms, it makes creating runtime
carveouts by modifying the static array at runtime exceedingly complex
like in mach-snapdragon/board.c.

Creation of such carveouts are much better handled by APIs such as
mmu_change_region_attr once the page tables are configured. Usually such
carveouts are configured via the device-tree's reserved-memory node
which provides the address and size for the carveout.

Therefore this patch adds mmu_unmap_reserved_mem which acts as a wrapper
over mmu_change_region_attr, helping unmap a reserved-memory region.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

mach-k3: map all banks using mem_map_from_dram_banks

The static memory map for K3 (k3_mem_map) only maps the first DRAM bank
and therefore doesn't scale for platforms with multiple memory banks.

This patch modifies enable_caches to add mem_map_from_dram_banks which
appends all the memory banks to k3_mem_map before calling mmu_setup.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

arm: armv8: mmu: add mem_map_from_dram_banks

For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
the MMU as part of mmu_setup.

But since the exact configuration of memory banks might not be known at
build time, many platforms such as imx9, versal2 etc. utilize
gd->bd->bi_dram to configure the static map at runtime.

Therefore this patch adds a new API mem_map_from_dram_banks that
modifies the static map in a similar way. Allowing the caller to map all
dram banks by just passing the index to last entry in their mem_map and
it's length.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

arm: armv8: invalidate dcache entries on dcache_enable

In dcache_enable, currently the dcache entries are only invalidated when
the MMU is not enabled. This causes issues when dcache_enable is called
with the MMU already configured, in such cases the existing dcache
entries are not flushed which might result in un-expected behavior.

This patch invalidates the cache entries on every call of dcache_enable
before enabling dcache (by setting CR_C). This makes dcache_enable
behave similar to icache_enable as well.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

arm: armv8: mmu: export mmu_setup

The mmu_setup function configures the page tables based on the board
supplied mem_map struct array. It is called implicitly as part of
dcache_enable but this limits us to only be able to use APIs such as
mmu_change_region_attr only after caches are enabled.

This might lead to speculative accesses before we can unmap a region
that is marked as cacheable in the static memory map.

Therefore this patch exports the mmu_setup function in mmu.h allowing
users to have more control over when the mmu is configured.

For K3 specifically this allows for the following configuration sequence
as part of enable_caches:

static mem_map fixups (TODO) -> mmu_setup -> carveouts using
mmu_change_region_attr (TODO) -> icache/dcache enable

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

mach-k3: use custom enable_cache

U-Boot's provided enable_caches enforces the following sequence:
icache_enable -> mmu_setup (as part of dcache_enable) -> dcache_enable

Whereas for K3 devices, we would like to add entries to the provided
static array (k3_mem_map) as per gd->bd->bi_dram and then call mmu_setup
to configure the MMU but also create carveouts for TFA/TEE before we
enable caches to prevent speculative accesses to the region. Thus the
following desired sequence:

add dram banks -> mmu_setup -> carveout TFA/TEE -> icache/dcache enable

Therefore this patch adds K3's own implementation of enable_cache for
ARM64, allowing for greater control over the cache enablement sequence.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

mach-k3: use minimal memory map for all K3

The K3 family of SoCs encompasses a wide variety of devices with varying
DDR configurations and memory carveout requirements, the current static
memory map provides basic support for TI EVMs but does not scale well
for newer platforms (such as AM62SiP with 512MiB of RAM).

Therefore this patch replaces the existing memory map with a minimal
one, that could be more easily modified at runtime.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

Merge tag 'net-20251022' of https://source.denx.de/u-boot/custodians/u-boot-net

Pull request net-20251022

net:
- airoha: improvements
- Tighten a few more driver dependencies
- designware: fix bitbang init error
- phy: Make driver overloading get_phy_id depend on !COMPILE_TEST
- phy: add paged PHY register accessors
- make dhcp_run() common for NET and NET_LWIP
- dwc_eth_ops: Correct check for FDT_64BIT
- mediatek: mt7988: various fixup + MDIO detach
- phy: aquantia: switch to use phy_get_ofnode(), fix bindings typo

net-legacy:
- bootp: Prevent buffer overflow to avoid leaking the RAM content
- tftp: make TFTP ports unconditionally configurable

misc:
- uthreads: Make use of CONFIG_IS_ENABLED consistently

Merge tag 'u-boot-at91-2026.01-a' of https://source.denx.de/u-boot/custodians/u-boot-at91

First set of u-boot-at91 features for the 2026.01 cycle:

This small fixes set includes a change on clocks register value and a
fix for the sam9x60ek default timer.

net: designware: fix bitbang init error

The Synchronous Abort and reset errors occurred due
to incorrect parameter passing during initialization.

Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
[jf: add missing #if IS_ENABLED(CONFIG_BITBANGMII)]
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>

net: phy: Make driver overloading get_phy_id depend on !COMPILE_TEST

With commit 597fe041a85f ("net/phy: enable get_phy_id redefinable") we
made get_phy_id a public but weak function, so that PHY drivers that had
required non-standard ways of getting the PHY ID could be supported.
However, overloading a weak function multiple times is (rightly) a link
error. At this point, we have two PHYs which make use of this feature,
so make both of them only available when COMPILE_TEST is unset, as part
of being able to support "allyesconfig" in the future.

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

net: bootp: Prevent buffer overflow to avoid leaking the RAM content

CVE-2024-42040 describes a possible buffer overflow when calling
bootp_process_vendor() in bootp_handler() since the total length
of the packet is passed to bootp_process_vendor() without being
reduced to len-(offsetof(struct bootp_hdr,bp_vend)+4).

The packet length is also checked against its minimum size to avoid
reading data from struct bootp_hdr outside of the packet length.

Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

net: phy: add paged PHY register accessors

Synchronize paged PHY helpers with Linux v6.17.

Add support for PHY devices that use paged register access by
implementing the following functions:
- phy_save_page(): Save current page number
- phy_select_page(): Switch to a specific page and return previous page
- phy_restore_page(): Restore previously saved page

Also adds read_page and write_page callbacks to the phy_driver
structure to enable driver-specific page handling.

These helpers allow safe access to paged PHY registers by ensuring
proper page selection and restoration,
even in error conditions, which will be used by the Airoha PHY driver.

Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>

net: airoha: increase the number of rx network buffers

According to commit 997786bbf473 ("drivers/net/airoha_eth: fix stalling
in package receiving") the minimal possible value of SYS_RX_ETH_BUFFER
is 4. Unfortunately it's too small for reliable ping.

Observations shows that SYS_RX_ETH_BUFFER must be at least 8.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

net: airoha: simplify rx/free packet logic a bit

The commit 997786bbf473 ("drivers/net/airoha_eth: fix stalling in package
receiving") can be improved. Instead of returning previous descriptor
it's possible:
 * do nothing in even descriptor case
 * return 2 descriptor to the queue (current and previous) in the odd
   descriptor case.

This patch:
 * implements above approach
 * remove logic not required within new approach
 * adds note that PKTBUFSRX must be even and larger than 7
   for reliable driver operations

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

net: make dhcp_run() common for NET and NET_LWIP

There are currently two implementations of dhcp_run(): one in cmd/net.c
for NET and one in net/lwip/dhcp.c for NET_LWIP. There is no
justification for that. Therefore, move the NET version into
net/net-common.c to be used by both stacks, and drop the NET_LWIP
version which by the way does not look totally correct.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Acked-by: Benjamin Hahn <B.Hahn@phytec.de>

net: mediatek: move MT7531 MMIO MDIO to dedicated driver

In preparation for support of MDIO on AN7581, move the MT7531 MMIO logic
to a dedicated driver and permit usage of the mdio read/write function
to the mtk_eth driver.

This only affect MT7988 that can use MMIO operation to access the Switch
register. The MT7988 code is updated to make use of the external driver.

This permits Airoha driver to make use of DM_MDIO to bind for the MT7531
driver that have the same exact register.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

net: mediatek: mt7988: free allocated MDIO bus on cleanup

Correctly free the MDIO Bus on calling cleanup function. While at it
also fix a copy-paste error and rename the cleanup function name to the
more specific name.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

net: mediatek: mt7988: restore PHY page on PHY setting exit

On exiting the phy_setting function for MT7988, the PHY page is never
restored to Page 0. This can cause all kind of problem with reading the
status of the PHY at runtime.

Correctly restore PHY page on exiting the PHY setting function.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

net: mediatek: mt7531/7988: fix broken PHY turn ON/OFF

The PHY for MT7531/MT7988 are never actully turned ON/OFF for the
affected PHY as we are read/writing to the wrong PHY address.

This is caused by the fact that we use the MT753X_PHY_ADDR macro 2
times offsetting the address multiple times.

One in the _setup() function and one in the mt7531_mii_read/write.

Drop the additional usage of MT753X_PHY_ADDR in setup() to correctly
set the PHY.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

doc: bindings: fix aquantia-phy.txt typo

Fix typo: "weays" -> "ways"

Signed-off-by: Beiyan Yun <root@infi.wang>

net: phy: aquantia: switch to use phy_get_ofnode()

Use PHY API phy_get_ofnode() helper to get PHY DT node.

Signed-off-by: Beiyan Yun <root@infi.wang>

net: Tighten more driver dependencies

In this case, the mediatek network drivers cannot build outside of
ARCH_MEDIATEK or ARCH_MTMIPS, and so express this requirement in Kconfig
as well. In the case of DWC_ETH_XGMAC / DWC_ETH_XGMAC_SOCFPGA, the file
controlled by the DWC_ETH_XGMAC option references a socfpga-specific
array defined in the file controlled by DWC_ETH_XGMAC_SOCFPGA. Rework
these options in Kconfig to handle this dependency.

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

net: Remove BOOTP_VENDOREX support

It has been over a decade since we had a platform that implemented the
bootp vendor extension support hook. Remove this option due to lack of
use.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

net: Add SYS_FAULT_MII_ADDR to Kconfig

The support found under SYS_FAULT_ECHO_LINK_DOWN requires that the
SYS_FAULT_MII_ADDR symbol also be set. This wasn't previously found in
Kconfig, so add it now.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

arm: socfpga: Tighten a few more driver dependencies

Some drivers which depend on SoCFPGA specific headers had not had
appropriate dependencies list in Kconfig. Add ARCH_SOCFPGA or
TARGET_SOCFPGA_SOC64 where appropriate.

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

uthreads: Make use of CONFIG_IS_ENABLED consistently

We do not yet support UTHREADS in xPL phases. However, we have the need
to dummy out certain functions so that xPL can build when full U-Boot
has UTHREADS enabled. Update the few places that need to use
CONFIG_IS_ENABLED so that we have the correct dummy in xPL.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

tftp: make TFTP ports unconditionally configurable

A few lines of code being guarded by the CONFIG_TFTP_PORT option seems
an unnecessary restriction on the TFTP support provided by a vanilla
U-Boot image. In cases where the TFTP server cannot run as superuser -
and hence cannot run on the well-known port 69 - this quirk incurs a
full reconfiguration and rebuild of the bootloader only in order to
select the appropriate destination port.

Remove the CONFIG_TFTP_PORT option entirely and make the tftpdstp and
tftpsrcp variables always have an effect. Their being unset will mean
that U-Boot behaves the same as if CONFIG_TFTP_PORT was unset. Update
the documentation accordingly. And fix up the single board which was
originally enabling this option.

Signed-off-by: Alvin Šipraga <alvin@pqrs.dk>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

.mailmap: update email address for Chen-Yu Tsai

The email forwarder I'm using has run into severe problems with Gmail
lately. Switch over to my kernel.org address.

Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

env: Invert gd->env_valid for env_mmc_save

The A/B update strategy of the env's has a gap in the first 2 calls of saveenv.
The env's are stored twice on the first memory area if:
gd->env_valid == ENV_INVALID.

u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK  <-- !!!
u-boot=> saveenv
Saving Environment to MMC... Writing to redundant MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK

This is the same issue as resolved in commit e589d5822cac ("env: spi:
Fix gd->env_valid for the first write")

Signed-off-by: Michael Glembotzki <Michael.Glembotzki@iris-sensing.com>
Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
[trini: Amend the commit message]
---
Changes in v2:
- Rebase to current master
- Amend the commit message to reference the SPI version of this fix,
  which had significant follow-up discussion.

spl: Restore args file being default in falcon mode

When falcon mode is enabled and SPL_OS_BOOT_SECURE is not enabled,
restore the previous default behavior of having an args file be
expected. Platforms which are using a FIT image here and do not need
this can update at their convenience to disable this option now.

Fixes: b1a3ed068869 ("spl: make args file optional in falcon mode")
Signed-off-by: Tom Rini <trini@konsulko.com>

Merge patch series "Add support for secure falcon mode: disable args file"

Anshul Dalal <anshuld@ti.com> says:

Continuing from the last series[1], this patch series addresses the requirement
to disable the args file in falcon mode.

The args file is used in falcon mode for loading the device-tree for the kernel.
However in secure falcon mode, the expected payload is a FIT containing a signed
device-tree and kernel image. Thus removing the need to load the extra args
file in the first place. Also, loading the extra file without any authentication
mechanism exposes an attack vector and should therefore be disabled to keep the
boot secure.

This patch set builds on the last few to first optionally allow for loading the
args file in non-secure falcon boot flow [1/3] and then disable them altogether
in the next patch [2/3] for secure falcon mode.

[1]: https://lore.kernel.org/u-boot/20251006101057.4172248-1-anshuld@ti.com/
Link: https://lore.kernel.org/r/20251009115846.897186-1-anshuld@ti.com

spl: set fdt address as spl_image arg in falcon mode

The arg field of `struct spl_image_info` is used by jump_to_image_linux
as the argument for the kernel in falcon mode.

Since commit 601cebc29d2a ("cmd: spl: Remove ATAG support from this
command"), fdt is the only valid argument for kernel in falcon mode.

However fdt was only being set as the argument in nor and xip boot
modes, this patch fixes it for all boot modes and removes the now
redundant code from spl_nor and spl_xip.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: prevent loading args file in secure falcon mode

The expected payload for the SPL in secure falcon mode is a fitImage
that contains the kernel image and the DT. This removes the need to load
an additional args file, which exposes an additional attack vector since
it can not be verified.

Therefore this patch disables loading of the arg file when
SPL_OS_BOOT_SECURE is set.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: make args file optional in falcon mode

Falcon mode loads a kernel file and an args file which is the
device-tree. However in the case of kernel file being a FIT that
contains the device-tree within it, loading the args file is not
required.

Therefore, this patch introduces a new SPL_OS_BOOT_ARGS config options
that allows us to enable or disable loading of the args file in falcon
mode.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

Merge patch series "Add support for secure falcon mode: disable fallback"

Anshul Dalal <anshuld@ti.com> says:

Continuing from the last series[1], this patch series addresses the requirement of
allowing no fallbacks in secure falcon mode.

To do this in a clean way, all the falcon mode logic for each boot media was
refactored to a corresponding *_load_image_os function whereas the regular
boot is implemented in *_load_image, this allows us to easily return early in
case the *_load_image_os function fails with secure mode enabled.

The series also introduces the new SPL_OS_BOOT_SECURE config symbol which
enables secure falcon boot flow.

The generic flow after the patch series looks as follows:

static int spl_<bootmedia>_load_image(...) {
if (CONFIG_IS_ENABLED(OS_BOOT)) {

ret = spl_<bootmedia>_load_image_os(...);

puts("Failcon mode failed\n");
if (CONFIG_IS_ENABLED(OS_BOOT_SECURE)) {
puts("no fallback allowed!\n");
return ret;
}

puts("Falling back to U-Boot\n");
}

/* Regular boot flow */
}

[1]: https://lore.kernel.org/u-boot/20250923124639.667718-1-anshuld@ti.com/
Link: https://lore.kernel.org/r/20251017193318.4124997-1-anshuld@ti.com

spl: falcon: disable fallback to U-Boot on failure

Instead of falling back to the standard U-Boot boot flow, we should just
halt boot if the expected boot flow in falcon mode fails.

This prevents a malicious actor from accessing U-Boot proper if they can
cause a boot failure on falcon mode.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: nand: refactor spl_nand_load_image for falcon mode

This patch moves the falcon mode handling logic out of
spl_ubi_load_image to spl_ubi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: nor: refactor spl_nor_load_image for falcon mode

This patch moves the falcon mode handling logic out of
spl_nor_load_image to spl_nor_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: spi: refactor spl_spi_load_image for falcon mode

This patch moves the falcon mode handling logic out of
spl_spi_load_image to spl_spi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: ubi: refactor spl_ubi_load_image for falcon mode

This patch moves the falcon mode handling logic out of
spl_ubi_load_image to spl_ubi_load_image_os, this allows for cleaner
handling for fallback to U-Boot in case falcon mode fails.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: mmc: split spl_mmc_do_fs_boot into regular/os_boot

Currently the logic to handle falcon mode as well as the regular boot is
inside spl_mmc_do_fs_boot, this prevents us from cleanly extending
falcon mode functionality like toggleable fallback to U-Boot proper.

Therefore this patch splits the logic into spl_mmc_fs_load and
spl_mmc_fs_load_os to handle the regular boot and falcon mode use case.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

spl: Kconfig: add SPL_OS_BOOT_SECURE config symbol

This patch adds the new SPL_OS_BOOT_SECURE symbol that enables secure
boot flow in falcon mode. This symbol can be used to disable certain
inherently insecure options during falcon boot.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>

Revert "spi: cadence-qspi: Remove cdns, is-dma property handling"

This reverts commit a040578d8270ed8788d7663808ea63ce5ffd7840.

Based on feedback other SOCs (for example Star64) are using driver in non
DMA mode which is causing issues that's why revert this patch.
cdns,is-dma should be removed differently.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reported-by: E Shattow <e@freeshell.de>

Merge tag 'efi-2026-01-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2026-01-rc1

CI:

  * https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/27944

Documentation:

 * samsung: Extend E850-96 documentation to be comprehensive
 * environment: fix links to Linux kernel documentation
 * sandbox: fix typos
 * document dmareset command
 * ti: j722s_evm: drop outdated boot note

UEFI:

 * Prevent leak of memory from tmp_files
 * Correctly check if the HTTP protocol is found
 * Use ESRT_FW_TYPE_SYSTEMFIRMWARE instead of ESRT_FW_TYPE_UNKNOWN
 * dbginfodump: use guid definition

Others:

 * lib/uuid: add support for efi debug image info table guid

doc: ti: j722s_evm: drop outdated boot note

The j722s_evm support is now largely complete and is certainly
not limited to UART boot so drop the confusing note from the docs.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

lib: uuid: add efi debug image info table guid

Add the EFI Debug Image Info Table GUID to the translation table used by
uuid_guid_get_str().

This allows to print a human readable table name with `efidebug tables'
instead of "(unknown)".

Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: dbginfodump: use guid definition

Use the Debug Image Info Table GUID definition from efi_api.h instead or
redefining it locally.

Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: environment: fix links to Linux kernel documentation

Architecture-specific documentation in the Linux kernel was moved to
the arch/ subdirectory.

Signed-off-by: Mattia Narducci <mattianarducci1@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: Use ESRT_FW_TYPE_SYSTEMFIRMWARE instead of ESRT_FW_TYPE_UNKNOWN

We currently set the firmware image type to ESRT_FW_TYPE_UNKNOWN.

The spec defines the following:
ESRT_FW_TYPE_UNKNOWN 0x00000000
ESRT_FW_TYPE_SYSTEMFIRMWARE 0x00000001
ESRT_FW_TYPE_DEVICEFIRMWARE 0x00000002
ESRT_FW_TYPE_UEFIDRIVER 0x00000003

Since we don't support updating DEVICEFIRMWARE or UEFIDRIVER types,
let's switch over to SYSTEMFIRMWARE which seems more appropriate.

Suggested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: sandbox: fix typos

Fix two typos in the sandbox docs.

Signed-off-by: Lukas Zirpel <lukas@zirpel.de>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

cmd/dma: documentation

This explains how
to use the new U-Boot command 'dmareset'.

Signed-off-by: Brian Sune <briansune@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

efi_loader: correctly check if the HTTP protocol is found

In function efi_http_service_binding_destroy_child() phandler is created as
as a local variable. If efi_search_protocol() fails, phandler will hold a
random value from the stack. Even it is not zero, we must not use it.

If efi_search_protocol() succeeds, the pointer has already be dereferenced,
so checking against NULL makes not sense here.

If ChildHandle is not a valid UEFI handle, we must return
EFI_INVALID_PARAMETER.

Use a single location for EFI_EXIT().

Addresses-Coverity-ID: CID 531974 (Unchecked return value)
Fixes: 5753dc3f6572 ("efi_loader: Prevent dereference of uninitialised variable")
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: Prevent leak of memory from tmp_files

After the malloc of tmp_files and before its value is recorded an early
exit will need to free tmp_files to prevent leaking that memory.

This issue was found by Smatch.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: samsung: Extend E850-96 documentation to be comprehensive

Add more bootloading details for E850-96 board. New sections cover next
topics:

  - Hardware configuration of the boot device
  - Flashing and updating the software (multiple methods)
  - Booting with Standard Boot (multiple methods)
  - EFI System Partition structure for E850-96
  - Loadable firmware (LDFW) note
  - Ethernet and USB Host Support

That documents all recently enabled U-Boot features for E850-96, which
can hopefully make U-Boot more useful for the users and developers of
this platform.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

fs: semihosting: Use correct variable for error check

After calling a function that can return an error, the test to detect
that error should use the return value not a different variable. Fix it.

This issue was found by Smatch.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
Fixes: f676b45151c3 ("fs: Add semihosting filesystem")

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh

SH HSCIF FIFO fixes, R-Car V4H/V4M DT corrections, R-Car V4H Sparrow
Hawk PCIe shutdown support before booting Linux.

ARM: dts: renesas: Disable RPC driver on R8A779H0 V4M Gray Hawk board

As requirement of CR side, QSPI Flash usage via RPC driver shall
be disabled and leaving the control of this module to CR side.
Perform DT modification to disable the RPC SPI.

Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Reviewed-by: Khanh Le <khanh.le.xr@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Do not modify defconfig, modify the DT instead, this way
        the RPC SPI can be enabled without recompiling the U-Boot
        itself. Update commit message accordingly.]

ARM: dts: renesas: Reinstate R8A779H0 V4M U-Boot DTs

Commit 63da3a795e86 ("ARM: dts: renesas: Drop R8A779H0 V4M DTs with OF_UPSTREAM counterparts")
removed unnecessary V4H DTs from arch/arm/dts , but in the process
also incorrectly dropped the -u-boot.dtsi U-Boot extras. Reinstate
those extras.

Due to DT file name change for the R8A779H0 V4M Gray Hawk, update
the r8a779h0-gray-hawk-u-boot.dtsi filename to newly matching
r8a779h0-gray-hawk-single-u-boot.dtsi .

Align r8a779h0-u-boot.dtsi with clean up commits
1487c34efa7b ("arm64: dts: renesas: Deduplicate extalr_clk bootph-all")
dd8f57ed2f0b ("ARM: dts: renesas: Drop most of bootph-* tags")

Fixes: 63da3a795e86 ("ARM: dts: renesas: Drop R8A779H0 V4M DTs with OF_UPSTREAM counterparts")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

ARM: dts: renesas: Disable R8A779G0 V4H White Hawk RPC SPI DT node again

Commit 3faeb78378ea ("ARM: dts: renesas: Minimize R8A779G0 V4H RPC SPI DT node")
incorrectly re-enabled the RPC SPI DT node, which was disabled in commit
13bdb6a26910 ("ARM: dts: renesas: Disable RPC driver on R8A779G0 V4H White Hawk board")
Reinstate the disablement.

Fixes: 3faeb78378ea ("ARM: dts: renesas: Minimize R8A779G0 V4H RPC SPI DT node")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

serial: sh: Handle HSCIF RX FIFO overflow

The HSCIF RX FIFO may overflow when data are streaming from remote end
into the HSCIF while U-Boot is still starting up. In that case, HSFSR
bit RDF is set, but HSFDR field R is zero. This confuses .tstc callback
into considering RX FIFO to be empty, which leads to .getc to be never
invoked, even when user attempts to pass more input onto the command
line.

Fix this by considering the RDF flag in serial_rx_fifo_level(), which
is called from .tstc in case of no errors. If RDF flag is set, trigger
the .getc callback and let it clear the RX FIFO.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

arm64: renesas: r8a779g3: Reset PCIe before next stage on Retronix R-Car V4H Sparrow Hawk

Fully reset both PCIe controllers before booting the next stage on
Retronix R-Car V4H Sparrow Hawk board. This is necessary especially
in case U-Boot brought up the PCIe controllers, at which point the
next stage might be confused by the state of the PCIe controller.
The reset has to happen this late and not in the PCIe controller
driver, because the SRCR11 bits seem to affect both controllers.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

pci: pcie-rcar-gen4: Shut down controller on link down and remove

In case the link is down, or the controller driver is removed before
booting the next stage, shut down the PCIe link, put both the remote
PCIe device and the controller into reset, and disable clock. This
way, the hardware is not left active when not in use.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

.gitignore: ignore more image files

This expression covers various images files like, for example:

mkimage-out.spl-stm32.mkimage
mkimage.spl-stm32.mkimage

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

Merge patch series "led: fixes"

Patrice Chotard <patrice.chotard@foss.st.com> says:

  - Update led_get_by_label()
  - Fix led Kconfig

Link: https://lore.kernel.org/r/20251009130844.11703-1-patrice.chotard@foss.st.com

led: Add LED dependency for LED_ACTIVITY and LED_BOOT

Add LED dependency for LED_ACTIVITY and LED_BOOT.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>

led: Update led_get_by_label()

During led_init() execution, led_get_label() returns either the label
property (which is an obsolete property [1]) or the LED's node name.
It can't be the function name as dev parameter is NULL.

Later, during led_post_bind() execution, for the same LED, the attributed
label by led_get_label() can be the function name, as led_get_label()
dev's parameter is set.

During call sequence led_boot_on() => led_boot_get() => led_get_by_label()
with label given in parameter (priv->boot_led_label which is either the
label or node's name set previously in led_init()) can be different to
to uc_plat->label and returns -ENODEV.

Update led_get_by_label() to allow to retrieve LED also by its node name.

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.yaml

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>

ARM: dts: sam9x60ek: select PIT as tick-timer

U-Boot currently enables the UPLL during boot, which triggers a udelay()
call that depends on the system tick timer. Since no explicit tick source
is defined in the device tree, boot stalls on this board.

Define the "tick-timer" property under /chosen and point it to the PIT
node, ensuring U-Boot uses the PIT as the tick source.

Fixes: ac30d90f3367 ("clk: Ensure the parent clocks are enabled while reparenting")
Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>

clk: at91: remove default values for PMC_PLL_ACR

Remove default values for PMC PLL Analog Control Register(ACR) as the
values are specific for each SoC and PLL, so load them from PLL
characteristics structure

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>

clk: at91: Add ACR in all PLL setting.

Add ACR in all PLL setting. Add correct ACR value for each PLL used in
different SoCs.

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>

test/py: Update to a newer pytest release

Our pytest package was pinned to a release from 2021. The minimum
compatible with labgrid v25.0.x is pytest 7.0.0. Update to the current
relase which is currently 8.4.2

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

test: uninstall PK after secboot tests

The EFI secure boot tests install a security data base.
Other EFI tests assume that secure boot is not enabled.
Add the missing tear-down at the end of each secboot test sequence.

Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Tom Rini <trini@konsulko.com>

virito: blk: fix logic to determine block sizes

With commit c85b8071e7d3 ("virtio: blk: support block sizes exceeding 512
bytes") logic was added to detect the VIRTIO_BLK_F_BLK_SIZE capability and
to copy the block size reported by QEMU to the block device descriptor.

The logical block size can be set when invoking QEMU:

    -drive if=none,file=4096.img,format=raw,id=vda \
    -device virtio-blk-device,drive=vda,physical_block_size=4096,logical_block_size=4096

In U-Boot the logical block size is shown by command `virtio info`:

    => virtio info
    Device 0: QEMU VirtIO Block Device
                Type: Hard Disk
                Capacity: 1024.0 MB = 1.0 GB (262144 x 4096)

There where two flaws which together hid that the logic was incorrect:

* VIRTIO_BLK_F_BLK_SIZE was missing in the driver capabilities and the bit
  was filtered out.
* The result of the call to virtio_has_feature() was negated.

The problem became apparent when using ARM FVP as emulator which does not set
VIRTIO_BLK_F_BLK_SIZE.

Fixes: c85b8071e7d3 ("virtio: blk: support block sizes exceeding 512 bytes")
Reported-by: Debbie Horsfall <debbie.horsfall@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

ci: rename conf.qemu_arm64_na to conf.qemu_arm64

The test-hooks config file has been renamed by [1], thus update the
name where it is used by the script.

[1] https://lore.kernel.org/u-boot/20251003191918.767698-2-raymond.mao@linaro.org/

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>

env: Kconfig: disable external env in secure os boot

Falcon mode uses falcon_image_file from the env during mmc fs boot, but
external env can be compromised. Therefore disable access to external
env by setting SPL_ENV_IS_NOWHERE when SPL_OS_BOOT_SECURE is set.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Merge patch series "ti_sci: Address some issues found by Smatch"

Andrew Goodbody <andrew.goodbody@linaro.org> says:

Prevent a memory leak from a non-freed malloc.
Return an error code on an error path.
Assign a value to a pointer before it is dereferenced.

Link: https://lore.kernel.org/r/20251008-ti_sci-v3-0-5866bf84adc6@linaro.org

ti_sci: Pointer is never assigned to valid value

The pointer resp is declared but never assigned a value but is then
dereferenced. Fix this by assigning the pointer to the message buffer.

This issue was found by Smatch.

Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>

ti_sci: Provide error code on error exit

In ti_sci_get_response the check for message sequence will return ret
on a fail but ret will be 0 at that point. Instead return -EINVAL.
Also change dev_dbg call to dev_err to be consistent with other error
detection code in the same function.

This issue was found by Smatch.

Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>

ti_sci: Prevent memory leak

temp is assigned the pointer returned by malloc which is used without a
NULL check and then never freed. Add a NULL check and ensure temp is
freed on all return paths.

This issue was found by Smatch.

Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>