| Age | Commit message (Collapse) | Author |
|---|
|
The efi_reinstall_protocol_interface() function is a UEFI function;
make sure to call it from within U-Boot using the EFI_CALL() macro.
This fixes the following assertion:
lib/efi_loader/efi_boottime.c:3752: efi_reinstall_protocol_interface: Assertion `__efi_entry_check()' failed.
To reproduce the issue, define LOG_DEBUG in lib/efi_loader/efi_boottime.c
and build u-boot for your platform. Then, boot the U-Boot helloworld.efi
application over the network. Example commands (adjust the URL and boot
entry number):
=> efidebug boot add -u 0 net http://10.0.2.2:8000/helloworld.efi
=> efidebug boot order 0
=> bootefi bootmgr
Fixes: dd5d82a59995 ("efi_loader: efi_net: Add device path cache")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Adriano Cordova <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When adding a new EFI Debug Image Info entry, we allocate memory for a new
EFI Debug Image Info Normal structure and we add a new entry into the EFI
Debug Image Info Table, which is in fact just a pointer to the allocated
structure.
However, when allocating memory for the new structure we allocate memory
for the wrong type, leading to allocating memory for just a pointer instead
of the desired structure.
Fix the type used during allocation.
Fixes: 146546138af5 ("efi: add EFI_DEBUG_IMAGE_INFO for debug")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Ying-Chun Liu (PaulLiu) <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Change the EFI variable load message from log_err() to log_info() with
neutral wording. The previous "Failed to load" message caused customer
confusion as it appeared to indicate an error condition.
The efi_var_from_file() function deliberately returns EFI_SUCCESS in
this case to allow the boot process to continue normally. This is
documented in the function's comment block but was not reflected in
the log message level or content.
The message now uses informational wording to reflect that this is
normal behavior when the ubootefi.var file does not yet exist.
Signed-off-by: Pranav Tilak <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The efi_exit() function frees the loaded image memory by calling
efi_delete_image(). However, when CONFIG_EFI_TCG2_PROTOCOL is enabled, the
image_obj->image_type structure member is accessed after the memory has
been freed.
Fix this by performing the tcg2 measurement before the image deletion.
Fixes: 8fc4e0b4273a ("efi_loader: add boot variable measurement")
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Masahisa Kojima <[email protected]>
Acked-by: Masahisa Kojima <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
sprintf will add a trailing \0 so manually adding a trailing \0 will
result in an extra unaccounted for character being written. This
overwrote the first byte of the following allocation block resulting in
unexpected behavior.
This was found by Running 'pxe get' with no available file resulting in
multiple attempts, using the default algorithm, to attempt to find a file.
Eventually there would be a failed assert when free() was called.
Failing the assert would result in a system reset.
Fixes: 27d7ccda94fa ("net: lwip: tftp: add support of blksize option to client")
Reported-by: Michal Simek <[email protected]>
Tested-by: Michal Simek <[email protected]>
Signed-off-by: Andrew Goodbody <[email protected]>
Tested-by: Tom Rini <[email protected]> # Pine64+
Reviewed-by: Jerome Forissier <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Make crypt_compare() accessible from board-specific code
by removing its dependency on the autoboot feature.
Signed-off-by: Tomas Paukrt <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Tom Rini <[email protected]> says:
A long while ago, Darek reported that our copy of the LZMA SDK library
is quite old and so vulnerable to at least one possible security issue
he found that was fixed upstream.
This does a few things. First, we introduce a Kconfig option
to enable LZMA's size reduction option, and enable it on
gardena-smart-gateway-mt7688. This is not critical at the start, but is
as we move forward. Next, we move all the way from version 9.20 of the
LZMA SDK to version 25.01. The few deviations from upstream are the
changes we've already made to the files and are documented in our
history. Finally, we add SPDX tags to the code we've imported from the
LZMA SDK (and upstream has been asked if they're interested in this).
Link: https://lore.kernel.org/u-boot/CAC7rXdTb5u5pzP-mr_+pddCxzfcO8Vm_t-=_+5wxRitMjy6-JA@mail.gmail.com/
Link: https://lore.kernel.org/r/[email protected]
|
|
After consulting https://spdx.org/licenses/ this code should be tagged
with the LZMA-SDK-9.22 identifer, so add them.
Signed-off-by: Tom Rini <[email protected]>
|
|
Currently, we have a copy of the LZMA SDK code, version 9.20, with small
updates. The original import of the LZMA SDK included a script to update the
library. This is no longer possible, due to important local changes, so
remove it. We also remove a number of extra text files that should be
unchanged from upstream, but provide no direct value to the project.
Instead, have the help text for LZMA note that this comes from the LZMA
SDK.
Next, we move our code up to the current release, 25.01. There are a
number of new header files, and some performance improvements made to
the code, at the cost of between 2 to 3 kilobytes in binary size. As
there is now a Kconfig option to disable this and retain similar speed
to what we have currently, the default option is to make this trade-off.
Our changes to the code around calling schedule() to avoid the watchdog
being triggered are kept. We add __UBOOT__ guards in two places to
prevent conflict with our own usage of these words on MIPS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Currently, our LZMA library has an option for optimizing for size,
rather than speed. It is a minimal savings today, and has not been worth
enabling. As this will change in the near future, add options now to
allow disabling it in full U-Boot or in SPL, and enable these on
gardena-smart-gateway-mt7688 which is very close to the size limit
today.
Reviewed-by: Stefan Roese <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Our last sync with the kernel was 5.1.
We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.
This is an attempt to sync up Makefiles to 6.1.
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call for the bump to 5.1,
so we are following the same guidelines here.
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>a #rebased on -next
|
|
Assigning a single variable to section __efi_runtime_date while the rest of
the test is in the boottime section does not make much sense.
As we do not set a virtual address map here, we don't need a runtime
section.
Update the variables at runtime test.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The EFI spec in §8.5.5 says
"The directory \EFI\UpdateCapsule is checked for capsules only within
the EFI system partition on the device specified in the active boot
option determine by reference to BootNext variable or BootOrder variable
processing."
Automatically generated boot options don't point to the ESP, they point to
the disk itself and find_handle() won't match when searching for an ESP
during a capsule update.
This happens because find_handle() only matches device paths that are
shorter or equal to the device path passed as an argument.
Since the EFI spec allows it we want to allow capsule updates, when the
boot option points to a disk, but that disk contains an ESP with a
\EFI\UpdateCapsule directory.
So, let's change device_is_present_and_system_part() and check if the
supplied device path contains an ESP. If it does return the handle of
the device. Otherwise, iterate over child devices and return the handle
of the first child that contains an ESP.
The returned handle can then be reused later. Rather than calling
efi_fs_from_path(), we can simply look up the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
on the discovered handle, avoiding the need to re-parse device paths.
Reported-by: Balaji Selvanathan <[email protected]>
Reported-by: John Toomey <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Check that only a file system installed on a handle for the
device-path node immediately preceding the file path node is
used for LoadImage().
LoadImage() ends up invoking efi_dp_find_obj(). This test helped to
demonstrate an issue in a suggested patch to change that function.
The test can be run with:
setenv efi_selftest load image from file
bootefi selftest
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
|
|
constants"
Quentin Schulz <[email protected]> says:
This does a bit of "cleanup" by reusing constants for some FIT
properties instead of having the same string in multiple places.
Additionally, this adds a new constant for the compatible property in
FIT configuration nodes[1] which is useful for FIT images with multiple
FIT configuration nodes to support multiple devices in the same blob.
U-Boot will try to figure out which node to select based on that
compatible[2].
However, if this property is missing (and the first blob in the fdt
property of the configuration node is uncompressed), the compatible from
the root node of the associated kernel FDT will be used for the
autoselection mechanism. For now, I only print the property if it
exists, but maybe it'd make sense to expose the fallback one if it's
missing. I guess we can implement that later on if desired.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Link: https://lore.kernel.org/r/[email protected]
|
|
Some FIT image properties have their string represented in
include/image.h via constants. FIT_ALGO_PROP does exist and would fit the
bill so let's use it instead of using a hardcoded string.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Add support for translating the EFI_PARTITION_INFO_PROTOCOL_GUID
to a text.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
into next
CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/28674
- riscv: Implement private GCC library
- mpfs: Add MPFS CPU Implementation
- andes: Stop disabling device tree relocation and some minor fixes
- sifive: Stop disabling device tree relocation
- starfive: Cleanup size types and typos
|
|
Prepare v2026.01-rc4
|
|
The following functions are provided:
Count leading zero bits
* int __clzsi2 (unsigned int a)
* int __clzdi2 (unsigned long a)
* int __clzti2 (unsigned long long a)
Count trailing zero bits
* int __ctzsi2 (unsigned int a)
* int __ctzdi2 (unsigned long a)
* int __ctzti2 (unsigned long long a)
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
get_dp_device() is used to derive the device path from a boot variable.
However, if the last efi_get_variable_int() call fails, we return an
error without freeing 'buf'.
There's no need to call efi_get_variable_int() for variables we don't
know the size since we have the efi_get_var() wrapper.
Replace that in the two instances we use it. The first one will also
fix the memory leak.
A nice sideeffect is that the code size is also reduced, since we are
re-using functions instead of open coding them
$~ bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 1/2 up/down: 6/-196 (-190)
Function old new delta
version_string 70 76 +6
efi_launch_capsules 2288 2196 -92
get_dp_device 244 140 -104
Total: Before=1222331, After=1222141, chg -0.02%
Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Heiko Schocher <[email protected]> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/[email protected]
|
|
add sm3 256 hash support, so TPM2 chips which report
5 pcrs with sm3 hash do not fail with:
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
Signed-off-by: Heiko Schocher <[email protected]>
|
|
add the U-Boot specific parts for the SM3 hash
implementation:
Signed-off-by: Heiko Schocher <[email protected]>
|
|
Implement SM3_256 Hash algorithm, based on
linux commit f83a4f2a4d8c: ("Merge tag 'erofs-for-6.17-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs")
Therefore add the needed parts from linux.
Signed-off-by: Heiko Schocher <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Prepare v2026.01-rc3
|
|
Use global st_boottime and st_runtime.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use global st_boottime and st_runtime.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use global st_runtime.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use global st_boottime and st_runtime.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use global st_runtime.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use global st_runtime.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Save the address of the EFI runtime as a global variable.
This allows to simplify the setup of tests.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
reserved-memory nodes
I've spent time trying to figure out why my board (Rockchip PX30-based)
suddenly boot loops when running a specific program in Linux userspace
after working on a U-Boot upgrade. I actually inadvertently had the TEE
environment variable set for a device which doesn't actually need to run
any TEE OS (so had OPTEE_LIB disabled).
It is currently possible to build an image with an OP-TEE OS (via the
TEE environment variable) without OPTEE_LIB. U-Boot will happily load
the TEE OS and the next OS (e.g. the Linux kernel).
This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to
the reserved-memory FDT node for the memory regions it just reserved for
itself. This updated FDT is then passed to U-Boot proper which should
know better not to use memory from there. The actual issue is that
without OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy
those nodes over to the next OS's FDT before starting it. This results
in the next OS's (e.g. Linux kernel) to not be aware of reserved memory,
incurring random crashes or device reboots when it tries to access
secure reserved memory area.
On Rockchip, the U-Boot FIT image which contains both the TEE OS and
U-Boot proper is generated by binman. Unfortunately, binman doesn't seem
to have access to Kconfig symbols (grep CONFIG_ doesn't return anything
meaningful and binman is either configured through FDT nodes or via CLI
arguments, c.f. cmd_binman in the root Makefile) so we cannot try to be
smart and guide the user to the correct Kconfig option to select if TEE
is set. We could add a property based on the presence of OPTEE_LIB in
rockchip-u-boot.dtsi for example and have a custom message based on
that, the issue is that I assume all FDT-based platforms do actually
need to do this dance, and not only Rockchip.
Another option could be to add a CLI argument to binman through which
we would pass the state of OPTEE_LIB and error out the build in that
case, but that feels like opening the door to other various dirty hacks.
Another option is to propagate the TEE environment variable to the
preprocessor of the FDT (via dtc_cpp_flags) and then we can do
#if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB)
#error "CONFIG_OPTEE_LIB must be enabled!"
#endif
but we have the same issue as above, it is then Rockchip-specific and
doesn't feel right to me.
Yet another option is to remove the @tee-SEQ node from the binman FIT
description when OPTEE_LIB isn't set but then we would lose the
following nice message when no TEE is provided:
Image 'simple-bin' is missing optional external blobs but is still functional: tee-os
and even worse, build without any TEE OS even though we could provide
one via the TEE environment variable.
Finally, another option could be to move this hack under
arch/arm/mach-rockchip/Kconfig to make it Rockchip-specific or add a
depends on ARCH_ROCKCHIP. However OP-TEE OS on Aarch32 Rockchip boards
doesn't actually need any of that if SPL_OPTEE_IMAGE is set because
arch/arm/mach-rockchip/sdram.c then marks some hardcoded memory regions
in RAM as holes in DRAM, which has the same effect as reserved memory
regions I guess. I assume other platforms may use something different,
so it may be casting too wide of a net.
This commit is what I could come up with as a stopgap measure to avoid
building images that simply cannot reliably work and fail randomly.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Memset() must return a pointer to the start of the updated memory block.
Fixes: 476476e73b14 ("efi: Add support for loading U-Boot through an EFI stub")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Remove duplicate #include.
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
%s/eventfor/event for/
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Convert function comments in efi_selftest_console.c to match
Sphinx style.
Correct function name in print_uuid() comment.
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Quentin Schulz <[email protected]> says:
While historically signature verification is mostly done for FIT such
FIT_SIGNATURE dependency for signature algorithm makes sense, it isn't
the only kind of file we can verify signatures of. It can also be done
manually with rsa_verify_hash() with an embedded public key.
Considering the impacted code is guarded by RSA_VERIFY, let's make the
symbol depend on that otherwise selecting it without RSA_VERIFY won't do
anything. The FIT_SIGNATURE dependency wasn't also enough before as it
only implied RSA_VERIFY.
Then, simply relocate the RSA SSA PSS padding with the other RSA symbols
in lib/rsa instead of in boot/ and rename it to remove the mention to
FIT.
Finally, add the PSS padding wherever PKCS1.5 padding is specified as
one or the other can be used.
Link: https://lore.kernel.org/r/[email protected]
|
|
While the verification step originally only supported PKCS1.5 as padding
algorithm for the signature, it was later extended to add support for
PSS but the doxygen doc wasn't updated to reflect that so let's fix
that oversight.
Fixes: 061daa0b61f0 ("rsa: add support of padding pss")
Signed-off-by: Quentin Schulz <[email protected]>
|
|
This renames FIT_RSASSA_PSS symbols to drop the FIT_ prefix to avoid
potential confusion since there's nothing FIT specific to those symbols.
It also isn't really related to booting, so boot/Kconfig is an odd place
for them to live. Since they make sense only in relation with RSA,
simply move them to lib/rsa where it makes more sense for them to
reside.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-01-rc2
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28208
Documentation:
* bootstd: Describe environment variable extension_overlay_addr
environment and remove extension support from TODO list
EFI:
* Correct the detection of the video mode in the EFI payload app:
- Use struct efi_gop_mode_info in the definition of struct
efi_entry_gopmode.
- In function get_mode_from_entry() use the correct type for the video
mode structure.
* Use a valid error code as return value in efi_store_memory_map().
* Avoid a memory leak for the variable name in efi_bl_create_block_device().
* Correct the code indentation in efi_uc_stop().
* Correct the description of struct efi_priv.
* Fix typos in code comments.
Other:
* qfw: Add more fields and a heading to qfw list
* Fix the support for ACPI pass-through on ARM and RISC-V:
Avoid zeroing out the XSDT address
* test: provide unit test for 'acpi list' command
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmkNj/kACgkQxIHbvCwF
# GsS8NQ/6Aj+Z54HJTIEfoXssvElLr5ATactrCxszq42i/yy6dLqa2Ym1afG6w1XS
# 1ZbCeU/bCXFke5Tsz+x89gEfckUm83oTwngwcID0WR1qn8mWjwR7tM5MuORq8NxU
# 7NwLuFs9O/QZihagKdz6hv1/Y+cBwiAYLY16EYVSuUlbLaKQo3QvxwWkqG3jdKWV
# Rm58/PolU+2h04MBwP0SxSduX4OyRF/tMOGjf5RGLyqCyj8kIgdu7PvUAPMM+Gps
# KemL59V0Bdv8hlF4JknmPz+idtZg2nHIDdNrBZvoxwzwGQeRZ1YXAMruRxZXqDYL
# tiuDp6HMv/GfIIGkz14tJtJMdboaAybAnluPWGalx8JQJqJzEPww0R+9s4KKQeWL
# mHgRyl6PxVV9p19f79Qq6q6ETwrFDX0YH3pdrGUk3DBa3lDt0UsEAnuW4FvaJ8tx
# 3PMrjKAxpxocT0hglsMVnptnfvDEigMsjwH/TWrau83mY+juxFQLjm+U4vye+qCa
# 4zXjjLas18+eRcrv2KxU7teakyi1Jp+WbqHq37L26YcQMaLq/RkBc0bTrsreKKLu
# jprYFpvc7EJpH2Fd1XWaZ2EnxXcVSJSvrY/iwRQqb6wbwQ6XGtMvSh3IFY8IzAoh
# N2Pj78oaYqyL1q/TftuZWhEHo3a0M/HfM4D+oMSHzJtWCb0wZHE=
# =OGcS
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 07 Nov 2025 12:21:45 AM CST
# gpg: using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4
# gpg: Good signature from "Heinrich Schuchardt <[email protected]>" [unknown]
# gpg: aka "[jpeg image of size 1389]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4
|
|
Signed-off-by: Quentin Schulz <[email protected]>
|
|
%s/mange/manage/
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
blk_create_devicef() uses a copy of parameter name.
We can use a local variable.
Reviewed-by: Bin Meng <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
%s/to be write/to write/
Reviewed-by: Bin Meng <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Correct indentation.
Reviewed-by: Bin Meng <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
