From: Lukas Funke
This commit extends the flags-variable with ranges for environment
variables. The range is appended to the variable flags using
the '@'-character. A range can be decimal (min/max), bitmask or regular
expression (64 byte).
Value ranges for variables can be used t
From: Lukas Funke
This series extends the flags-variable with ranges for environment
variables. The range is appended to the variable flags using
the '@'-character. A range can be decimal (min/max), bitmask or regular
expression (64 byte).
Value ranges for variables can be used t
From: Lukas Funke
tpm_tis_wait_init() is using the 'chip->timeout_b' field which is
initialized in tpm_tis_init(). However, the init-function is called
*after* tpm_tis_wait_init() introducing an uninitalized field access.
This series/commit fixes the issue.
Changes
From: Lukas Funke
tpm_tis_wait_init() is using the 'chip->timeout_b' field which is
initialized in tpm_tis_init(). However, the init-function is called
*after* tpm_tis_wait_init() introducing an uninitalized field access.
This commit switches both routines.
Signed-off-by: Lukas Fu
From: Lukas Funke
tpm_tis_wait_init() is using the 'chip->timeout_b' field which is
initialized in tpm_tis_init(). However, the init-function is called
*after* tpm_tis_wait_init() introducing an uninitalized field access.
This commit switches both routines.
Signed-off-by
From: Lukas Funke
tpm_tis_wait_init() is using the 'chip->timeout_b' field which is
initialized in tpm_tis_init(). However, the init-function is called
*after* tpm_tis_wait_init() introducing an uninitalized field access.
This series/commit fixes the issue.
Lukas Funke (1)
Hi Quentin,
On 02.07.2024 15:05, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 2:58 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This series enables U-Boot to import
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This series enables U-Boot to import environment variables from the
selectd FIT configuration. One use-case is that the overall build process
From: Lukas Funke
Add test which adds environment variables to the FIT configuration node
and checks whether they are exported to the runtime environment.
Signed-off-by: Lukas Funke
---
configs/sandbox_defconfig | 1 +
test/py/tests/test_fit.py | 45
From: Lukas Funke
Add function which reads properties from FIT conf node prefixed with
"env,". Import property name (without 'env,') and it's value as
runtime environment variables.
Note: this only works with string properties
Example:
configurations {
From: Lukas Funke
This series enables U-Boot to import environment variables from the
selectd FIT configuration. One use-case is that the overall build process
enriches the FIT configuration node with dm-verity information which
should be injected into the kernel commandline. U-Boot will then
From: Lukas Funke
This series enables the CPU reset in the SPL for ZynqMP based platforms.
This only works if CONFIG_SYSRESET is disabled. This is usually the
case since the the regular sysreset requires bl31 firmware to be loaded
in order to hand the sysreset over to PMU firmware. In SPL we
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
Changes in v3:
- Use 'ZYNQMP_PM_RESET_SOFT' directly
- Add comment on what
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
Note: Accessing eFuses requires eFuse access to be enabled in the
underlying PMU firmware.
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_zynqmp.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/soc
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_versal.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/soc_xilinx_versal.c b
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_versal_net.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc
From: Lukas Funke
Enable CMD_FUSE and ZYNQMP_EFUSE in order to be able to write
ZyqnMP eFuses from within the bootloader.
Signed-off-by: Lukas Funke
---
(no changes since v1)
configs/xilinx_zynqmp_kria_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs
From: Lukas Funke
Enable CMD_FUSE and ZYNQMP_EFUSE in order to be able to write
ZyqnMP eFuses from within the bootloader for Kria SoM.
Signed-off-by: Lukas Funke
---
(no changes since v1)
configs/xilinx_zynqmp_virt_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs
From: Lukas Funke
This series adds a driver to read and write ZynqMP eFuses [1]. The
driver can be accessed by the 'fuse read' and 'fuse write' commands
Example:
=> fuse read 0 0xc 3
Reading bank 0:
Word 0x000c: 3cb16685 013af244 4000
Note: Accessing eFuses r
From: Lukas Funke
This series enables the CPU reset in the SPL for ZynqMP based platforms.
This only works if CONFIG_SYSRESET is disabled. This is usually the
case since the the regular sysreset requires bl31 firmware to be loaded
in order to hand the sysreset over to PMU firmware. In SPL we
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
Changes in v2:
- Drop 2/2 since reworking ZYNQMP_FIRMWARE dependency is out-of-scope
board
On 03.06.2024 17:08, Michal Simek wrote:
On 6/3/24 16:50, Lukas Funke wrote:
On 03.06.2024 16:32, Michal Simek wrote:
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires
On 03.06.2024 16:32, Michal Simek wrote:
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
From: Lukas Funke
In order to make CONFIG_IS_ENABLED() work with 'ZYNQMP_FIRMWARE'
introduce an additional Kconfig 'SPL_ZYNQMP_FIRMWARE' which is selected
if and only if ZYNQMP_FIRMWARE is enabled. Driver are adapted such
that they build with and without the config being
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board
From: Lukas Funke
This series enables the CPU reset in the SPL for ZynqMP based platforms.
This only works if CONFIG_SYSRESET is disabled. This is usually the
case since the the regular sysreset requires bl31 firmware to be loaded
in order to hand the sysreset over to PMU firmware. In SPL we
On 29.05.2024 16:40, Michal Simek wrote:
On 5/15/24 14:41, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by
katesh
Cc: Stefan Herbrechtsmeier ;
Ashok Reddy Soma ; Lukas Funke
; Jaehoon Chung
; Johan Jonker ; Peng Fan
; Simon Glass ; Tom Rini
Subject: Re: [RFC PATCH v1 1/1] mmc: zynq_sdhci: Only evaluate card-stable
signal if card was detected
On 4/24/24 10:23, lukas.funke-...@weidmueller.com wrote:
F
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff
From: Lukas Funke
This series adds a driver to read and write ZynqMP eFuses [1]. The
driver can be accessed by the 'fuse read' and 'fuse write' commands
Example:
=> fuse read 0 0xc 3
Reading bank 0:
Word 0x000c: 3cb16685 013af244 4000
Note: Accessing eFuses r
Hi Stefan,
On 15.05.2024 08:12, Stefan Roese wrote:
Hi Lukas,
On 5/14/24 16:04, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
drivers/misc/Kconfig| 8 ++
drivers/misc/Makefile | 1 +
drivers/misc
From: Lukas Funke
This series adds a driver to read and write ZynqMP eFuses [1]. The
driver can be accessed by the 'efuse_read' and 'efuse_write' subcommands
of the 'zynqmp' command.
Example:
=> zynqmp efuse_read 0xc 0xc
: 85 66 b1 32 43 f2 4a 02
From: Lukas Funke
Add subcommands to read/write eFuses using u-boot. The subcommands
through the 'zynqmp' command.
Example:
=> zynqmp efuse_read 0xc 0xc
: 85 36 b1 3c 34 f2 3b 01 00 00 00 40 .f.
---
board/xilinx/zynqmp
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/firmware
Hi Michal,
On 10.04.2024 09:06, Michal Simek wrote:
Hi,
On 4/8/24 14:59, Michal Simek wrote:
On 3/27/24 13:11, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Currently some vendors use spl_board_init() for their SoC
specific initialization. This prohibits board developers from
On 02.05.2024 08:57, Johannes Kirchmair - SKIDATA wrote:
Dear u-boot folks,
we are trying to share some information between u-boot and a Linux user space
tool. For this we place some information in a FRAM. This information is just
some numeric values, indicating some wanted behaviour. I though
On 24.04.2024 13:01, Heinrich Schuchardt wrote:
On 24.04.24 09:43, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Rename spl_soc_init() to spl_dram_init() because the generic function
name does not reflect what the function actually does. Also
spl_dram_init() is commonly used for
From: Lukas Funke
On ZynqMp there seems to be a dependency between the card-stable bit and
the card-detect bit. The card-stable bit is set *if and only if*
the card-detect bit was set before, indicating that the signal was
stable and reliable during card insertion.
If the card-detect bit is
From: Lukas Funke
On ZynqMp there seems to be a dependency between the card-stable bit and
the card-detect bit. The card-stable bit is set *if and only if*
the card-detect bit was set before, indicating that the signal was
stable and reliable during card insertion.
If the card-detect bit is
From: Lukas Funke
Rename spl_soc_init() to spl_dram_init() because the generic function
name does not reflect what the function actually does. Also
spl_dram_init() is commonly used for dram initialization and should be
called from board_init_f().
Signed-off-by: Lukas Funke
---
Changes in v3
From: Lukas Funke
Rename spl_soc_init() to spl_dram_init() because the generic function
name does not reflect what the function actually does. Also
spl_dram_init() is commonly used for dram initialization and should be
called from board_init_f().
Signed-off-by: Lukas Funke
---
(no changes
From: Lukas Funke
This patch series renames spl_soc_init() to spl_dram_init() since the
purpose of the function is to initialization the DRAM on sifive/starfive
boards. spl_dram_init() is a commonly used function for this purpose.
Changes in v3:
- Reorganize patches such that each patch can
From: Lukas Funke
Call spl_dram_init() since this is commonly used for dram initialization
in u-boot.
Signed-off-by: Lukas Funke
---
Changes in v2:
- capitalized acronym DRAM
board/starfive/visionfive2/spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board
From: Lukas Funke
Rename spl_soc_init() to spl_dram_init() because the generic function
name does not reflect what the function is actually doing. In addition
spl_dram_init() is commonly used for dram initialization and should
be called from board_init_f().
Signed-off-by: Lukas Funke
---
(no
From: Lukas Funke
Call spl_dram_init() since this is commonly used for DRAM initialization
in u-boot.
Signed-off-by: Lukas Funke
---
(no changes since v1)
board/sifive/unleashed/spl.c | 4 ++--
board/sifive/unmatched/spl.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff
From: Lukas Funke
This patch series renames spl_soc_init() to spl_dram_init() since the
purpose of the function is to initialization the DRAM on sifive/starfive
boards. spl_dram_init() is a commonly used function for this purpose.
Changes in v2:
- capitalized acronym DRAM
Lukas Funke (3
From: Lukas Funke
This patch series renames spl_soc_init() to spl_dram_init() since the
purpose of the function is to initialization the DRAM on sifive/starfive
boards. spl_dram_init() is a commonly used function for this purpose.
Lukas Funke (3):
arch: riscv: Rename spl_soc_init() to
From: Lukas Funke
Call spl_dram_init() since this is commonly used for dram initialization
in u-boot.
Signed-off-by: Lukas Funke
---
board/sifive/unleashed/spl.c | 4 ++--
board/sifive/unmatched/spl.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/sifive
From: Lukas Funke
Call spl_dram_init() since this is commonly used for dram initialization
in u-boot.
Signed-off-by: Lukas Funke
---
board/starfive/visionfive2/spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive
From: Lukas Funke
Rename spl_soc_init() to spl_dram_init() because the generic function
name does not reflect what the function is actually doing. In addition
spl_dram_init() is commonly used for dram initialization and should
be called from board_init_f().
Signed-off-by: Lukas Funke
: Lukas Funke
---
arch/arm/mach-zynq/cpu.c| 10 ++
arch/arm/mach-zynq/include/mach/sys_proto.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-zynq/cpu.c b/arch/arm/mach-zynq/cpu.c
index b8d413b69a..e6151bc21d 100644
--- a/arch/arm/mach-zynq/cpu.c
Herbrechtsmeier
Signed-off-by: Lukas Funke
---
arch/arm/mach-zynq/cpu.c| 19 +++
arch/arm/mach-zynq/include/mach/sys_proto.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-zynq/cpu.c b/arch/arm/mach-zynq/cpu.c
index 3d2866422e..b8d413b69a
From: Stefan Herbrechtsmeier
This commit adds a function to get/set the multiboot register. This
becomes handy in order to ensure a fresh bootimage search after reset.
Signed-off-by: Stefan Herbrechtsmeier
Signed-off-by: Lukas Funke
---
arch/arm/mach-zynq/cpu.c| 19
From: Lukas Funke
This series adds support to enable/disable/lock the jtag interface
from u-boot. This becomes handy if secure boot is used but debugging
should be poissible for non-productions builds.
The series also adds support to get/set the multiboot register in order
to ensure a freash
From: Lukas Funke
Some architectures use spl_board_init() in their SoC specific
implementation. Board developers should be able to add board specific
implementation via spl_board_init(). Hence, introduce a spl_soc_init()
method which is called right before spl_board_init() for SoC
specific
From: Lukas Funke
Rename spl_board_init() to spl_soc_init(). SoC specific
implementation should be separated from board specific implementation
in order to be extended by board developers.
Signed-off-by: Lukas Funke
---
Changes in v3:
- Rephrase Kconfig description and correct minor typo
From: Lukas Funke
Currently some vendors use spl_board_init() for their SoC
specific initialization. This prohibits board developers from adding
board init code using said function. This series introduces a new
function in order to separate SoC init code from board init code.
Changes in v3
From: Lukas Funke
Rename spl_board_init() to spl_soc_init(). SoC specific
implementation should be separated from board specific implementation
in order to be extended by board developers.
Signed-off-by: Lukas Funke
---
Changes in v2:
- Change spl_arch_init() to spl_soc_init()
arch/arm
From: Lukas Funke
Currently some vendors use spl_board_init() for their SoC
specific initialization. This prohibits board developers from adding
board init code using said function. This series introduces a new
function in order to separate SoC init code from board init code.
Changes in v2
From: Lukas Funke
Some architectures use spl_board_init() in their SoC specific
implementation. Board developers should be able to add board specific
implementation via spl_board_init(). Hence, introduce a spl_soc_init()
method which is called right before spl_board_init() for SoC
specific
, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Some architectures use spl_board_init() in their architecture specific
implementation. Board developers should be able to add board specific
implementation via spl_board_init(). Hence, introduce a spl_arch_init()
method which is called right
From: Lukas Funke
Some architectures use spl_board_init() in their architecture specific
implementation. Board developers should be able to add board specific
implementation via spl_board_init(). Hence, introduce a spl_arch_init()
method which is called right before spl_board_init() for
From: Lukas Funke
Rename spl_board_init() to spl_arch_init(). Architecture specific
implementation should be separated from board specific implementation
in order to be extended by board developers.
Signed-off-by: Lukas Funke
---
arch/arm/Kconfig | 4 ++--
arch/arm/mach-zynq/spl.c
From: Lukas Funke
Currently some architectures use spl_board_init() for their architecture
specific initialization. This prohibits board developers from adding
board init code using said function. This series introduces a new
function in order to separate arch init code from board init code
From: Lukas Funke
ZynqMP CG series devices only have two cpus. In this
case the interrupt-affinity property has to adapted, because
cpu3 and cpu4 are missing. By adding a label to the pmu fwnode the
interrupt-affinity can be adapted in a device specific DT.
Signed-off-by: Lukas Funke
---
arch
On 27.02.2024 09:45, Michal Simek wrote:
On 2/27/24 09:40, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Some zynqmp SoCs (the cg series) only have two cpus. Thus, for some
cases the cpu-affinity has to adapted, because cpu3 and cpu4 are
interrupt-affinity right?
Duh. Can you
From: Lukas Funke
Some zynqmp SoCs (the cg series) only have two cpus. Thus, for some
cases the cpu-affinity has to adapted, because cpu3 and cpu4 are
missing. By adding a label to the pmu fwnode the cpu affinity can
be adapted in a device specific dt.
Signed-off-by: Lukas Funke
---
arch/arm
and("setexpr fred gsub us is \"${fred}\"", 0));
+ ut_assertok(run_command("setexpr mary gsub us is \"${fred}\"", 0));
+ val = env_get("fred");
+ ut_asserteq_str("this is a test", val);
+ val = env_get("mary")
Hi Tom,
On 18.01.2024 21:22, Tom Rini wrote:
On Wed, Jan 10, 2024 at 10:10:33AM +0100, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
The commit enables vsprintf() to handle the '%pbl' format specifier
in order to print bitmaps and its derivatives such as cpumask and
n
From: Lukas Funke
Forward '%p' format specifier to the underlying format logic in order
to print pointers, especially bitmaps.
Signed-off-by: Lukas Funke
---
Changes in v3:
- Dereference pointer argument (i.e. *value) in the
'setexpr name fmt value' case. This is curren
From: Lukas Funke
Extend setexpr_get_arg() function in order to handle bitmaps with
length greater than 8 byte. If the bitmap is provided as hex string
the string is parsed into a bitmap.
Signed-off-by: Lukas Funke
---
(no changes since v1)
cmd/setexpr.c | 29
From: Lukas Funke
The commit enables vsprintf() to handle the '%pbl' format specifier
in order to print bitmaps and its derivatives such as cpumask and
nodemask [1]. This can be used to derive kernel boot parameters from
bitmaks such as 'isolcpu' or 'nohz_full' [2
From: Lukas Funke
Prefix the get_arg() function with 'setexpr_' in order to prepare
the removal of the static specifier. The prefix shall denote the origin
of the function.
Signed-off-by: Lukas Funke
---
(no changes since v1)
cmd/setexpr.c | 6 +++---
1 file changed, 3 insert
From: Lukas Funke
Promote 'setexpr_get_arg()' to a public function in order to use it
from the setexpr command and in the printf-internals.
Signed-off-by: Lukas Funke
---
(no changes since v1)
cmd/setexpr.c | 15 +--
include/command.h | 27
From: Lukas Funke
Add '%pbl' printf format specifier as descriped in [1].
[1] https://www.kernel.org/doc/Documentation/printk-formats.txt
Signed-off-by: Lukas Funke
---
Changes in v3:
- Remove '%bp' from documentation
- Give an example output in the documentation
doc/de
From: Lukas Funke
Add a 'hextobarray()' function which converts a hex string to it's
memory representation. This can be used to represent large integer
numbers or bitmasks which do not fit in a regular unsigned long value.
Signed-off-by: Lukas Funke
---
(no changes sinc
From: Lukas Funke
Add tests to test the bitmap format specifier. Test different bit
widths and access to memory by pointer.
Signed-off-by: Lukas Funke
---
(no changes since v1)
test/cmd/setexpr.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/test/cmd/setexpr.c
From: Lukas Funke
Add 'for_each_set_bitrange' (from Linux kernel) in order to iterate
over each set bitrange of a bitmap. This becomes handy if one wants
to generate a cpu list i.e. for isolcpu or nohz_full.
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
(no change
From: Lukas Funke
Correctly parse the field width from the format specifier. Before this
commit the field_width was simply ignored.
Signed-off-by: Lukas Funke
---
(no changes since v1)
cmd/printf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/printf.c b/cmd
From: Lukas Funke
This series enables the 'setexpr' command to print "cpu list"-like
bitmaps based on the printk format specifier [1].
One use-case is to pass cpu list [2] based kernel parameter like
'isolcpu', 'nohz_full', irq affinity or RCU related CP
From: Lukas Funke
Add generic 'find_next_zero_bit()' implementation in order to enable the
use of the 'for_each_set_bitrange' macro. The implementation is currently
missing for the sandbox-arch and using the function results in a linker
error. The implementation is
On 12.12.2023 14:09, Heinrich Schuchardt wrote:
On 12.12.23 12:56, Lukas Funke wrote:
On 12.12.2023 12:40, Heinrich Schuchardt wrote:
On 12.12.23 11:13, Heinrich Schuchardt wrote:
On 12.12.23 09:52, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This series enables the 'se
On 12.12.2023 12:40, Heinrich Schuchardt wrote:
On 12.12.23 11:13, Heinrich Schuchardt wrote:
On 12.12.23 09:52, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This series enables the 'setexpr' command to print "cpu list"-like
bitmaps based on the printk format
Hi Heinrich,
On 12.12.2023 11:13, Heinrich Schuchardt wrote:
On 12.12.23 09:52, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This series enables the 'setexpr' command to print "cpu list"-like
bitmaps based on the printk format specifier [1].
One use-case is
From: Lukas Funke
Forward '%p' format specifier to the underlying format logic in order
to print pointers, especially bitmaps.
Signed-off-by: Lukas Funke
---
(no changes since v1)
cmd/printf.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/cmd/
From: Lukas Funke
The commit enables vsprintf() to handle the '%*pb[l]' format specifier
in order to print bitmaps and its derivatives such as cpumask and
nodemask [1]. This can be used to derive kernel boot parameters from
bitmaks such as 'isolcpu' or 'n
From: Lukas Funke
Add '%*pb[l]' printf format specifier as descriped in [1].
[1] https://www.kernel.org/doc/Documentation/printk-formats.txt
Signed-off-by: Lukas Funke
---
(no changes since v1)
doc/develop/printf.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/d
From: Lukas Funke
Add test to test the bitmap format specifier
Signed-off-by: Lukas Funke
---
(no changes since v1)
test/cmd/setexpr.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/test/cmd/setexpr.c b/test/cmd/setexpr.c
index 312593e1e3..4e1c9e983b 100644
--- a/test/cmd
From: Lukas Funke
Add 'for_each_set_bitrange' (from Linux kernel) in order to iterate
over each set bitrange of a bitmap. This becomes handy if one wants
to generate a cpu list i.e. for isolcpu or nohz_full.
Signed-off-by: Lukas Funke
---
(no changes since v1)
include/linux/bi
From: Lukas Funke
This series enables the 'setexpr' command to print "cpu list"-like
bitmaps based on the printk format specifier [1].
One use-case is to pass cpu list [2] based kernel parameter like
'isolcpu', 'nohz_full', irq affinity or RCU related CP
From: Lukas Funke
Add generic 'find_next_zero_bit' implementation in order to enable the
use of the 'for_each_set_bitrange' macro. The implementation is currently
missing for the sandbox-arch and using the function results in a linker
error.
There are more efficient im
From: Lukas Funke
The commit enables vsprintf() to handle the '%*pb[l]' format specifier
in order to print bitmaps and its derivatives such as cpumask and
nodemask [1]. This can be used to derive kernel boot parameters from
bitmaks such as 'isolcpu' or 'n
From: Lukas Funke
Forward '%p' format specifier to the underlying format logic in order
to print pointers, especially bitmaps.
Signed-off-by: Lukas Funke
---
cmd/printf.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/cmd/printf.c b/cmd/prin
From: Lukas Funke
Add 'for_each_set_bitrange' (from Linux kernel) in order to iterate
over each set bitrange of a bitmap. This becomes handy if one wants
to generate a cpu list i.e. for isolcpu or nohz_full.
Signed-off-by: Lukas Funke
---
include/linux/bitmap.h | 7 +++
1 file
From: Lukas Funke
Add generic 'find_next_zero_bit' implementation in order to enable the
use of the 'for_each_set_bitrange' macro. The implementation is currently
missing for the sandbox-arch and using the function results in a linker
error.
There are more efficient im
1 - 100 of 151 matches
Mail list logo
