Tom Rini [Fri, 10 Jul 2026 21:55:23 +0000 (15:55 -0600)]
Merge patch series "fs: btrfs: add support for readdir"
Alexey Charkov <alchark@flipper.net> says:
Btrfs in U-boot currently uses a custom callback for ls and doesn't
expose the standard opendir/readdir/closedir interface, making it harder
to use in generic code. One area where this would be useful is in
discovering BLS type 1 entries [1] on a Btrfs filesystem.
Add support for the standard interface, and implement ls in terms of it.
Alexey Charkov [Fri, 26 Jun 2026 15:18:22 +0000 (19:18 +0400)]
fs: btrfs: use fs_ls_generic() and drop custom implementation
Now that generic callbacks for opendir/readdir/closedir are implemented,
the custom btrfs_ls() implementation is no longer needed, along with the
btrfs_iter_dir() callback iterator.
cmd: x86: zboot: remove duplicate zboot_setup() call in do_zboot_setup
do_zboot_setup() invokes zboot_setup() twice: once with proper error
reporting, and again immediately afterwards with no diagnostic. The
second call re-runs the entire boot parameter setup on the
already-populated zero page, which is at best wasted work and at
worst leaves the structure in an unexpected state.
Drop the stray second invocation; the first call already covers both
success and failure handling.
cmd: upl: fix off-by-one argc check in do_upl_read
do_upl_read() guards against missing arguments with "argc < 1", but
argc always counts argv[0] (the command name) so that condition is
never true. The function then unconditionally dereferences argv[1],
which is out of bounds when the user runs "upl read" with no address
argument and feeds garbage into hextoul()/map_sysmem().
Use "argc < 2" so the address argument is actually required.
cmd: ini: avoid NULL deref when loadaddr/filesize env vars are unset
When the user runs "ini <section>" without explicit address or size
arguments, do_ini() falls back to env_get("loadaddr") and
env_get("filesize") and passes the results straight to hextoul().
env_get() returns NULL for an undefined variable and hextoul() does
not tolerate a NULL pointer, so on a board without these variables
set the command dereferences NULL.
Fetch the strings into locals first, reject the NULL case with
CMD_RET_USAGE, and only then convert to numeric values.
Fixes: c167cc02033 ("Add a new "ini" command") Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
cmd: host: fix duplicate device_unbind and wrong error message in unbind
do_host_unbind()'s error handler for device_unbind() prints the
misleading message "Cannot attach file" and then calls device_unbind()
a second time on the same device, both of which look like copy-paste
mistakes left over from neighbouring code.
Remove the duplicate device_unbind() call and report the correct
failure with the device name.
Fixes: 952018117ab ("dm: sandbox: Switch over to using the new host uclass") Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
cmd: clone: report destination block number on dest write error
The error path of the destination blk_dwrite() prints srcblk, which
refers to the source device's block counter and is unrelated to the
write that just failed. This produces misleading diagnostics that
point at the wrong block on the wrong device when a clone aborts on
a write error.
Print destblk so the message identifies the block that actually
failed, mirroring the existing "Src read error @blk %ld" message
above which correctly uses srcblk.
remoteproc: k3-r5: Fix crash when issuing rproc init
Prevent NULL pointer dereference with lockstep mode.
Since commit 21d03d60e909 ("j7200 defconfig: add rproc commands"),
issuing rproc init command with cluster configured in lockstep results
in a NULL pointer dereference.
This is because ti_sci_proc_request() is called on both cores on the
same cluster, without checking if they are populated.
To fix that, only request the core being probed, as there is no need to
request the other one.
Moreover, the old code was requesting both cores in lockstep mode, but
only releasing one:
it called k3_r5f_proc_request() with ti_sci_proc_release(), instead of
using k3_r5f_proc_request()/k3_r5f_proc_release() or
ti_sci_proc_request()/ti_sci_proc_release().
So, replacing k3_r5f_proc_request() by ti_sci_proc_request() restores
the intended behavior.
- Add new rockchip custodian,
- Remove inactive rockchip custodian,
- Preemptively fix rk3528/rk356x DTS issue that will come with 7.1
upstream DTS sync,
- Fix typo in doc,
- Fix variable used before being set in rockchip_nfc,
- Fix asm-operand-widths clang warning for RK3528, RK3576 and RK3588,
- Work around HW undefined state for NVMEs on RK3588 Jaguar,
- Added support for new devices:
- LinkEase EasePi R1
- 9Tripod X3568 v4
The 9Tripod X3568 v4 is an RK3568-based SBC, just like the RK3568-EVB.
It always uses soldered connections between the X3568CV2/X3568CV3/X3568CV4 core board
and the X3568bv4 I/O board.
The differences between the core boards
- PCB size, layout
- CPU (RK3568B2/RK3568J)
- Memory type (DDR4/LPDDR4/LPDDR4X) and size
- eMMC size
- DSI/EDP resistor values
Although the components vary, they maintain full compatibility.
The X3568 board has multiple hardware revisions, and we currently support v4 (I/O board).
Specification:
- SoC: RockChip RK3568 ARM64 (4 cores)
- eMMC: 16-128 GB
- RAM: 2-16 GB
- Power: DC 12V 2A
- Ethernet: 2x YT8521SC RGMII (10/100/1000 Mbps)
- Wireless radio: 802.11b/g/n/ac/ax dual-band
- LED:
Power: AlwaysOn
User: GPIO
- Button:
VOL+: SARADC/0 <35k µV>
VOL-: SARADC/0 <450k µV>
Power/Reset: PMIC RK809
- CAN
CAN/1: 4-pin (PH 2.0)
- PWM
PWM/4: Backlight DSI/0 DSI/1
PWM/7: IR Receiver [may not install]
- UART:
UART/2: Debug TTL - 1500000 8N1 (1.25mm)
UART/3: TTL (PH 2.0)
UART/4: TTL (PH 2.0)
UART/8: AP6275S Bluetooth
UART/9: TTL (PH 2.0)
- I2C:
I2C/0: PMIC RK809
I2C/1: Touchscreen DSI/0 DSI/1
I2C/4: Camera
I2C/5: RTC@51 PCF8563
- I2S:
I2S/0: miniHDMI Sound
I2S/1: RK809 Audio Codec
I2S/3: AP6275S Bluetooth Sound
- SDMMC:
SDMMC/0: microSD (TF) slot
SDMMC/2: AP6275S SDIO WiFi card
- Camera: 1x CSI
- Video: miniHDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP)
- Audio: miniHDMI / MIC on-board / Speaker / SPDIF / 3.5mm Headphones / AP6275S Bluetooth
- USB:
USB 2.0 HOST x2
USB 2.0 HOST x3 (4-pin)
USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST) [slot may not install]
USB 3.0 HOST x1
USB 3.0 OTG/HOST x1
- SATA: 1x SATA 3.0 with Power/4-pin [slot may not install]
- PCIe: 1x PCIe 3.0 x2 (x4 connector) [power/clock/slot may not install]
board: rockchip: set M.2 NVMe PERSTN low in spl_board_init on Jaguar
As it is, an NVMe's built-in PERSTN pull-up fights against the
SoC's built-in pull-down which results in an undefined logic state
on the Samsung SSD 980 and likely others.
Fix that by forcing PERSTN low as early as possible, which is SPL.
Both Linux and U-Boot (via "pci enum") set the pin high later
as needed and the NVMe is detected fine.
Oscillocope shots ("x" means undefined logic state at around 1.5V):
Before:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____xxxxxxxxxxxxxxx_|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
After:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____x_______________|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
With this change, the power-up sequence conforms to PCIe specs,
except a remaining short PERSTN glitch. The glitch is about 400ms
long. It could be shortened by moving the logic to TPL, but
completely fixing it is only possible in hardware.
The oobfree[0].length calculation depends on the
rknand->metadata_size value, but this is calculated
after the function rk_nfc_ecc_init is called. Move this
calculation to a location before it's value is required.
Jonas Karlman [Tue, 7 Jul 2026 10:09:17 +0000 (10:09 +0000)]
arm: dts: rockchip: Align OTP nodes for RK3528/RK356x with Linux v7.1
The <soc>-u-boot.dtsi OTP nodes for RK3528/RK356x use different names
compared to the OTP nodes that was merged in Linux v7.1. This causes
build issues when dts/upstream pulls in updated DTs, i.e.:
ERROR (duplicate_label): /soc/nvmem@ffce0000: Duplicate label 'otp'
on /soc/nvmem@ffce0000 and /soc/efuse@ffce0000
ERROR (duplicate_label): /nvmem@fe38c000: Duplicate label 'otp'
on /nvmem@fe38c000 and /efuse@fe38c000
Align the OTP node names in <soc>-u-boot.dtsi with the node names used
in upstream Linux v7.1 to avoid build issues when latest DTs are synced.
Also drop the unused RK356x id@a subnode as it has moved under a
nvmem-layout node in the merged upstream DT.
MAINTAINERS: add myself as ARM ROCKCHIP maintainer
Kever has been pulled into different responsibilities at Rockchip and
this means he has less to no time for his maintainership in U-Boot as
has been seen for about a year now. Let's try to improve the situation
and have Rockchip-related things merged again by adding myself as
another maintainer.
MAINTAINERS: add more Rockchip drivers to ARM ROCKCHIP
A few drivers are not using "rockchip" in their path so they aren't
currently detected by get_maintainer.pl as belonging to the ARM ROCKCHIP
entry, so let's fix that oversight by adding them individually. We could
use N: rk_ but I feel this isn't distinctive enough to avoid too many
false positive and I don't want to be keeping a list of things to not
match against.
Rockchip has an RV11xx SoC series (RV1103, RV1106, RV1126) so let's
match *anything* in U-Boot which contains this string in the path and
not only the U-Boot Device Trees.
Rockchip also manufactures PMICs and regulators typically under the
RK8xx naming scheme (e.g. RK806, RK808, RK860, etc.) so let's match
files with rk8 in their path.
Most Rockchip SoCs have their name start with rk3xxx. Historically, the
second digit is for the generation of SoC, e.g. rk31xx was before
rk32xx, itself before rk33xx and now rk35xx (and the expected rk36xx end
of this year). We won't talk about the rk30xx timeline but it's also
prefixed the same way. So let's match *anything* in U-Boot which
contains rk3 in the path to simplify the MAINTAINERS entry and hopefully
catch as much as possible.
board/firefly/ and board/pine64/ only contain subdirectories and each of
them have rk3 in their name.
PX5 is a Rockchip SoC, so let's match *anything* in U-Boot which
contains this string in the path. However, this matches a bit too much,
specifically the PPC-based kmsupx5_defconfig so we need to exclude it
explicitly.
Tom Rini [Thu, 9 Jul 2026 14:02:23 +0000 (08:02 -0600)]
Merge tag 'ubi-updates-for-2026.10-rc1' of https://source.denx.de/u-boot/custodians/u-boot-ubi
ubi updates for 2026.10-rc1
- fs: ubifs: fix ubifs_finddir() from Patrick Fixes: 0cab29ff467e ("fs: ubifs: Fix and rework error handling in ubifs_finddir")
fix test -e
- cmd: ubi: rework from Weijie
- env: ubi: add support to create environment volume if it does not exist
- cmd: ubi: allow creating volume with all free spaces in ubi_create_vol
- cmd: ubi: export more APIs to public
- cmd: ubi: reorganize command messages
- cmd: ubi: change all positive error return value to negative
- cmd: ubi: change the type of parameter dynamic to bool
- cmd: ubifs: mark string parameters with const
- cmd: ubi: use void * for buf parameter in ubi_volume_read
- cmd: ubi: mark read-only function parameters with const
- ubi: remove unnecessary extern directive from function prototypes
This patch series add pin controller and gpio driver support for EN7523/
AN7581/AN7583 SoCs. The driver based on official linux airoha pinctrl
and gpio driver with Matheus Sampaio Queiroga changes.
The original Matheus Sampaio Queiroga driver can be taken from the repo:
https://sirherobrine23.com.br/airoha_en7523/kernel/src/branch/airoha_en7523_pinctrl
Additionally in the EN7523 case the patches removes existing gpio dts
nodes and replaces them with pinctrl node. It should not be very
dangerous, because:
* No official EN7523 gpio support present in U-Boot
* Legacy Linux EN7523 GPIO driver is mostly abandoned
* The same driver is planned for upstream linux/openwrt
This patchset includes bitfield.h patches created for Linux kernel by
Geert Uytterhoeven. It suits U-Boot fine. I preserve original author and
original commit messages. Please note me, if there is a better way.
The patches were tested on EN7523/AN7581/AN7583 boards.
These pinconf/pinctrl definitions will be used by the next patches.
The definitions was taken from public headers of linux-7.0. It's used
by several linux pinctrl drivers, so it might be helpful for U-Boot as
well.
Pinconf definitions are placed near the corresponding U-Boot definitions
in file include/dm/pinctrl.h. Pin/group/function definitions stored within
the same path as in linux (include/linux/pinctrl/pinctrl.h).
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: David Lechner <dlechner@baylibre.com>
The existing FIELD_{GET,PREP}() macros are limited to compile-time
constants. However, it is very common to prepare or extract bitfield
elements where the bitfield mask is not a compile-time constant.
To avoid this limitation, the AT91 clock driver and several other
drivers already have their own non-const field_{prep,get}() macros.
Make them available for general use by adding them to
<linux/bitfield.h>, and improve them slightly:
1. Avoid evaluating macro parameters more than once,
2. Replace "ffs() - 1" by "__ffs()",
3. Support 64-bit use on 32-bit architectures,
4. Wire field_{get,prep}() to FIELD_{GET,PREP}() when mask is
actually constant.
This is deliberately not merged into the existing FIELD_{GET,PREP}()
macros, as people expressed the desire to keep stricter variants for
increased safety, or for performance critical paths.
Yury: use __mask within new macros.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Crt Mori <cmo@melexis.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Acked-by: Richard Genoud <richard.genoud@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
[Linux commit: c1c6ab80b25c8db1e2ef5ae3ac8075d2c242ae13] Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
The BUILD_BUG_ON_MSG() check against "~0ull" works only with "unsigned
(long) long" _mask types. For constant masks, that condition is usually
met, as GENMASK() yields an UL value. The few places where the
constant mask is stored in an intermediate variable were fixed by
changing the variable type to u64.
However, for non-constant masks, smaller unsigned types should be valid,
too, but currently lead to "result of comparison of constant 18446744073709551615 with expression of type ... is always
false"-warnings with clang and W=1.
Hence refactor the __BF_FIELD_CHECK() helper, and factor out
__FIELD_{GET,PREP}(). The later lack the single problematic check, but
are otherwise identical to FIELD_{GET,PREP}(), and are intended to be
used in the fully non-const variants later.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
[Linux commit: 2a6c045640c38a407a39cd40c3c4d8dd2fd89aa8] Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Gerald Van Baren <vanbaren@cideas.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
board: renesas: gen5-cm33: #undef field_{get, prep}() before definition
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
clk: renesas: #undef field_{get, prep}() before definition
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
mtd: nand: raw: sunxi: #undef field_{get, prep}() before definition
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
net: hifemac: #undef field_{get, prep}() before definition
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
power: domain: renesas-r8a78000: #undef field_{get, prep}() before definition
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
watchdog: renesas_wwdt: #undef field_{get, prep}() before definition
Prepare for the advent of globally available common field_get() and
field_prep() macros by undefining the symbols before defining local
variants. This prevents redefinition warnings from the C preprocessor
when introducing the common macros later.
Weijie Gao [Wed, 20 May 2026 08:27:41 +0000 (16:27 +0800)]
env: ubi: add support to create environment volume if it does not exist
When U-Boot is booting from a fresh device, the environment volume may not
exist in the factory UBI image. This is a common case where factory UBI
image contains only volumes with valid data.
With the current design, even if the volume is created manually, the
environment will still be unusable (e.g., saveenv) before a reboot.
This patch adds support to automatically create missing volumes before
loading environment. This will make environment available at first boot.
There are two options:
CONFIG_ENV_UBI_VOLUME_CREATE: whether to enable volume creation
CONFIG_ENV_UBI_VOLUME_STATIC: create static volume (default is dynamic)
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Weijie Gao [Wed, 20 May 2026 08:27:38 +0000 (16:27 +0800)]
cmd: ubi: export more APIs to public
Export the following functions to public:
- ubi_detach(): this is paired with ubi_part(). One may call this function
to completely clean up the ubi subsystem after using ubi_part().
- ubi_{create,find,remove}_vol: this is a set of functions for volume
management.
The original ubi_remove_vol is renamed to __ubi_remove_vol to allow the new
ubi_remove_vol() being used as a wrapper for __ubi_remove_vol() with volume
name.
Also, comments are added for all exported functions.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Weijie Gao [Wed, 20 May 2026 08:27:36 +0000 (16:27 +0800)]
cmd: ubi: reorganize command messages
This patch moves normal subcommand messages into the main command function.
This will allow current and potential api functions being called with clean
output on success.
A new function ubi_require_volume() is added for finding and printing error
message if volume not found. The original ubi_find_volume() will be silent
for being an api function.
To avoid ubi_require_volume() being called twice for volume read/remove,
some changes are required:
- The parameter of ubi_remove_vol() is changed to accept
'struct ubi_volume *' directly.
- The original ubi_volume_read() is renamed to __ubi_volume_read, with its
first parameter changed to accept also 'struct ubi_volume *' directly.
- A new ubi_volume_read() is added to wrap __ubi_volume_read() to accept
volume name as its first parameter.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Weijie Gao [Wed, 20 May 2026 08:27:35 +0000 (16:27 +0800)]
cmd: ubi: change all positive error return value to negative
Change all return value using errno codes to negative. This makes it
consistent with the linux ubi layer.
Also, to follow the standard definition of U-Boot command, in the do_ubi()
command handler, the return value is converted to CMD_RET_FAILURE for error
returning, and CMD_RET_USAGE for incorrect usage.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
ubifs_finddir() can return a negative error code (-ENOMEM or
PTR_ERR(dent)) and returns 1 when the name is found in the directory.
Fix the result check accordingly.
This fixes file existence detection (for "test -e") when U-Boot uses
UBIFS through ops ubifs_exists(). Since this function is also called
before other file operations, commands such as "load" could be executed
on a non-existing file without reporting an error.
Fixes: 0cab29ff467e ("fs: ubifs: Fix and rework error handling in ubifs_finddir") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Coben Han [Thu, 11 Jun 2026 03:06:46 +0000 (12:06 +0900)]
i2c: designware: fix i2c probe error
Probing i2c slave device just needs its device address.
A certain type of chipsets such as RTC S35390A have no offset,
which means address length should be 0.
But the current designware_i2c_probe_chip function requires
offset 0 and its length 1.
This causes the designware-i2c to be initialized again and again.
Furthermore, after booting into kernel, the designware-i2c kernel
driver complains its controller timeout.
This patch fixes this misbehaviour in such way that only device
address is issued, no reinitialization needs when target device
not detected, the designware-i2c kernel driver continues working.
Michal Simek [Mon, 29 Jun 2026 09:46:36 +0000 (11:46 +0200)]
arm: dts: zynqmp: Fix space indentation to use tabs
Fix indentation issues where spaces were used instead of tabs in several
ZynqMP device tree overlay files. Device tree files should use tabs for
indentation to maintain consistency with the kernel coding style.
Harini T [Mon, 29 Jun 2026 09:46:33 +0000 (11:46 +0200)]
arch: arm: dts: Add RTC clock nodes for ZynqMP platform
Add fixed RTC clock nodes at 32.768 kHz for ZynqMP. The RTC driver uses
this clock to calculate the calibration value, replacing the deprecated
calibration device tree property.
Michal Simek [Tue, 23 Jun 2026 12:53:43 +0000 (14:53 +0200)]
arm64: versal-net: Add mmc_get_env_dev() and deduplicate MMC handling
The SD and eMMC cases in boot_targets_setup() duplicated the MMC device
lookup, and versal-net relied on the weak mmc_get_env_dev() default
instead of selecting the device matching the boot mode (unlike versal and
zynqmp).
Factor the lookup into mmc_get_bootseq(), mirroring spi_get_bootseq():
it maps the boot mode to the MMC node and returns the device sequence,
optionally handing back the mode banner so only boot_targets_setup()
prints it. mmc_get_env_dev() is now provided as a thin wrapper, and the
SD/eMMC cases call the helper instead of open-coding the lookups. The
local udevice pointer in boot_targets_setup() is no longer needed.
Michal Simek [Tue, 23 Jun 2026 12:53:42 +0000 (14:53 +0200)]
arm64: versal-net: Look up eMMC device in boot_targets_setup()
The EMMC_MODE case set bootseq from dev_seq(dev) without ever assigning
dev, so it used an uninitialized pointer and produced a bogus device
sequence in boot_targets.
eMMC is wired to the SD1 controller (mmc@f1050000, see
versal-net-mini-emmc.dts). Look that device up like the SD cases do
before using its sequence number.
Michal Simek [Tue, 23 Jun 2026 12:53:41 +0000 (14:53 +0200)]
arm64: versal-net: Do not print bootmode from spi_get_env_dev()
spi_get_bootseq() printed the QSPI/OSPI mode banner, which is noise when
called from spi_get_env_dev() during environment setup. The banner is
only meaningful for the "Bootmode:" announcement in boot_targets_setup().
Make spi_get_bootseq() a pure lookup that returns the banner string
through an optional output argument instead of printing it.
spi_get_env_dev() passes NULL and stays silent, while
boot_targets_setup() prints the returned mode name as before.
The QSPI and OSPI cases only differ in the SPI device name. Pick the name
in the switch and perform a single uclass_get_device_by_name() lookup
afterwards, instead of repeating the lookup and dev_seq() in every case.
spi_get_env_dev() and boot_targets_setup() both decoded the QSPI/OSPI
boot modes into a SPI device sequence number with identical
uclass_get_device_by_name() lookups.
Factor that logic into a single spi_get_bootseq() helper that takes the
bootmode and returns the device sequence. spi_get_env_dev() becomes a
thin wrapper around it, and boot_targets_setup() calls it for the
QSPI/OSPI cases instead of open-coding the lookups. Passing the bootmode
in avoids reading the bootmode register twice in boot_targets_setup().
Michal Simek [Tue, 23 Jun 2026 12:53:38 +0000 (14:53 +0200)]
arm64: zynqmp: Decouple MMIO accessors from firmware
zynqmp_mmio_read() and zynqmp_mmio_write() selected between direct MMIO
and the firmware (PM_MMIO_READ/WRITE) interface with an in-function
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) / current_el() check. Generic arch
code should not carry firmware-specific ifdefs, and with SCMI the access
method changes again.
Split the accessors like the multiboot and bootmode hooks: the weak
default in arch/arm/mach-zynqmp does the direct MMIO access (used in SPL,
at EL3 and when no firmware is present), while firmware-zynqmp.c provides
a strong definition that issues the firmware call and falls back to the
direct access in SPL/EL3 where the SMC path is unavailable. The raw MMIO
primitives zynqmp_mmio_rawread() and zynqmp_mmio_rawwrite() are exported
for the shared fallback, and the read-modify-write helper now uses the
raw read instead of routing through the firmware-aware accessor.
The firmware-vs-MMIO decision is selected at link time, so adding SCMI
later only requires a third strong definition with no changes to generic
code.
Michal Simek [Tue, 23 Jun 2026 12:53:37 +0000 (14:53 +0200)]
arm64: versal-net: Move bootmode decoding out of board code
versal_net_get_bootmode() open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl() in board code. Like
the Versal change, move the whole function behind an overridable hook so
generic board code stays free of firmware specifics and is ready for
SCMI.
The weak versal_net_get_bootmode() in arch/arm/mach-versal-net does the
plain MMIO read via versal_net_bootmode_reg() and decodes it (used at EL3
and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Michal Simek [Tue, 23 Jun 2026 12:53:36 +0000 (14:53 +0200)]
arm64: versal-net: Move SoC detection out of board code
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal-net where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Michal Simek [Tue, 23 Jun 2026 12:53:35 +0000 (14:53 +0200)]
arm64: versal2: Move SoC detection out of board code
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal2 where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Michal Simek [Tue, 23 Jun 2026 12:53:34 +0000 (14:53 +0200)]
arm64: zynqmp: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the system timestamp counter directly
with readl()/writel() in board code. This is SoC register setup rather
than board policy, and similar code exists across the Xilinx SoCs.
Move it into zynqmp_timer_setup() in arch/arm/mach-zynqmp so the board
hook only keeps the EL3 guard and calls the helper. The asm/arch/clk.h
include (for zynqmp_get_system_timer_freq()) moves to cpu.c along with
the code.
Michal Simek [Tue, 23 Jun 2026 12:53:33 +0000 (14:53 +0200)]
arm64: versal-net: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_net_timer_setup() in arch/arm/mach-versal-net so the
board hook only keeps the EL3 guard and calls the helper.
Michal Simek [Tue, 23 Jun 2026 12:53:32 +0000 (14:53 +0200)]
arm64: versal2: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal2_timer_setup() in arch/arm/mach-versal2 so the board
hook only keeps the EL3 guard and calls the helper.
Michal Simek [Tue, 23 Jun 2026 12:53:31 +0000 (14:53 +0200)]
arm64: versal: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_timer_setup() in arch/arm/mach-versal so the board
hook only keeps the EL3 guard and calls the helper.
Michal Simek [Tue, 23 Jun 2026 12:53:30 +0000 (14:53 +0200)]
arm64: versal: Move bootmode decoding out of board code
versal_get_bootmode() lived in board code and open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl(). To keep generic board
code free of firmware specifics and SoC register details and ready for
SCMI, move the whole function, including the alt-shift and mask decoding,
behind an overridable hook.
The weak versal_get_bootmode() in arch/arm/mach-versal does the plain
MMIO read via versal_bootmode_reg() and decodes it (used at EL3 and
without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Michal Simek [Tue, 23 Jun 2026 12:53:29 +0000 (14:53 +0200)]
arm64: versal: Decouple multiboot register access from firmware
versal_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal_multi_boot_reg() so the firmware override does not duplicate it.
versal_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface for the multiboot register. The firmware-vs-MMIO decision is
selected at link time, and adding SCMI later only requires a third strong
definition with no board-code changes.
Michal Simek [Tue, 23 Jun 2026 12:53:28 +0000 (14:53 +0200)]
arm64: versal2: Move bootmode decoding out of board code
versal2_get_bootmode() lived in board code and accessed the CRP boot
mode register with a direct readl(). To keep generic board code free of
SoC register details and ready for firmware/SCMI based access, move the
whole function, including the alt-shift and mask decoding, into
arch/arm/mach-versal2 as a __weak default.
Board code now simply calls versal2_get_bootmode(). When a firmware
based implementation is available and tested it can provide a strong
definition that overrides the weak one at link time; until then only the
weak MMIO version is built.
Michal Simek [Tue, 23 Jun 2026 12:53:27 +0000 (14:53 +0200)]
arm64: versal2: Decouple multiboot register access from firmware
versal2_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal2_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal2 and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal2_multi_boot_reg() so the firmware override does not duplicate it.
versal2_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface and the now unused zynqmp_firmware.h include is dropped. The
firmware-vs-MMIO decision is selected at link time, and adding SCMI later
only requires a third strong definition with no board-code changes.
Michal Simek [Tue, 23 Jun 2026 12:53:26 +0000 (14:53 +0200)]
arm: xilinx: Guard mach sys_proto.h against multiple inclusion
The Versal and Versal Gen 2 mach sys_proto.h headers lacked an include
guard. mach-versal/sys_proto.h additionally defines enum tcm_mode, so
including it twice in one translation unit fails to build with a
redeclaration error.
This is about to happen in firmware-zynqmp.c, which needs the SoC
prototypes unconditionally for the upcoming weak/strong multiboot and
bootmode accessors. Add the standard _ASM_ARCH_SYS_PROTO_H guard, as
already used by mach-zynqmp, so the header can be included more than once.
Padmarao Begari [Tue, 23 Jun 2026 15:08:22 +0000 (20:38 +0530)]
soc: xilinx: zynqmp: Add TCG variant detection for ZU3TCG
The XCZU3TCG device shares IDCODE 0x04718093 with XCZU3TEG but has
the GPU disable eFuse bit set (Consumer Grade, no GPU). Previously,
the TEG detection branch appended "teg" unconditionally, causing
U-Boot to report the device as zu3teg and failing bitstream ID
checks for xczu3tcg bitstreams.
Check EFUSE_GPU_DIS_MASK in the TEG branch to distinguish the two
sub-variants, mirroring the existing EG/CG detection logic:
- GPU disabled -> TCG family -> "zu3tcg"
- GPU enabled -> TEG family -> "zu3teg"
Pranav Tilak [Tue, 23 Jun 2026 03:53:51 +0000 (09:23 +0530)]
ufs: amd-versal2: Fix missing .priv_auto in driver registration
Add missing .priv_auto field to the driver. Without it,
struct ufs_versal2_priv is never properly allocated and dev_get_priv()
returns NULL, leading to DDR corruption at low DDR addresses.
Fixes: b5ac5f030720 ("ufs: ufs-amd-versal2: Add support for AMD UFS controller") Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20260623035411.2088224-1-pranav.vinaytilak@amd.com
Marek Vasut [Wed, 17 Jun 2026 02:48:46 +0000 (04:48 +0200)]
MAINTAINERS: Replace Zynq/ZynqMP with N:
Use N: to match on all zynq/zynqmp files, drop the large list of
entries which represent the same set of relevant files and miss a
few in the process. Combine Zynq and ZynqMP entries into single
entry to further cut down the duplication.