board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled
As there are few redundant functions in board/ti/*/evm.c files, pull
them to a common location of access to reuse and include the common file
to access the functions.
Call k3-ddrss driver through fixup_ddr_driver_for_ecc() to fixup the
device tree and resize the available amount of DDR, if ECC is enabled.
Otherwise, fixup the device tree using the regular
fdt_fixup_memory_banks().
Also call dram_init_banksize() after every call to
fixup_ddr_driver_for_ecc() is made so that gd->bd is populated
correctly.
Ensure that fixup_ddr_driver_for_ecc() is agnostic to the number of DDR
controllers present.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
The functionality of enabling Inline ECC is now controlled by
CONFIG_K3_INLINE_ECC. So, remove the support for 'ti,ecc-enable'
property to avoid redundancy and to ensure the Inline ECC feature is
mananged through build-time config.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Setup the ECC region's start and range using the device private data,
ddrss->ddr_bank_base[0] and ddrss->ddr_ram_size. Also, move start and
range of ECC regions from 32 bits to 64 bits to accommodate for
DDR greater than or equal to 4GB.
ram: k3-ddrss: Add k3_ddrss_ddr_bank_base_size_calc() to solve 'calculations restricted to 32 bits' issue
As R5 is a 32 bit processor, the RAM banks' base and size calculation
is restricted to 32 bits, which results in wrong values if bank's base
is greater than 32 bits or bank's size is greater than or equal to 4GB.
So, add k3_ddrss_ddr_bank_base_size_calc() to get the base address and
size of RAM's banks from the device tree memory node, and store in a
64 bit device private data which can be used for ECC reserved memory
calculation, Setting ECC range and Fixing up bank size in device tree
when ECC is enabled.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Georgi Vlaev [Mon, 6 Jan 2025 09:07:01 +0000 (14:37 +0530)]
ram: k3-ddrss: Use the DDR controller BIST engine for ECC priming
The 1-bit inline ECC support in TI's DDRSS bridge requires
the configured memory regions to be preloaded with a pattern
before use. This is done by the k3-ddrss driver from the
R5 SPL in a 'for' loop. It takes around 10 seconds to fill
2GB of memory, for example. Memset can cut the time in half
and using DMA currently yields a similar result.
The BIST engine of DDR controller provides support for
initializing any memory region with a pattern. This
bypasses the DDRSS bridge, so the required inline ECC
data is not computed and populated in the memory. For
some values like zero, the computed ECC syndrome is also
zero and we can use these values to preload the memory
from the DDR controller, without the assistance of the
bridge.
The registers involved in the process are described in the
'DDR controller registers' topic in [1] AM62 and [2] J721E
reference manuals.
The patch replaces the 'for' loop memory fill function with
the BIST memory initialization procedure. This cuts the time
to preload the 2GB memory from 10 seconds down to 1 second.
The bist preload function uses the lpddr4 APIs in the k3-ddrss,
so this is compatible with devices with both 16-bit LPDDR4 and
32-bit LPDDR4 interfaces (e.g J721E).
Signed-off-by: Yang Gang <yanggang@byosoft.com.cn> Fixes: 6b92c1735205 ("efi: Create ECPT table") Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Sat, 21 Dec 2024 17:45:29 +0000 (11:45 -0600)]
doc/develop/distro.rst: Better document upstream definition of extlinux.conf
First, the "Boot Loader Specification" link has moved to a new location,
so link to that directly. Second, that link does not document as much of
the extlinux.conf format as I recall the old version doing at least.
However, the Syslinux Project wiki is the current location of the documentation
linked to in doc/README.pxe and also has a reference for SYSLINUX. Link
to both of these.
The command name was "sbi" instead of "sb" in "doc/usage/cmd/sb.rst",
the file documenting the "sb" command. It is annoying, because the
index in the left panel on the
<https://docs.u-boot.org/en/latest/usage/cmd/sb.html> page shows no
"sb" command, which makes difficult to navigate to the "sb"
documentation.
Fixed the command name: "sbi" -> "sb".
Fixes: ec6d30649cd5 (doc: sandbox: Add docs for the sb command, 2024-10-28) Signed-off-by: Olivier L'Heureux <olivier.lheureux@mind.be> Reviewed-by: Simon Glass <sjg@chromium.org>
The fix provided by 997fc12ec91 is actually introducing
a buffer overrun, and the overrun is effective if the
memory after the reloc section is not zeroed.
Probably that's why this bug is not always noticeable.
The problem is that 8-bytes 'rel' pointer can be 4-bytes aligned
according to the PE Format, so the actual relocate function can
take values after the reloc section.
One example is the following dump from the reloc section:
This section has two relocations at offset bce26008 and bce2600a,
however the given size (rel_size) for this relocation is 16-bytes
and this is coming form the efi image Misc.VirtualSize, so in this
case the 'reloc' pointer ends at affset bce2600c and is taken as
valid and this is where the overflow is.
In our system we see this problem when we are starting the
Boot Guard efi image.
This patch is fixing the overrun while preserving the fix done
by 997fc12ec91.
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@belden.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Ilias Apalodimas [Thu, 28 Nov 2024 07:11:20 +0000 (09:11 +0200)]
efi_loader: Don't warn if the TCG2 FinalEvents table is not installed
When the TCG2 protocol installation fails, we are trying to remove
all the objects we created in tcg2_uninit().
However, there are cases when this function runs before the config
table was installed. So instead of printing an error unconditionally
check against EFI_NOT_FOUND and don't print anything if the table wasn't
installed to begin with.
Currently when booting dhcp_run() may be executed multiple times:
once in eth_bootdev_hunt() and once in the network booting bootmeth.
We need to call eth_bootdev_hunt() when setting up the EFI sub-system to
supply the simple network protocol. We don't need an IP address set up.
We can reduce the bootime by not executing dhcp_run() in
eth_bootdev_hunt().
Furthermore eth_bootdev_hunt() with autostart=yes leads on the legacy
network stack leads to downloading a file via TFTP and to booting the
downloaded file.
Instead of running dchp_run() just check that there is a network device
in eth_bootdev_hunt().
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
'usb start' or invoking eth_bootdev_hunt leads to a crash when function
dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL)
relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 in the CI until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
test_extension.py assumes that no extension is known at test start.
This assumption is wrong because we do not come out of reboot.
A prior test may have already hunted for the extension bootdev.
Remove the invalid assert.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Sean Edmond [Mon, 29 Apr 2024 18:51:16 +0000 (11:51 -0700)]
Fix neighbor discovery ethernet address saving
When a successful neighbor advertisement is received, the ethernet
address should be saved for later use to avoid having to redo the
neighbor discovery process.
For example, with TFTP the address should get saved into
"net_server_ethaddr". This is being done correctly with ARP for IPv4,
but not for neighbor discovery with IPv6.
Signed-off-by: Sean Edmond <seanedmond@microsoft.com> Reviewed-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
Jerome Forissier [Fri, 29 Nov 2024 14:47:32 +0000 (15:47 +0100)]
net: tftpput: reset timeout_count when an ACK is received
timeout_count is never reset once a tftpput transfer has started. If for
whatever reason timeouts occur frequently, but the server keeps replying
nonetheless, the transfer may be needlessly aborted.
Reset timer_count on reception of an ACK to avoid this situation.
Section 3.3 of Reduced Gigabit Media Independent Interface (RGMII)
Version 2.0 (4/1/2002) details that a PHYs using a ~2ns internal delay
are referred to as RGMII-ID. This internal delay is optional.
Page 147-148 of the Marvell Doc. No. MV-S107146-U0 Rev. F details
timings of the RX/TX delays. We see that with the TX/RX_CLK delay
enabled, our RX/TX_CTL signal is shifted w.r.t CLK to reflect the delay
added.
In 431be62 there is no timing difference between RGMII and RGMII-ID, and
so programmers wanting to explicitly set their PHY to RGMII will find
that delay added anyway. This could throw off timing if that internal
delay is undesired.
We should be handling all 4 possible RGMII cases of PHY_INTERFACE_MODE:
RGMII, RGMII_ID, RGMII_TXID, and RGMII_RXID. Reverting 431be62
implements this.
See also m88e1111_config_init_rgmii_delays in the equivalent driver in
Linux (drivers/net/phy/marvell.c), which does not set these delays in
RGMII mode.
68e6eca was tested out on an 88E1512 PHY in RGMII-ID mode. This
reversion has been tested by myself on an 88E1518 in RGMII-ID mode. This
patch affects boards using this driver in "rgmii" mode, as the internal
delay will no longer be enabled. Namely kikwood-nsa310s.
net: tftpboot: clear timeout_count on every successful block
We have a some boards that rarely starts networking abnormally, so there are
many timeouts during file transfer. In the same time there is a normal transfer
between timeouts. In this case we can continue transfer (instead of connection
aborting) by just clearing timeout counter on every successful block.
This patch does not affect the case when several timeouts happen one after
another. The transfer will be aborted. Thus the transfer will be
continued in the case of unstable link, but will be aborted in the case
of inaccessible server.
Feature downside: it may greatly slowdown (instead of abort) file transfer
in the case of unstable link.
Jerome Forissier [Fri, 13 Dec 2024 12:45:36 +0000 (13:45 +0100)]
trace: add support for 'trace wipe'
Implement a 'trace wipe' command to delete the currently accumulated
trace data. This comes handy when someone needs to trace a particular
command. For example:
trace: proftool: dump-ftrace should write funcgraph times in ns not us
When converting a U-Boot trace records file to ftrace function graph
format for use by trace-cmd ('proftool -f funcgraph dump-ftrace'), the
time associated to each function is incorrectly saved in microseconds
instead of nanoseconds. Multuply the value by 1000 to fix the issue.
With this change, the trace-cmd output looks consistent. Here is an
example with udelay(25) added to mem_malloc_init() as a test case:
In the above dump, the udelay() call is reported as taking 26 us which
is consistent with the timestamps (6.719687 - 6.719659 = 0.000026).
Without this patch we would have "0.026 us" instead of "+ 26.000 us".
Manorit Chawdhry [Tue, 17 Dec 2024 08:54:37 +0000 (14:24 +0530)]
drivers: firmware: ti_sci: Add DM_FLAG_PRE_RELOC to driver
Currently the driver relies on bootph flag to probe it during PRE_RELOC
stage but with the upcoming cleanup of v6.13, we don't have the bootph
property in the parent nodes anymore and ti_sci driver being one of the
parent nodes required during SPL stage would end up hampering the probe
model [0].
Add DM_FLAG_PRE_RELOC to ti_sci driver for mitigating this issue.
Bryan Brattlof [Tue, 10 Dec 2024 21:43:30 +0000 (15:43 -0600)]
arm: dts: k3-am62p-sk-binman: add SE security variant builds
The Texas Instruments Foundational Security (TIFS) firmware must match
the security level configured on the SoC. To boot Security Enforced (SE)
variants of the AM62Px, add another tiboot3 build which packages the
Security Enforced (SE) firmware variant for AM62Px SoCs.
Vaishnav Achath [Wed, 18 Dec 2024 13:13:41 +0000 (18:43 +0530)]
arm: dts: k3-j722s*: Add overrides specific to OSPI
OSPI Boot requires overrides specific to R5 and also
to use DMA in R5 SPL stage the DM_TIFS needs to be used.
Add the corresponding overrides for R5 SPL stage.
Vaishnav Achath [Wed, 18 Dec 2024 13:13:39 +0000 (18:43 +0530)]
arm: dts: k3-j722s-r5-evm: Fix DM2TIFS secproxy thread ID
Fix the DM2TIFS secureproxy thread ID as per the latest TISCI
documentation for J722S.
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j722s/sec_proxy.html
Weijie Gao [Tue, 17 Dec 2024 08:40:03 +0000 (16:40 +0800)]
net: mediatek: fix usability with wget command
The wget command currently cannot work correctly with mtk_eth driver.
This patch fixed this by increase DMA ring size and invalidate ring data
after use.
Weijie Gao [Tue, 17 Dec 2024 08:39:41 +0000 (16:39 +0800)]
net: mediatek: fix sgmii selection for mt7622
Unlike other platforms, mt7622 has only one SGMII and it can be
attached to either gmac1 or gmac2. So the register field of the
sgmii selection differs from other platforms as newer platforms can
control each sgmii individually.
This patch adds a new capability for mt7622 to handle this case.
Weijie Gao [Tue, 17 Dec 2024 08:39:23 +0000 (16:39 +0800)]
net: mediatek: use correct register field for SGMII speed selection
The register field for SGMII speed selection is a 2-bit field with
value 0 for 1Gbps and 1 for 2.5Gbps (2/3 are reserved).
So it's necessary to set both bits instead of just setting/clearing
only the lower bit.
Weijie Gao [Tue, 17 Dec 2024 08:39:16 +0000 (16:39 +0800)]
clk: mediatek: mt7629: fix parent clock of some top clock muxes
According to the mt7629 programming guide, the CLK_TOP_F10M_REF_SEL
shares the same parent selection with CLK_TOP_IRRX_SEL, while the
present parent selection for CLK_TOP_F10M_REF_SEL is actually used
for CLK_TOP_SGMII_REF_1_SEL.
Tom Rini [Tue, 31 Dec 2024 16:58:36 +0000 (10:58 -0600)]
Merge patch series "Select CONFIG_64BIT for sandbox64 and x86_64"
Andrew Goodbody <andrew.goodbody@linaro.org> says:
Picking up a series from Dan Carpenter and applying requested
changes for v2.
I had previously set CONFIG_64BIT for arm64. This patchset does the
same thing for sandbox and x86_64. (Mips and riscv were already
doing it). This CONFIG option is used in the Makefile to determine
if it's a 32 or 64 bit system for the CHECKER.
Makefile
1052 # the checker needs the correct machine size
1053 CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
Andrew Goodbody [Mon, 16 Dec 2024 18:07:35 +0000 (18:07 +0000)]
x86: select CONFIG_64BIT for X86_64
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to
static analysis tools.
Introduce CONFIG_SPL_64BIT and select it for architectures other than
x86 with 64 bit builds. Do not select it for x86 builds as x86 uses
a 32 bit SPL.
Ensure that when limits are set they use CONFIG_64BIT for U-Boot
proper and CONFIG_SPL_64BIT for SPL. This is to allow for the 32 bit
SPL build used by x86.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Mon, 16 Dec 2024 18:07:34 +0000 (18:07 +0000)]
sandbox: select CONFIG_64BIT for sandbox
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to
static analysis tools.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Mon, 16 Dec 2024 18:07:33 +0000 (18:07 +0000)]
sandbox: Correct guard around readq/writeq
In include/linux/io.h the declarations of ioread64 and iowrite64
which make use of readq/writeq are guarded with CONFIG_64BIT so
guard the sandbox declarations of readq and writeq also with
CONFIG_64BIT.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Evgeny Bachinin [Tue, 10 Dec 2024 22:39:57 +0000 (01:39 +0300)]
fdtdec: encapsulate dtb_dt_embedded() within
Patch keeps the access to dtb_dt_embedded() within fdtdec API,
by means of new API function introduction. This new function is a
common place for updating appropriate global_data fields for
OF_EMBED case.
Also, the consequence of the patch is movement of '___dtb_dt_*begin'
symbols' declaration from header file, because nobody used symbols
outside the lib/fdtdec.c.
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com> Suggested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Thu, 12 Dec 2024 22:33:36 +0000 (16:33 -0600)]
Gitlab: Remove some "rules:when: always" lines
In commit 399f739be6b2 ("CI: allow jobs to be run in merge requests") we
added "rules:when: always" to many stages of the pipeline to allow for merge
requests to trigger a run. However based on current Gitlab
documentation, we should still be triggered on merge requests without
this. Furthermore the way we have things written today we always run all
stages of the CI rather than failing out early on problems, which is not
always useful. Remove these as we should still be fine with merge
requests triggering a run.
Tom Rini [Thu, 12 Dec 2024 20:14:59 +0000 (14:14 -0600)]
Gitlab: Make test.py stage only depend on binman et al testsuite
Our Gitlab pipeline is currently broken up in to several stages. This
was done with the thought process of "we should test tools and if
they're good test emulated targets and if they're good test real
hardware and if they're good test the world". However, in terms of that
first stage it only really matters that binman, et al are still
functional. And for a few years now Gitlab has had a "needs" keyword
that lets you refine pipeline dependencies. Use this to perform the
minor optimization of having test.py only require that tool testing job.
This will become more useful later when we add long running testsuites
that we do not want to block later jobs.
Simon Glass [Fri, 20 Dec 2024 03:59:27 +0000 (20:59 -0700)]
sandbox: Adjust configuration to hang on panic()
It is annoying to have sandbox enter a boot loop when an assertion
fails. Hang instead, since then the error message is only printed once
and Ctrl-C can be used to quit, as per normal.
J. Neuschäfer [Fri, 20 Dec 2024 10:37:54 +0000 (11:37 +0100)]
gpio: mpc8xxx: Preserve pre-init state of outputs
The mpc8xxx_gpio driver contains a workaround for certain chips
where the previously written state of outputs cannot be read back
from the GPIO data (GPDAT) register (MPC8572/MPC8536). This workaround
consists of tracking the state of GPDAT in a "shadow register" (i.e. a
software variable). The shadow register is initialized to zero.
This results in a problem w.r.t. outputs that are configured to a
high (1) state before U-Boot runs, but not touched by U-Boot itself:
Due to the zero-initialization, these GPIOs end up being set to zero,
the first time that any other output is set.
To avoid such issues initialize the GPDAT shadow register to the value
previously held by any outputs, if possible. On MPC8572/MPC8536 this
should make no difference, i.e. the shadow register should be
initialized to zero on these chips.
This patch has been tested on a MPC8314E-based board.
Reviewed-by: Sinan Akman <sinan@writeme.com> Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
J. Neuschäfer [Fri, 20 Dec 2024 10:37:52 +0000 (11:37 +0100)]
powerpc: mpc83xx: Allow including initreg.h into multiple files
Globals defined in headers can result in multiple-definition errors
while linking, if they are visible beyond the current translation unit.
This hasn't been a problem for initreg.h so far, but would become a
problem in the next patch, where I use a constant from initreg.h in a
second C file.
Reviewed-by: Sinan Akman <sinan@writeme.com> Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Tom Rini [Mon, 30 Dec 2024 21:55:11 +0000 (15:55 -0600)]
Merge patch series "powerpc: Fix and enforce distinction between immediates and registers"
J. Neuschäfer <j.ne@posteo.net> says:
This patchset changes the definition r0 etc. to %r0, so that the
assembler can check that registers are only used where expected, and
fixes the fallout.
J. Neuschäfer [Thu, 12 Dec 2024 17:05:47 +0000 (18:05 +0100)]
powerpc: Introduce and enforce assembler checks on GPR usage
PowerPC general-purpose registers are historically specified as plain
numbers (0-31), which makes them hard to distinguish from immediates.
For this reason, include/ppc_asm.tmpl defines aliases named r0-r31.
This can still lead to uncaught mistakes if a register is used in place
of a number.
Instead of (e.g.) 5 use %r5, which will result in an assembler warning
if used as a number. Turn these warnings into errors by passing
`--fatal-warnings` to the assembler.
I verified with gazerbeam_defconfig (MPC83xx) and qemu-ppce500_defconfig
(MPC85xx) that this patch results in the same machine code.
J. Neuschäfer [Thu, 12 Dec 2024 17:05:46 +0000 (18:05 +0100)]
powerpc: Fix 0 vs. r0 confusion in X/D-form instructions
Instructions such as dcbi are in the X-form; they have RA and RB fields
and the effective address (EA) is computed as (RA|0)+(RB). In words,
this means that if RA is zero, the left-hand side of the addition is
zero, otherwise the corresponding GPR is used. r0 can never be used on
the left-hand side of a X-form instruction.
For D-form instructions such as addis, the Power ISA illustrates this in
the instruction pseudo-code:
if RA = 0 then RT <- EXTS(SI || 0x0000)
else RT <- (RA) + EXIS(SI || 0x0000)
In all of these cases, RA=0 indicates the value zero, not register r0.
I verified with gazerbeam_defconfig (MPC83xx) and qemu-ppce500_defconfig
(MPC85xx) that this patch results in the same machine code.
The LMB subsystem was used opportunistically for a number of years.
A while back Sughosh merged it with the EFI subsystem in order to have a
common allocator and avoid subsystems overwriting memory they shouldn't.
This is an initial cleanup of all the crud we gathered over the years.
There's no functional change expected from the patches as they just cleanup
some abstraction functions and rename a few variables to make more
sense.
I plan to make even bigger changes -- e.g I don't see the point of
having *_alloc() and *_reserve() versions of the functions since they
do the same thing and just cause confusion. lmb_alloc_addr_flags()
returning the base address on success makes little sense since we
already *request* the address on the function arguments, etc.
Since this patchset grew enough already, I'd like to get it in
before more refactoring happens.
It's worth noting that although some patches slightly increase the code
size due to an extra flags argument being carried around, the final
result is eventually smaller.
Ilias Apalodimas [Wed, 18 Dec 2024 07:02:37 +0000 (09:02 +0200)]
lmb: Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()
lmb_alloc_addr_flags() is a wrapper for _lmb_alloc_addr() and it's the
only function using it. Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()
and remove the wrapper.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Wed, 18 Dec 2024 07:02:36 +0000 (09:02 +0200)]
lmb: Remove lmb_alloc_base_flags()
lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE.
There's not much we gain from this abstraction, so let's remove the
former add the flags argument to lmb_alloc_base() and make the code
a bit easier to follow.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Wed, 18 Dec 2024 07:02:35 +0000 (09:02 +0200)]
lmb: Remove lmb_alloc_addr_flags()
lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE
There's not much we gain from this abstraction, so let's remove the
latter, add a flags argument to lmb_alloc_addr() and make the code a
bit easier to follow.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Wed, 18 Dec 2024 07:02:33 +0000 (09:02 +0200)]
lmb: Rename free_mem to available_mem
free_mem is a misnomer. We never update it with the free memory for
LMB. Instead, it describes all available memory and is checked against
used_mem to decide whether an area is free or not.
So let's rename this field to better match its usage.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Wed, 18 Dec 2024 07:02:32 +0000 (09:02 +0200)]
lmb: Remove lmb_reserve_flags()
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Wed, 18 Dec 2024 07:02:31 +0000 (09:02 +0200)]
lmb: Move enum lmb_flags to a u32
LMB flags is not an enum anymore. It's currently used as a bitmask
in various places of our code. So make it a u32 which is more
appropriate when dealing with masks.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tom Rini [Mon, 30 Dec 2024 19:20:33 +0000 (13:20 -0600)]
Merge patch series "lmb: Improve style"
Sam Protsenko <semen.protsenko@linaro.org> says:
Cleanup the LMB code a bit, after fixing the false positive error
messages. No functional change. This series depends on [1] (which is
"lmb: Fix reserving the same region multiple times").
Sam Protsenko [Wed, 11 Dec 2024 02:25:50 +0000 (20:25 -0600)]
lmb: Improve kernel-doc comments
Fix warnings from kernel-doc script. Improve and unify overall style of
kernel-doc comments in lmb source files. Move all kernel-doc comments
for public functions into the header, as recommended in U-Boot
documentation [1]:
Non-trivial functions should have a comment which describes what
they do. If it is an exported function, put the comment in the
header file so the API is in one place. If it is a static function,
put it in the C file.
This also takes care of existing duplication. While at it, do a bit of
cosmetic cleanups as well.
No functional change.
[1] doc/develop/codingstyle.rst
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Sam Protsenko [Wed, 11 Dec 2024 02:25:47 +0000 (20:25 -0600)]
lmb: Fix flags data type in lmb_add_region_flags()
rgnflags variable in lmb_add_region_flags() has incorrect type: it's
declared as phys_size_t when it should be enum lmb_flags. That
copy-paste mistake was firstly introduced in commit 59c0ea5df33f ("lmb:
Add support of flags for no-map properties"), and then copied further
into commit ed17a33fed29 ("lmb: make LMB memory map persistent and
global"). Fix it by using the correct type to match struct lmb_region
field.