Tom Rini [Fri, 11 Jul 2025 18:43:36 +0000 (12:43 -0600)]
python: requirements.txt: Update a few modules for security issues
The GitHub dependabot tool has reported a number of issues recently with
some modules that we use. While unlikely to be exploitable in the way we
use them, update various libraries to the latest.
Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini@konsulko.com>
- Add support for the i.MX95 B0 version.
- Enable standard boot for phycore-imx8mp.
- Kconfig fixes for i.MX MMC and FSL_SEC_MON.
- Support 4Gb single die variant of the i.MX8MM Venice board.
- Board: mpfs_icicle: Fix board_fit_config_name_match and disable
DEBUG_UART
- Board: Add SD card support to the Beagle-V-Fire
- Board: Add support for TH1520-integrated GMACs
Andrew Goodbody [Thu, 3 Jul 2025 14:03:30 +0000 (15:03 +0100)]
mmc: Take cleanup path to free memory on error exit
Instead of returning -EINVAL directly which will not call the cleanup
path to free memory, fix the code to set the error and then goto the
cleanup code.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tim Harvey [Mon, 14 Jul 2025 17:23:03 +0000 (10:23 -0700)]
venice: lpddr4_timing_imx8mm: update ddr phy config for mscale_v3.10
Update the ddr phy config values to those created by the mscale_v3.10
tool. The original values were obtained using mscale_v3.10. The v3.10
tool removed ddr phy register values of 0x0.
This has no functional change but makes comparing and patching ddr
configuration easier in addition to slightly shrinking the DRAM config
size.
Tim Harvey [Mon, 14 Jul 2025 17:23:02 +0000 (10:23 -0700)]
venice: lpddr4_timing_imx8mm: add 4gb single die support
Add dram support for the MT53E1G32D2FW-046 RevC part which is a single die
32Gbit density part vs RevA/B which were dual-die parts:
- use a previously unused EEPROM byte to denote a variant of the
base config to be patched
- add a dram description string
- return the board struct from eeprom_init and pass it to the
spl_dram_init function so that it has access to the EEPROM
- move ddr_init into the spl_dram_init so that it can be patched
in the per-soc init function
Add the configuration register for DDRC_ADDRMAP7 which was added in the
RAP spreadsheet v19. This has no functional change but allows DRAM
configuration to be patched in a later commit.
Tom Rini [Fri, 11 Jul 2025 15:20:25 +0000 (09:20 -0600)]
nxp: Move FSL_SEC_MON related options to arch/Kconfig.nxp
The options related to FSL_SEC_MON are part of the chain of trust
related options and should be under that menu, so move it there.
Furthermore we don't need to prompt for the driver itself but do need to
allow for configuration of the monitor endianess.
Tom Rini [Fri, 11 Jul 2025 15:15:52 +0000 (09:15 -0600)]
brppt2: Use the correct MMC driver
As part of splitting the i.MX parts of FSL_ESDHC out from the more
legacy parts, the FSL_ESDHC_IMX symbol was added. This platform is the
only one which was not converted correctly.
Fixes: e37ac717d796 ("Convert to use fsl_esdhc_imx for i.MX platforms") Signed-off-by: Tom Rini <trini@konsulko.com>
Ye Li [Mon, 7 Jul 2025 20:42:55 +0000 (04:42 +0800)]
spl: imx: Add support for new PQC container
To support PQC container format which is used for post quantum
authentication on new i.MX parts like i.MX94
The major changes compared to legacy container format is in
signature block, new container tag and version, and new alignment
of container header.
Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Alice Guo <alice.guo@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com>
Alice Guo [Mon, 7 Jul 2025 20:42:54 +0000 (04:42 +0800)]
tools: imx8image: Add 2 new commands CMD_CNTR_VERSION and CMD_DUMMY_DDR
i.MX95 B0 uses image container format v2, and `one container header
occupies 0x4000, so that CMD_CNTR_VERSION needs to be added.
The purpose of CMD_DUMMY_DDR is to create a dummy image entry in boot
container prior the DDR OEI image entry. ROM reads the address of DUMMY
DDR image entry and passes it to DDR OEI in OEI entry function as
parameter value, in order to indicate the offset of training data with
the boot container.
Ye Li [Mon, 7 Jul 2025 20:42:53 +0000 (04:42 +0800)]
arm: imx: Update ELE get_info structure for i.MX94
Since i.MX94, the ELE get_info structure is updated to add
OEM PQC SRK hash, so update it.
Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Alice Guo <alice.guo@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com>
Yao Zi [Thu, 10 Jul 2025 03:42:01 +0000 (03:42 +0000)]
configs: th1520_lpi4a: Enable network support
Enable the network stack, the designware ethernet driver and
corresponding glue driver. The Lichee Pi 4A board ships two RTL8211F
phys, both attached to GMAC 0, thus support for Realtek phys and DM
support for MDIO devices are enabled as well.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Thu, 10 Jul 2025 03:42:00 +0000 (03:42 +0000)]
riscv: dts: th1520: Describe GMACs and enable them on Lichee Pi 4A
TH1520 SoC ships two MAC controllers based on Designware Ethernet IP
that are capable of Gigabit operation. Describe them in SoC devicetree
and enable them for Lichee Pi 4A.
Signed-off-by: Yao Zi <ziyao@disroot.org> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Thu, 10 Jul 2025 03:41:59 +0000 (03:41 +0000)]
drivers: net: Add T-Head DWMAC glue layer
The Designware IP integrated in TH1520 SoC requires extra clock
configuration to operate correctly. The Linux kernel's T-Head DWMAC glue
driver is ported and adapted to U-Boot's API.
Signed-off-by: Yao Zi <ziyao@disroot.org> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Thu, 10 Jul 2025 03:41:58 +0000 (03:41 +0000)]
riscv: cpu: th1520: Limit upper RAM boundary to 4 GiB
TH1520 SoC ships DMA peripherals that could only reach the first 32-bit
range of memory, for example, the GMAC controllers. Let's limit the
usable top of RAM below 4GiB to ensure DMA allocations are accessible to
all peripherals.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Thu, 10 Jul 2025 03:41:57 +0000 (03:41 +0000)]
clk: thead: th1520-ap: Correctly handle flags for dividers
Unlike the gate clocks which make no use of flags, most dividers in
TH1520 SoC are one-based, thus are applied with CLK_DIVIDER_ONE_BASED
flag. We couldn't simply ignore the flag, which causes wrong results
when calculating the clock rates.
Add a member to ccu_div_internal for defining the flags, and pass it to
divider_recalc_rate(). With this fix, frequency of all the clocks match
the Linux kernel's calculation.
Fixes: e6bfa6fc94f ("clk: thead: Port clock controller driver of TH1520 SoC") Signed-off-by: Yao Zi <ziyao@disroot.org> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
spi: coreqspi: add xfer function for PolarFire SoC
Add xfer function to PolarFire SoC coreqspi driver. The read and write
operations are limited to one byte at a time instead of four as CMD18
(multiple block read) reads garbage when four byte ops are enabled.
Signed-off-by: Eoin Dickson <eoin.dickson@microchip.com> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
By default DEBUG_UART uses the SBI DBCN extension on S-Mode RISC-V
platforms, but the Icicle Kit's firmware doesn't support it. Since
DEBUG_UART is getting turned on automagically and this is somewhat
misleading, disable it in the Icicle kit's defconfig.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The loop in the icicle implementation of board_fit_config_name_match()
runs strtok() to split off the vendor portion of the compatible string
using , as the delimiter. strtok() modifies a string in place, so where
the first config and compatible do not match, the compatible has been
modified by the time the loop hits the second iteration.
Since stringlists in dt land are null separated strings, the nulls
strtok() inserts to replace the delimiter increase the number of strings
in the compatible list. When the second iteration of the loop calls
fdt_stringlist_get(), it gets the vendorless portion of the first
compatible string, rather than the second compatible string. Copy each
compatible before calling strtok() to avoid this problem.
The temporary string the compatible is copied to is statically
allocated, as attempts to dynamically allocate it at this stage of boot
were met with "alloc space exhausted" errors.
Mark Kettenis [Sat, 12 Jul 2025 18:52:27 +0000 (20:52 +0200)]
board: vexpress_ca9x4: Enable D-cache and MMU
Enable the D-cache, which will also enable the MMU. The latter
make sure we don't do unaligned access on Strongly-ordered memory,
which has UNPREDICTABLE behaviour according the architecture
definition. This fixes using U-Boot with recent versions of
QEMU's vexpress-ca9 emulation.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Andrew Goodbody [Wed, 9 Jul 2025 11:49:09 +0000 (12:49 +0100)]
boot: Ensure method_flags is initialised before use
The local variable method_flags is only assigned to in some of the
code paths leaving it possibly uninitialised at first use.
Initialise method_flags at declaration to ensure that it cannot be
used uninitialised. Also remove now redundant assignments.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Sam Protsenko [Wed, 9 Jul 2025 04:23:42 +0000 (23:23 -0500)]
dfu: Fix dfu_config_interfaces() for single interface DFU syntax
As stated in DFU documentation [1], the device interface part might be
missing in dfu_alt_info:
dfu_alt_info
The DFU setting for the USB download gadget with a semicolon
separated string of information on each alternate:
dfu_alt_info="<alt1>;<alt2>;....;<altN>"
When several devices are used, the format is:
- <interface> <dev>'='alternate list (';' separated)
So in first case dfu_alt_info might look like something like this:
dfu_alt_info="mmc 0=rawemmc raw 0 0x747c000 mmcpart 1;"
And in second case (when the interface is missing):
dfu_alt_info="rawemmc raw 0 0x747c000 mmcpart 1;"
When the interface is not specified the 'dfu' command crashes when
called using 'dfu 0' or 'dfu list' syntax:
=> dfu list
"Synchronous Abort" handler, esr 0x96000006, far 0x0
That's happening due to incorrect string handling in
dfu_config_interfaces(). In case when the interface is not specified in
dfu_alt_info it triggers this corner case:
d = strsep(&s, "="); // now d contains s, and s is NULL
if (!d)
break;
a = strsep(&s, "&"); // s is already NULL, so a is NULL too
if (!a) // corner case
a = s; // a is NULL now
which causes NULL pointer dereference later in this call, due to 'a'
being NULL:
part = skip_spaces(part);
That's because as per strsep() behavior, when delimiter ("&") is not
found, the token (a) becomes the entire string (s), and string (s)
becomes NULL. To fix that issue assign "a = d" instead of "a = s",
because at that point variable d actually contains previous s, which
should be used in this case.
[1] doc/usage/dfu.rst
Fixes: commit febabe3ed4f4 ("dfu: allow to manage DFU on several devices") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Link: https://lore.kernel.org/r/20250709042342.13544-1-semen.protsenko@linaro.org Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Wed, 2 Jul 2025 01:06:03 +0000 (19:06 -0600)]
common/avb_verify.c: Make use of LBAF for printing lbaint_t
When printing the contents of an lbaint_t variable we need to use LBAF
to print it in order to get the correct format type depending on 32 or
64bit-ness.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Link: https://lore.kernel.org/r/20250702010603.19354-2-trini@konsulko.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Wed, 2 Jul 2025 01:06:02 +0000 (19:06 -0600)]
boot/android_ab.c: Make use of LBAF for printing lbaint_t
When printing the contents of an lbaint_t variable we need to use LBAF
to print it in order to get the correct format type depending on 32 or
64bit-ness. Furthermore, printed message should not be split as that
makes finding them harder, so bring this back to a single line.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Link: https://lore.kernel.org/r/20250702010603.19354-1-trini@konsulko.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
cmd: i2c: fix build when CFG_SYS_I2C_NOPROBES defined with DM_I2C
When DM_I2C is enabled and CFG_SYS_I2C_NOPROBES is defined, the
building is broken due to already existing 'bus' local variable.
Rename udevice 'bus' to 'cur_bus' to fix this.
drivers/net/airoha_eth: fix stalling in package receiving
ARCH_DMA_MINALIGN is 64 for ARMv7a/ARMv8a architectures, but RX/TX
descriptors are 32 bytes long. So they may not be aligned on an
ARCH_DMA_MINALIGN boundary. In case of RX path, this may cause the
following problem
1) Assume that a packet has arrived and the EVEN rx descriptor has been
updated with the incoming data. The driver will invalidate and check
the corresponding rx descriptor.
2) Now suppose the next descriptor (ODD) has not yet completed.
Please note that all even descriptors starts on 64-byte boundary,
and the odd ones are NOT aligned on 64-byte boundary.
Inspecting even descriptor, we will read the entire CPU cache line
(64 bytes). So we read and sore in CPU cache also the next (odd)
descriptor.
3) Now suppose the next packet (for the odd rx descriptor) arrived
while the first packet was being processed. So we have new data
in memory but old data in cache.
4) After packet processing (in arht_eth_free_pkt() function) we will
cleanup the descriptor and put it back to rx queue.
This will call flush_dcache_range() function for the even descriptor,
so the odd one will be flushed as well (it is in the same cache line).
So the old data will be written to the next rx descriptor.
5) We get a freeze. The next descriptor is empty (so the driver is
waiting for packets), but the hardware will continue to receive
packets on other available descriptors. This will continue until
the last available rx descriptor is full. Then the hardware will
also freeze.
The problem will be solved if the previous descriptor will be put back
to the queue instead of the current one.
If the current descriptor is even (starts on a 64-byte boundary),
then putting the previous descriptor to the rx queue will affect
the previous cache line. To be 100% ok, we must make sure that the
previous and the one before the previous descriptor cannot be used
for receiving at this moment.
If the current descriptor is odd, then the previous descriptor is on
the same cache line. Both (current and previous) descriptors are not
currently in use, so issue will not arrise.
WARNING: The following restrictions on PKTBUFSRX must be held:
* PKTBUFSRX is even,
* PKTBUFSRX >= 4.
The bug appears on 32-bit airoha platform, but should be present on
64-bit as well.
The code was tested both on 32-bit and 64-bit airoha boards.
The dma_map_single() function calls one of the functions
* invalidate_dcache_range(),
* flush_dcache_range().
Both of them expect that 'vaddr' is aligned to the ARCH_DMA_MINALIGN
boundary. Unfortunately, RX/TX descriptors are 32-byte long. Thus they
might not be aligned to the ARCH_DMA_MINALIGN boundary. Data flushing
(or invalidating) might do nothing in this case.
The same applies to dma_unmap_single() function.
In the TX path case the issue might prevent package transmission (filled
TX descriptor was not flushed).
To fix an issue a special wrappers for
* dma_map_single(),
* dma_unmap_single()
functions were created. The patch fix flushing/invalidatiog for the
RX path as well.
The bug appears on 32-bit airoha platform, but should be present on
64-bit as well.
The code was tested both on 32-bit and 64-bit airoha boards.
drivers/net/airoha_eth: add missing terminator for compatible devices list
Compatible device list must have a terminator. If terminator is missed
the u-boot driver subsystem will access random data placed after the
list in the memory.
The issue can be observed with the "dm compat" command.
Andrew Goodbody [Tue, 8 Jul 2025 11:16:42 +0000 (12:16 +0100)]
fs: exfat: Remove pointless variable uoffset
In exfat_generic_pread and exfat_generic_pwrite offset is passed in as a
off_t type which is defined as 'unsigned long long' so there is no need
to create the variable uoffset as a uint64_t as this is just a direct
copy of offset. Also remove the impossible test of 'offset < 0' as this
is always false due to offset being unsigned.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Tue, 8 Jul 2025 11:16:41 +0000 (12:16 +0100)]
fs: exfat: Perform NULL check before dereference
In the functions exfat_pread and exfat_pwrite there is a NULL check for
ctxt.cur_dev but this has already been derefenced twice before this
happens.
Refactor the code a bit to put the NULL check first.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
In the Fixes commit, I initialized size_inc from the return value of
the new fit_estimate_hash_sig_size() helper. That helper may fail and
report that by returning a negative value, but I overlooked that
size_inc had type size_t, and hence the error check doesn't work.
Change size_inc to have type int so the error check works. Inside the
loop, it is passed to another function as a size_t parameter, but
that's fine, because we know it is non-negative, and its value may be
incremented in steps of 1024 and is capped at ~64K, so it will
certainly never overflow an int.
Fixes: 7d4eacb0e68 ("mkimage: do a rough estimate for the size needed for hashes/signatures")
Addresses-Coverity-ID: 569495: Integer handling issues (NEGATIVE_RETURNS) Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
CONFIG_NR_DRAM_BANKS defines the number of DRAM banks on the
device. The default value of NR_DRAM_BANKS for ARCH_K3 is set to 2
(arch/arm/mach-k3/Kconfig:199) but should be 1 for am62x platforms.
This patch updates NR_DRAM_BANKS value for all am62x platforms to 1.
Andrew Goodbody [Mon, 7 Jul 2025 16:26:53 +0000 (17:26 +0100)]
pci: Assign a default value on reads on error
Many callers of PCI read functions do not check the return value for
error before using the variable that should contain the value read were
there not to be an error. However in the error case this variable is
never assigned to and so will contain uninitialised data.
To provide some certainty as to behaviour in the error case assign a
default value of all bits set.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Mon, 7 Jul 2025 14:12:20 +0000 (15:12 +0100)]
scsi: Make static functions consistent using lbaint_t
The static helper functions are inconsistent in their use of their third
parameter which is used to pass a block count. Keep consistency by
always using lbaint_t here. This will fix an issue where two left shifts
were overflowing the variable type in use.
This issue found by Smatch
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Andrew Goodbody [Thu, 3 Jul 2025 10:00:33 +0000 (11:00 +0100)]
cros_ec: sandbox: Use correct value for number of slots
In the definition of struct ec_state the number of slots that are
created is VSTORE_SLOT_COUNT (==4) but the value of req->slot is
checked against EC_VSTORE_SLOT_MAX (==32) so this can lead to memory
access beyond that allocated.
Instead change the size check to use VSTORE_SLOT_COUNT to ensure it
matches what has actually been allocated.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tom Rini [Mon, 14 Jul 2025 18:43:33 +0000 (12:43 -0600)]
Merge patch series "integer limit macro consolidation"
Rasmus Villemoes <ravi@prevas.dk> says:
I was bitten by our limit macros not being usable in #if conditionals
when building a standalone app. It turns out that the work to fix that
had already been started by the inclusion of the mbedtls library, so
it's something that people do hit.
Let's finish the job by providing suitable limit macros for all three families:
Please note that a naive approach like spelling out the full decimal
value for the constants doesn't really work, as there is no such thing
as a "negative integer constant". That is, doing
#define LLONG_MIN -9223372036854775808LL
would lead to the compiler complaining
warning: integer constant is so large that it is unsigned
and the type of that LLONG_MIN would actually be "unsigned long long", so e.g.
#if LLONG_MIN >= 0
#warning "LLONG_MIN is not negative?"
#endif
limits.h: provide all limit macros for standard [u]intNN_t types
Currently, we only have UINT32_MAX and UINT64_MAX in limits.h, and
then stdint.h and kernel.h somewhat randomly define UINT8_MAX and
INT32_MAX, respectively.
Provide a full set of definitions in terms of the min/max macros for
the types that [u]intNN_t are defined in terms of, namely the {s,u}NN
ones.
Try to avoid breaking whatever depended on getting UINT8_MAX from our
compat stdint.h by replacing it with an include of limits.h.
move limits for sNN/uNN types from kernel.h to limits.h
Since we define the {s,u}{8,16,32,64} types the same way on all
architectures, i.e. everybody uses asm-generic/int-ll64.h, we can just
define the associated limit macros in terms of those for the
corresponding types. This eliminates another set of limit macros that
are not usable in #if conditionals.
These type names and macros are not C or POSIX, so there's no language
violation, but certainly a violation of developers' reasonable
expectations.
move more limits from kernel.h to limits.h and standardize their definitions
In a customer project that was building a stand-alone application, I
hit a problem related to the fact that our LONG_MAX and friends are
not standards-compliant, in that they are not "suitable for use in #if
preprocessing directives"
So following up on commit 13de8483388 ("mbedtls: add mbedtls into the
build system"), move the rest of the macros associated to the standard
C types {signed,unsigned} {char, short, int, long, long long} (and of
course bare 'char') to limits.h.
Make use of the fact that both gcc and clang provide suitable
predefined __FOO_MAX__ macros for the signed types, and use a standard
scheme for defining the FOO_MIN and UFOO_MAX macros in terms of
FOO_MAX.
Note that suffixes like L and ULL are allowed for preprocessor
integers; it is (casts) which are not. And using appropriate suffixes,
we can arrange for the type of e.g. UINT_MAX to be "unsigned int" due
to integer promotion rules.
Rui Miguel Silva [Wed, 18 Jun 2025 09:32:16 +0000 (10:32 +0100)]
clk: qcom: sm8650: add usb3 noc clk
Commit [0] introduced, correctly, the bubble of qcom clock errors to
make it easy to spot missing clocks in the platforms, and this is a case
of that, add the GCC_CFG_NOC_USB3_PRIM_AXI_CLK clock to sm8650 clock
pool.
0: 7c5460afec3f ("clk/qcom: bubble up qcom_gate_clk_en() errors")
watchdog: qcom-wdt: Drop read check on write-only WDT_EN register
On some Qualcomm platforms, such as Dragonwing boards, the WDT_EN
register is write-only. Reading it back after enabling the watchdog
can return invalid data or cause unexpected behavior.
In particular, the check:
if (readl(wdt_addr(wdt, WDT_EN)) != 1)
may fail even though the watchdog is correctly enabled and running.
This leads to misleading error messages and unnecessary failures.
Removing the read check ensures compatibility and avoids false
negatives on platforms where WDT_EN is not readable.
This work builds upon this previous submission:
https://lore.kernel.org/u-boot/20250625094607.1348494-1-gopinath.sekar@oss.qualcomm.com/
Neil Armstrong [Mon, 30 Jun 2025 16:04:45 +0000 (18:04 +0200)]
gpio: qcom: move pm8550 gpio to new driver
Move support of the pm8550 gpios to the newly introduced
driver and drop the compatible entry and the read-only quirk
at the same time from the old driver.
Neil Armstrong [Mon, 30 Jun 2025 16:04:44 +0000 (18:04 +0200)]
gpio: qcom: add new driver for SPMI gpios
The current qcom_pmic_gpio driver is too limited and doesn't
support state tracking for all pins like the Linux driver.
Adding full pinconf support would require adding the state
and it's much simpler to restart from scratch with a new
driver based on the Linux one adapted to the U-Boot GPIO
and Pinctrl APIs.
For now only the PMICs I've been able to validate are
added in the compatible list but we should be able to
add the entire list from the Linux driver.
There's a few difference from the Linux driver:
- no IRQ support
- uses the U-Boot GPIO flags that maps very well
- uses the gpio-ranges to get the pins count
- no debugfs but prints the pin state via pinmux callback
It uses the same CONFIG entry as the old one, since
the ultimate goal is to migrate entirely on this new
driver once we verify it doesn't break the older
platforms.
Yao Zi [Fri, 11 Jul 2025 08:52:34 +0000 (08:52 +0000)]
kbuild: Avoid including architecture-specific Makefile twice
Stranges errors are observed when building U-Boot master for almost any
RISC-V board, the messages are in two types, one is about duplicated
symbols,
u-boot/arch/riscv/cpu//mtrap.S:32: multiple definition of `trap_entry';
arch/riscv/cpu/mtrap.o: u-boot/arch/riscv/cpu//mtrap.S:32: first defined here
and the other is fixdep's complaint about missing dependency files,
fixdep: error opening file: arch/riscv/cpu/.mtrap.o.d: No such file or directory
fixdep: error opening file: arch/riscv/cpu//.start.o.d: No such file or directory
where the latter could only be reproduced when building parallelly.
Both the two types of errors are about files in arch/riscv/cpu, and
there's a suspicious slash character in the reported path. Looking
through RISC-V-specific Makefiles, there's only one place that may
expand to such a path,
libs-y += arch/riscv/cpu/$(CPU)/
The right hand expands to "arch/riscv/cpu//" if $(CPU) isn't defined at
the time of including. With some debug statement added to
arch/riscv/Makefile, the output proves that arch/riscv/Makefile is
included twice, once with $(CPU) undefined and once defined correctly
according to CONFIG_SYS_CPU.
Futher bisecting shows an extra include statement against
arch/$(SRCARCH)/Makefile is added in earlier bump of Kbuild system. But
the statement is evaluated before config.mk is included and definition
of $(CPU), causing objects in arch/riscv/cpu/ are built and linked twice
(once as "arch/riscv/cpu/*", and once as "arch/riscv/cpu//*"), resulting
in the error.
Let's simply remove the extra include to fix these nasty errors. For
config targets, bumping Kbuild also introduced a new include to
arch/$(SRCARCH)/Makefile, which is removed as well for consistency.
Fixes: 5f520875bdf ("kbuild: Bump the build system to 5.1") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Fabio Estevam <festevam@gmail.com> Tested-by: Bryan Brattlof <bb@ti.com>
Tom Rini [Fri, 4 Jul 2025 21:46:06 +0000 (15:46 -0600)]
Kconfig: Test for !COMPILE_TEST in some locations
We have a few options that we cannot enable in a "allyesconfig" type
build because we cannot use zero as a default value.
- The logic around HAS_BOARD_SIZE_LIMIT assumes that if we have set this
then we compare with it. Similarly, we need to set SPL_NO_BSS_LIMIT as
the default there.
- Both SYS_CUSTOM_LDSCRIPT and ENV_USE_DEFAULT_ENV_TEXT_FILE then prompt
for a file name to use.
- The SYS_I2C_SOFT driver is a legacy driver which requires a lot of
configuration within the board config. file instead, so disable it.
Tom Rini [Fri, 4 Jul 2025 21:46:05 +0000 (15:46 -0600)]
Kconfig: Add COMPILE_TEST option
Take the COMPILE_TEST option from the Linux Kernel v6.15 and since the
wording there is OK for us too, use it verbatim. Also update the default
for WERROR to be COMPILE_TEST which again matches the Linux Kernel.
This is the first big step needed to allow for "allyesconfig" to be
possible as it then lets us then disable things that aren't valid for a
compile only test.
Tom Rini [Fri, 4 Jul 2025 21:45:42 +0000 (15:45 -0600)]
global: Make ARCH_MISC_INIT a selected symbol
This symbol is not something that the user should be enabling or
disabling but rather the developer for a particular board should select
it when required.
This is mostly size neutral, however a few places do have changes. In
the case of i.MX6ULL systems, it is always the case that
arch_misc_init() could call setup_serial_number() and do useful work,
but was not enabled widely, but now is. In the case of i.MX23/28
systems, we should be able to call mx28_fixup_vt() again here, so do so.
Finally, some platforms were calling arch_misc_init() and then not doing
anything and this results in removing the option.
Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Fri, 4 Jul 2025 21:45:41 +0000 (15:45 -0600)]
toradex: Switch from ARCH_MISC_INIT to MISC_INIT_R in some cases
The hook arch_misc_init was not intended to be used for per-board hooks.
This can be done with misc_init_r instead, which is what follows
immediately after arch_misc_init. Switch a few platforms.
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Andrew Goodbody [Fri, 4 Jul 2025 10:53:18 +0000 (11:53 +0100)]
fs: erofs: Do NULL check before dereferencing pointer
The assignments to sect and off use the pointer from ctxt.cur_dev but
that has not been NULL checked before this is done. So instead move the
assignments after the NULL check.
This issue found by Smatch
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Gao Xiang <xiang@kernel.org>
Move to using the latest generated RM YAML configuration files generated
by the K3 Resource Partitioning Tool which updates them to have standard
formatting with respect to indentation.
These files were generated from the untagged commit 41718bd5f915 ("docs: Update
docs and move them to docs folder") of the K3 Resource Partitioning tool. This
tool is packaged as a part of the public SDK and is not otherwise
publicly available.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com>