April 2024 - U-Boot

[PATCH 1/2] ARM: dts: stm32: add PWR regulators support on stm32mp131
by Marek Vasut 14 Jun '24

14 Jun '24

This patch adds STM32 PWR regulators DT support on stm32mp131. This requires TFA to clear RCC_SECCFGR, is disabled by default and can only be enabled on board DT level. Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Patrice Chotard <patrice.chotard(a)foss.st.com> Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Cc: Tom Rini <trini(a)konsulko.com> Cc: u-boot(a)dh-electronics.com Cc: u-boot(a)lists.denx.de Cc: uboot-stm32(a)st-md-mailman.stormreply.com --- arch/arm/dts/stm32mp131.dtsi | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi index 81d99a7582b..ad331b73d18 100644 --- a/arch/arm/dts/stm32mp131.dtsi +++ b/arch/arm/dts/stm32mp131.dtsi @@ -1092,6 +1092,30 @@ <&scmi_clk CK_SCMI_LSI>; }; + pwr_regulators: pwr@50001000 { + compatible = "st,stm32mp1,pwr-reg"; + reg = <0x50001000 0x10>; + status = "disabled"; + + reg11: reg11 { + regulator-name = "reg11"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + }; + + reg18: reg18 { + regulator-name = "reg18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + usb33: usb33 { + regulator-name = "usb33"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + }; + exti: interrupt-controller@5000d000 { compatible = "st,stm32mp13-exti", "syscon"; interrupt-controller; -- 2.43.0

2 7

[PATCH v2] stm32mp: Reserve OPTEE area in EFI memory map
by Patrice Chotard 14 Jun '24

14 Jun '24

Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory") memory region above ram_top is tagged in EFI memory map as EFI_BOOT_SERVICES_DATA. In case of STM32MP1/STM32MP13 platforms, above ram_top, there is one reserved-memory region tagged "no-map" dedicated to OP-TEE : _ addr=de000000 size=2000000 for stm32mp157x-dkx and stm32mp135f-dk _ addr=fe000000 size=2000000 for stm32mp157c-ev1 Before booting kernel, EFI memory map is first built, the OPTEE region is tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE is used. Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions() which try to add again the same OPTEE region (addr=de000000 size=2000000 in case of stm32mp157x-dkx / stm32mp135f-dk or addr=fe000000 size=2000000 in case for stm2mp157c-ev1) but now with LMB_NOMAP tag which produces the following error message : _ for stm32mp157x-dkx / stm32mp135f-dk : "ERROR: reserving fdt memory region failed (addr=de000000 size=2000000 flags=4)" _ for stm32mp157c-ev1 : "ERROR: reserving fdt memory region failed (addr=fe000000 size=2000000 flags=4)" To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark it as reserved. Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- Changes in v2: _ update commit message by adding information about memory area dedicated for OPTEE for various STM32MP1/STM32MP13 boards. arch/arm/mach-stm32mp/dram_init.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-stm32mp/dram_init.c index fb1208fc5d5..f67f54f2ae0 100644 --- a/arch/arm/mach-stm32mp/dram_init.c +++ b/arch/arm/mach-stm32mp/dram_init.c @@ -7,6 +7,7 @@ #include <common.h> #include <dm.h> +#include <efi_loader.h> #include <image.h> #include <init.h> #include <lmb.h> @@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size) return reg + size; } + +void efi_add_known_memory(void) +{ + if (IS_ENABLED(CONFIG_EFI_LOADER)) + /* + * Memory over ram_top is reserved to OPTEE. + * Declare to EFI only memory area below ram_top + */ + efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base, + EFI_CONVENTIONAL_MEMORY); +} -- 2.25.1

3 2

[PATCH v2 0/4] Generate capsules from config files
by Sughosh Ganu 11 Jun '24

11 Jun '24

Add support for generating capsules through a config file. Multiple capsules can be generated through a single invocation of the mkeficapsule tool, where the capsule parameters are fetched from the config file. The format of the config file pretty similar to the one used by the capsule generation tool in EDKII. The functionality is enabled on the sandbox variant and the EFI capsule update test is now configured to generate the capsules through a config file. The sandbox_flattree variant generates capsules through binman, thus covering both the paths. This is a rebased version of the earlier patch series that was sent to the mailing list [1]. That series was not getting merged as Simon had asked for generation of capsules as part of the sandbox platform build. Those patches have since been merged. Moreover, there has been adoption of the capsule generation logic by TI platforms as well, so that should address the concern which Tom had about it's usage. These patches are more of a step in the direction of adding support for generation of a multi-payload capsule. There has been a request for it's support for a platform [2]. [1] - https://lists.denx.de/pipermail/u-boot/2023-November/538223.html [2] - https://lists.denx.de/pipermail/u-boot/2024-March/548126.html Sughosh Ganu (4): tools: mkeficapsule: Add support for parsing capsule params from config file doc: Document capsule generation through a config file sandbox: capsule: Add a config file for generating capsules test: capsule: Generate capsules through config file configs/sandbox_defconfig | 2 + doc/develop/uefi/uefi.rst | 70 ++++ .../test_efi_capsule/capsule_gen_binman.dts | 2 + test/py/tests/test_efi_capsule/conftest.py | 7 + .../test_efi_capsule/sandbox_capsule_cfg.txt | 73 ++++ tools/Kconfig | 15 + tools/Makefile | 1 + tools/eficapsule.h | 114 ++++++ tools/mkeficapsule.c | 87 +++-- tools/mkeficapsule_parse.c | 352 ++++++++++++++++++ 10 files changed, 692 insertions(+), 31 deletions(-) create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt create mode 100644 tools/mkeficapsule_parse.c -- 2.34.1

3 9

Proposal: U-Boot memory management
by Simon Glass 11 Jun '24

11 Jun '24

Hi, This records my thoughts after a discussion with Ilias & Heinrich re memory allocation in U-Boot. 1. malloc() malloc() is used for programmatic memory allocation. It allows memory to be freed. It is not designed for very large allocations (e.g. a 10MB kernel or 100MB ramdisk). 2. lmb lmb is used for large blocks of memory, such as those needed for a kernel or ramdisk. Allocation is only transitory, for the purposes of loading some images and booting. If the boot fails, then all lmb allocations go away. lmb is set up by getting all available memory and then removing what is used by U-Boot (code, data, malloc() space, etc.) lmb reservations have a few flags so that areas of memory can be provided with attributes There are some corner cases...e.g. loading a file does an lmb allocation but only for the purpose of avoiding a file being loaded over U-Boot code/data. The allocation is dropped immediately after the file is loaded. Within the bootm command, or when using standard boot, this would be fairly easy to solve. Linux has renamed lmb to memblock. We should consider doing the same. 3. EFI EFI has its own memory-allocation tables. Like lmb, EFI is able to deal with large allocations. But via a 'pool' function it can also do smaller allocations similar to malloc(), although each one uses at least 4KB at present. EFI allocations do not go away when a boot fails. With EFI it is possible to add allocations post facto, in which case they are added to the allocation table just as if the memory was allocated with EFI to begin with. The EFI allocations and the lmb allocations use the same memory, so in principle could conflict. EFI allocations are sometimes used to allocate internal U-Boot data as well, if needed by the EFI app. For example, while efi_image_parse() uses malloc(), efi_var_mem.c uses EFI allocations since the code runs in the app context and may need to access the memory after U-Boot has exited. Also efi_smbios.c uses allocate_pages() and then adds a new mapping as well. EFI memory has attributes, including what the memory is used for (to some degree of granularity). See enum efi_memory_type and struct efi_mem_desc. In the latter there are also attribute flags - whether memory is cacheable, etc. EFI also has the x86 idea of 'conventional' memory, meaning (I believe) that below 4GB that isn't reserved for the hardware/system. This is meaningless, or at least confusing, on ARM systems. 4. reservations It is perhaps worth mentioning a fourth method of memory management, where U-Boot reserves chunks of memory before relocation (in board_init_f.c), e.g. for the framebuffer, U-Boot code, the malloc() region, etc. Problems —------- There are no urgent problems, but here are some things that could be improved: 1. EFI should attach most of its data structures to driver model. This work has started, with the partition support, but more effort would help. This would make it easier to see which memory is related to devices and which is separate. 2. Some drivers do EFI reservations today, whether EFI is used for booting or not (e.g. rockchip video rk_vop_probe()). 3. U-Boot doesn't really map arch-specific memory attributes (e.g. armv8's struct mm_region) to EFI ones. 4. EFI duplicates some code from bootm, some of which relates to memory allocation (e.g. FDT fixup). 5. EFI code is used even if EFI is never used to boot 6. EFI allocations can result in the same memory being used as has already been allocated by lmb. Users may load files which overwrite memory allocated by EFI. Lifetime -------- We have three different memory allocators with different purposes. Can we unify them a little? Within U-Boot: - malloc() space lives forever - lmb lives while setting out images for booting - EFI (mostly) lives while booting an EFI app In practice, EFI is set up early in U-Boot. Some of this is necessary, some not. EFI allocations stay around forever. This works OK since large allocations are normally not done in EFI, so memory isn't really consumed to any great degree by the boot process. What happens to EFI allocations if the app returns? They are still present, in case another app is run. This seems fine. API –-- Can we unify some APIs? It should be possible to use lmb for large EFI memory allocations, so long as they are only needed for booting. We effectively do this today, since EFI does not manage the arrangement of loaded images in memory. for the most part. It would not make sense to use EFI allocation to replace lmb and malloc(), of course. Could we use a common (lower-level) API for allocation, used by both lmb and EFI? They do have some similarities. However they have different lifetime constraints (EFI allocations are never dropped, unlikely lmb). ** Overall, it seems that the existence of memory allocation in boot-time services has created confusion. Memory allocation is muddled, with both U-Boot code and boot-time services calling the same memory allocator. This just has not been clearly thought out. Proposal —------- Here are some ideas: 1. For video, use the driver model API to locate the video regions, or block off the entire framebuffer memory, for all devices as a whole. Use efi_add_memory_map() 2. Add memory attributes to UCLASS_RAM and use them in EFI, mapping to the EFI_MEMORY_... attributes in struct efi_mem_desc. 3. Add all EFI reservations just before booting the app, as we do with devicetree fixup. With this model, malloc() and lmb are used for all allocation. Then efi_add_memory_map() is called for each region in turn just before booting. Memory attributes are dealt with above. The type (enum efi_memory_type) can be determined simply by the data structure stored in it, as is done today. For example, SMBIOS tables can use EFI_ACPI_RECLAIM_MEMORY. Very few types are used and EFI code understands the meaning of each. 4. Avoid setting up EFI memory at the start of U-Boot. Do it only when booting. This looks to require very little effort. 5. Avoid calling efi_allocate_pages() and efi_allocate_pool() outside boot-time services. This solves the problem 6. If memory is needed by an app, allocate it with malloc() and see 3. There are only two efi_allocate_pages() (smbios and efi_runtime). There are more calls of efi_allocate_pool(), but most of these seem easy to fix up. For example, efi_init_event_log() allocates a buffer, but this can be allocated in normal malloc() space or in a bloblist. 6. Don't worry too much about whether EFI will be used for booting. The cost is likely not that great: use bootstage to measure it as is done for driver model. Try to minmise the cost of its tables, particularly for execution time, but otherwise just rely on the ability to disable EFI_LOADER. – Regards, Simon

6 51

[PATCH v6 00/14] firmware: scmi: add SCMI base protocol support
by AKASHI Takahiro 10 Jun '24

10 Jun '24

This patch series allows users to access SCMI base protocol provided by SCMI server (platform). See SCMI specification document v3.2 beta[1] for more details about SCMI base protocol. What is currently not implemented is - SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism This feature won't be very useful in the current U-Boot environment. [1] https://developer.arm.com/documentation/den0056/e/?lang=en Test ==== The patch series was tested on the following platforms: * sandbox * qemu-arm64 with OPTEE as SCMI server * confirmed CI check (pull request #439) Prerequisite: ============= * This patch series is based on v2023.10. Patches: ======== Patch#1-#6: refactoring & bug fix Patch#7-#9,#11: Add SCMI base protocol driver Patch#10,#12-#13: Add SCMI base protocol device unit test Patch#14: add a protocol sanity check Change history: =============== v6 (Oct 11, 2023) * shuffle the order of patches to fix a bisect error (No change on the code) * drop scmi command which was intended to be used for debugging * add patch#8 (version check) v5 (sep 26, 2023) * fix a per_child_auto size (patch#1) * fix an existing bug (not using a protocol's channel) (patch#2-#4) v4 (Sep 12, 2023) * shuffle the patch order (patch#5,6 prior to patch#7) * several improvements/cleanup thanks to Etienne (Each commit message has more details.) v3 (Sep 8, 2023) * import patch#6 (protocol availability check) from my followup patch * fix an issue on ST board (reported by Etienne) (patch#1) * minor code improvements * fix various typos pointed out by Etienne * revise function descriptions/comments (Each commit message has more details.) v2 (Jul, 26, 2023) * refactor devm_scmi_of_get_channel()/process_msg(), removing uses of ops (patch#1) * use helper functions, removing uses of ops (patch#2,#9,#10) * add more descriptions in scmi command doc (patch#11) * remove 'scmi base' sub-command (patch#10,#12) v1 (Jun, 28, 2023) * initial release AKASHI Takahiro (14): scmi: refactor the code to hide a channel from devices firmware: scmi: use a protocol's own channel if assigned firmware: scmi: support dummy channels for sandbox agent firmware: scmi: move scmi_bind_protocols() backward firmware: scmi: framework for installing additional protocols test: dm: add protocol-specific channel test firmware: scmi: implement SCMI base protocol firmware: scmi: add a version check against base protocol firmware: scmi: fake base protocol commands on sandbox test: dm: simplify SCMI unit test on sandbox firmware: scmi: install base protocol to SCMI agent sandbox: remove SCMI base node definition from test.dts test: dm: add SCMI base protocol test firmware: scmi: add a check against availability of protocols arch/sandbox/dts/test.dts | 5 +- arch/sandbox/include/asm/scmi_test.h | 19 +- drivers/clk/clk_scmi.c | 27 +- drivers/firmware/scmi/Makefile | 1 + drivers/firmware/scmi/base.c | 664 +++++++++++++++++++++ drivers/firmware/scmi/mailbox_agent.c | 5 +- drivers/firmware/scmi/optee_agent.c | 5 +- drivers/firmware/scmi/sandbox-scmi_agent.c | 469 ++++++++++++++- drivers/firmware/scmi/scmi_agent-uclass.c | 412 +++++++++++-- drivers/firmware/scmi/smccc_agent.c | 5 +- drivers/power/regulator/scmi_regulator.c | 26 +- drivers/reset/reset-scmi.c | 19 +- include/dm/uclass-id.h | 1 + include/scmi_agent-uclass.h | 89 ++- include/scmi_agent.h | 29 +- include/scmi_protocols.h | 495 +++++++++++++++ test/dm/scmi.c | 195 ++++-- 17 files changed, 2262 insertions(+), 204 deletions(-) create mode 100644 drivers/firmware/scmi/base.c -- 2.34.1

5 19

[RFC PATCH v1 0/1] mmc: zynq_sdhci: Only evaluate card-stable signal if card was detected
by lukas.funke-oss＠weidmueller.com 31 May '24

31 May '24

From: Lukas Funke <lukas.funke(a)weidmueller.com> 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 *not* evaluated the corresponding check leads to a timeout indicating that the card-detect was not stable. There was another patch that tried to mitigate this behaviour: https://lore.kernel.org/u-boot/20230516142116.29996-1-stefan.herbrechtsmeie… However, the discussion stalled and the solution was not accepted. This patch introduces another way to deal with the observed behaviour. Lukas Funke (1): mmc: zynq_sdhci: Only evaluate card-stable signal if card was detected drivers/mmc/zynq_sdhci.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) -- 2.30.2

4 4

[PATCH v3 0/2] Introduce spl_soc_init() for SoC specific initialization
by lukas.funke-oss＠weidmueller.com 30 May '24

30 May '24

From: Lukas Funke <lukas.funke(a)weidmueller.com> 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: - Rephrase Kconfig description and correct minor typo Changes in v2: - Change spl_arch_init() to spl_soc_init() Lukas Funke (2): spl: Introduce SoC specific init function arm64: zynq(mp): Rename spl_board_init() to spl_soc_init() arch/arm/Kconfig | 4 ++-- arch/arm/mach-zynq/spl.c | 4 ++-- arch/arm/mach-zynqmp/spl.c | 4 ++-- common/spl/Kconfig | 7 +++++++ common/spl/spl.c | 3 +++ include/spl.h | 8 ++++++++ 6 files changed, 24 insertions(+), 6 deletions(-) -- 2.30.2

4 7

[PATCH v2 0/8] Add DFU, emmc and usb boot for TI am62x
by Sjoerd Simons 29 May '24

29 May '24

This series adds more boot sources for the TI am62x. For that the dts' are synced from the upstream ti-next git tree (to add usb nodes), some dwc3 glue is and finally the default configuration is tuned to add support for DFU and USB (host and gadget) Changes in v2: - Update dts sync to v6.3-rc5 - Switch dwc3 glue to a seperate driver rather then in dwc-generic - Minimize config changes to just DFU configuration - Only enable usb port 0 DFU in SPL - Create a seperate defconfig for R5 Sjoerd Simons (8): omap: timer: add ti,am654-timer compatibility arm: mach-k3: am62: Add timer0 id to the dev list arm: dts: k3-am62: Bump dtsi from linux arm: dts: k3-am625-sk: Enable emmc in SPL usb: dwc3: Add dwc3 glue driver for am62 configs: am62: Add configs for enabling USB in U-Boot arm: dts: k3-am625-sk: Enable usb ports in u-boot configs: am62x_evm_*: Enable USB and DFU support arch/arm/dts/k3-am62-main.dtsi | 259 +++++++++++++++++++++++--- arch/arm/dts/k3-am62-mcu.dtsi | 49 +++++ arch/arm/dts/k3-am62-wakeup.dtsi | 4 +- arch/arm/dts/k3-am625-r5-sk.dts | 2 +- arch/arm/dts/k3-am625-sk-u-boot.dtsi | 27 ++- arch/arm/dts/k3-am625-sk.dts | 95 +++++----- arch/arm/dts/k3-am625.dtsi | 52 ++++++ arch/arm/mach-k3/am62x/dev-data.c | 1 + configs/am62x_evm_a53_defconfig | 35 +++- configs/am62x_evm_r5_usbdfu_defconfig | 116 ++++++++++++ drivers/timer/omap-timer.c | 1 + drivers/usb/dwc3/Kconfig | 14 ++ drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-am62.c | 127 +++++++++++++ include/configs/am62x_evm.h | 10 +- 15 files changed, 701 insertions(+), 92 deletions(-) create mode 100644 configs/am62x_evm_r5_usbdfu_defconfig create mode 100644 drivers/usb/dwc3/dwc3-am62.c -- 2.40.0

9 23

[PATCH v4 0/5] fs/erofs: new filesystem
by Huang Jianan 28 May '24

28 May '24

Changes since v3: - update tools/docker/Dockerfile; Changes since v2: - sync up with erofs-utils 1.4; - update lib/lz4 to v1.8.3; - add test for filesystem functions; Changes since v1: - fix the inconsistency between From and SoB; - add missing license header; Huang Jianan (5): fs/erofs: add erofs filesystem support lib/lz4: update LZ4 decompressor module fs/erofs: add lz4 decompression support fs/erofs: add filesystem commands test/py: Add tests for the erofs MAINTAINERS | 9 + cmd/Kconfig | 6 + cmd/Makefile | 1 + cmd/erofs.c | 42 ++ configs/sandbox_defconfig | 1 + fs/Kconfig | 2 + fs/Makefile | 1 + fs/erofs/Kconfig | 21 + fs/erofs/Makefile | 9 + fs/erofs/data.c | 311 +++++++++++++ fs/erofs/decompress.c | 78 ++++ fs/erofs/decompress.h | 24 + fs/erofs/erofs_fs.h | 436 ++++++++++++++++++ fs/erofs/fs.c | 267 +++++++++++ fs/erofs/internal.h | 313 +++++++++++++ fs/erofs/namei.c | 252 +++++++++++ fs/erofs/super.c | 105 +++++ fs/erofs/zmap.c | 601 ++++++++++++++++++++++++ fs/fs.c | 22 + include/erofs.h | 19 + include/fs.h | 1 + include/u-boot/lz4.h | 49 ++ lib/lz4.c | 679 ++++++++++++++++++++-------- lib/lz4_wrapper.c | 23 +- test/py/tests/test_fs/test_erofs.py | 211 +++++++++ tools/docker/Dockerfile | 1 + 26 files changed, 3269 insertions(+), 215 deletions(-) create mode 100644 cmd/erofs.c create mode 100644 fs/erofs/Kconfig create mode 100644 fs/erofs/Makefile create mode 100644 fs/erofs/data.c create mode 100644 fs/erofs/decompress.c create mode 100644 fs/erofs/decompress.h create mode 100644 fs/erofs/erofs_fs.h create mode 100644 fs/erofs/fs.c create mode 100644 fs/erofs/internal.h create mode 100644 fs/erofs/namei.c create mode 100644 fs/erofs/super.c create mode 100644 fs/erofs/zmap.c create mode 100644 include/erofs.h create mode 100644 test/py/tests/test_fs/test_erofs.py -- 2.25.1

5 20

[PATCH] fs: ubifs: Add support for ZSTD decompression
by Piotr Wojtaszczyk 27 May '24

27 May '24

Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk(a)timesys.com> --- fs/ubifs/ubifs-media.h | 2 ++ fs/ubifs/ubifs.c | 55 ++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 55 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/ubifs-media.h b/fs/ubifs/ubifs-media.h index 2b5b26a01b..299d80f928 100644 --- a/fs/ubifs/ubifs-media.h +++ b/fs/ubifs/ubifs-media.h @@ -320,12 +320,14 @@ enum { * UBIFS_COMPR_NONE: no compression * UBIFS_COMPR_LZO: LZO compression * UBIFS_COMPR_ZLIB: ZLIB compression + * UBIFS_COMPR_ZSTD: ZSTD compression * UBIFS_COMPR_TYPES_CNT: count of supported compression types */ enum { UBIFS_COMPR_NONE, UBIFS_COMPR_LZO, UBIFS_COMPR_ZLIB, + UBIFS_COMPR_ZSTD, UBIFS_COMPR_TYPES_CNT, }; diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c index a509584e5d..4df7cbb951 100644 --- a/fs/ubifs/ubifs.c +++ b/fs/ubifs/ubifs.c @@ -27,6 +27,11 @@ #include <linux/err.h> #include <linux/lzo.h> +#if IS_ENABLED(CONFIG_ZSTD) +#include <linux/zstd.h> +#include <abuf.h> +#endif + DECLARE_GLOBAL_DATA_PTR; /* compress.c */ @@ -42,6 +47,26 @@ static int gzip_decompress(const unsigned char *in, size_t in_len, (unsigned long *)out_len, 0, 0); } +#if IS_ENABLED(CONFIG_ZSTD) +static int zstd_decompress_wrapper(const unsigned char *in, size_t in_len, + unsigned char *out, size_t *out_len) +{ + struct abuf abuf_in, abuf_out; + int ret; + + abuf_init_set(&abuf_in, (void *)in, in_len); + abuf_init_set(&abuf_out, (void *)out, *out_len); + + ret = zstd_decompress(&abuf_in, &abuf_out); + if (ret < 0) { + return ret; + } + + *out_len = ret; + return 0; +} +#endif + /* Fake description object for the "none" compressor */ static struct ubifs_compressor none_compr = { .compr_type = UBIFS_COMPR_NONE, @@ -71,8 +96,22 @@ static struct ubifs_compressor zlib_compr = { .decompress = gzip_decompress, }; +#if IS_ENABLED(CONFIG_ZSTD) +static struct ubifs_compressor zstd_compr = { + .compr_type = UBIFS_COMPR_ZSTD, +#ifndef __UBOOT__ + .comp_mutex = &zstd_enc_mutex, + .decomp_mutex = &zstd_dec_mutex, +#endif + .name = "zstd", + .capi_name = "zstd", + .decompress = zstd_decompress_wrapper, +}; +#endif + + /* All UBIFS compressors */ -struct ubifs_compressor *ubifs_compressors[UBIFS_COMPR_TYPES_CNT]; +struct ubifs_compressor *ubifs_compressors[UBIFS_COMPR_TYPES_CNT] = {NULL}; #ifdef __UBOOT__ @@ -166,8 +205,14 @@ int ubifs_decompress(const struct ubifs_info *c, const void *in_buf, compr = ubifs_compressors[compr_type]; + if (unlikely(!compr)) { + ubifs_err(c, "compression type %d is not compiled in", compr_type); + return -EINVAL; + } + if (unlikely(!compr->capi_name)) { - ubifs_err(c, "%s compression is not compiled in", compr->name); + ubifs_err(c, "%s compression is not compiled in", + compr->name ? compr->name : "unknown"); return -EINVAL; } @@ -232,6 +277,12 @@ int __init ubifs_compressors_init(void) if (err) return err; +#if IS_ENABLED(CONFIG_ZSTD) + err = compr_init(&zstd_compr); + if (err) + return err; +#endif + err = compr_init(&none_compr); if (err) return err; -- 2.25.1

2 2