u-boot.git/fs/ext4/ext4_common.c, branch v2021.04

common: Drop log.h from common header

2020-05-19T01:19:18Z

Move this header out of the common header. Signed-off-by: Simon Glass

common: Drop part.h from common header

2020-05-18T21:33:33Z

Move this uncommon header out of the common header. Signed-off-by: Simon Glass

ext4: gracefully fail on divide-by-0

2019-07-18T15:31:29Z

This patch checks for 0 in several ext4 headers and gracefully fails instead of raising a divide-by-0 exception. Signed-off-by: Paul Emge

ext4: fix calculating inode blkcount for non-512 blocksize filesystems

2019-07-18T15:31:24Z

The block count entry in the EXT4 filesystem disk structures uses standard 512-bytes units for most of the typical files. The only exception are HUGE files, which use the filesystem block size, but those are not supported by uboot's EXT4 implementation anyway. This patch fixes the EXT4 code to use proper unit count for inode block count. This fixes errors reported by fsck.ext4 on disks with non-standard (i.e. 4KiB, in case of new flash drives) PHYSICAL block size after using 'ext4write' uboot's command. Signed-off-by: Marek Szyprowski Reviewed-by: Lukasz Majewski

Fix ext4 block group descriptor sizing

2019-04-10T00:04:06Z

Ext4 allows for arbitrarily sized block group descriptors when 64-bit addressing is enabled, which was previously not properly supported. This patch dynamically allocates a chunk of memory of the correct size. Signed-off-by: Benjamin Lim

fs: ext4: Problem with ext4load and sparse files

2019-04-10T00:04:03Z

Hi, when I try to load a sparse file via ext4load, I am getting the error message 'invalid extent' After a deeper look in the code, it seems to be an issue in the function ext4fs_get_extent_block in fs/ext4/ext4_common.c: The file starts with 1k of zeros. The blocksize is 1024. So the first extend block contains the following information: eh_entries: 1 eh_depth: 1 ei_block 1 When the upper layer (ext4fs_read_file) asks for fileblock 0, we are running in the 'invalid extent' error message. For me it seems, that the code is not prepared for handling a sparse block at the beginning of the file. The following change, solved my problem: I am really not an expert in ext4 filesystems. Can somebody please have a look at this issue and give me a feedback, if I am totally wrong or not?

fs: ext4: Add support for the creation of symbolic links

2019-04-10T00:03:30Z

Re-use the functions used to write/create a file, to support creation of a symbolic link. The difference with a regular file are small: - The inode mode is flagged with S_IFLNK instead of S_IFREG - The ext2_dirent's filetype is FILETYPE_SYMLINK instead of FILETYPE_REG - Instead of storing the content of a file in allocated blocks, the path to the target is stored. And if the target's path is short enough, no block is allocated and the target's path is stored in ext2_inode.b.symlink As with regulars files, if a file/symlink with the same name exits, it is unlinked first and then re-created. Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini [trini: Fix ext4 env code] Signed-off-by: Tom Rini

fs: ext4: constify the buffer passed to write functions

2019-04-09T19:34:15Z

There is no need to modify the buffer passed to ext4fs_write_file(). The memset() call is not required here and was likely copied from the equivalent part of the ext4fs_read_file() function where we do need it. Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini

fs: ext4: cache extent data

2019-04-09T19:34:15Z

When a file contains extents, U-Boot currently reads extent-related data for each block in the file, even if that data is located in the same block each time. This significantly slows down loading of files that use extents. Implement a very dumb cache to prevent repeatedly reading the same block. Files with extents now load as fast as files without. Note: There are many cases where read_allocated_block() is called. This patch only addresses one of those places; all others still read redundant data in any case they did before. This is a minimal patch to fix the load command; other cases aren't fixed. Signed-off-by: Stephen Warren

Remove includes and PRI* usages in printf() entirely

2018-09-11T00:48:17Z

In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's . Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada