mtd-utils.git/lib, branch v1.5.2

libmtd: fix comment typo

2015-05-28T23:31:34+00:00

Signed-off-by: Baruch Siach Signed-off-by: Brian Norris

mtd-utils: libfec: use standard C type instead of u_long

2015-05-28T23:31:34+00:00

Fixes compilation on hosts with the musl C library. Also drops the unused u_short typedef. Signed-off-by: Imre Kaloz Signed-off-by: Brian Norris

libmtd: don't ignore "region index" parameter in mtd_regioninfo()

2014-11-05T03:00:42+00:00

ioctl(MEMGETREGIONINFO) has one input parameter (regionindex) and three output parameters (info about the erase region). There are two problems in mtdinfo/libmtd here: 1. mtdinfo.c doesn't initialize its region_info_user struct, instead passing uninitialized data to mtd_regioninfo() 2. mtd_regioninfo() fails to utilize the 'regidx' parameter to fill out the regionindex parameter properly, so the garbage from mtdinfo.c is propagated to the ioctl() This means that mtdinfo will continuously probe the same (possibly out-of-range) erase region, instead of looping over the valid regions. Let's fix this in the mtd_regioninfo() helper, and at the same time, let's zero out the mtdinfo.c buffer, as an additional precaution to keep from using uninitialized data. Initial error report from Yang, when running "mtdinfo /dev/mtd0" on a Cavium 6100 board: root@CN61XX:~# mtdinfo /dev/mtd0 mtd0 Name: phys_mapped_flash Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 128 (8388608 bytes, 8.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Additional erase regions: 0 Character device major/minor: 90:0 Bad blocks are allowed: false Device is writable: true libmtd: error!: MEMGETREGIONINFO ioctl failed for erase region 0 error 22 (Invalid argument) Eraseblock region 0: info is unavailable libmtd: error!: MEMGETREGIONINFO ioctl failed for erase region 1 error 22 (Invalid argument) Eraseblock region 1: info is unavailable Reported-by: Yang Wei Signed-off-by: Brian Norris

libmtd: fix mtd_dev_present return value on legacy systems

2014-09-15T17:11:02+00:00

On legacy systems, if "/proc/mtd" doesn't exist or gives a read error, mtd_dev_present returns -1 (since it calls legacy_dev_present), contrary to what's specified in the header file. This causes checks like if (mtd_dev_present(n)) { ... } to give false positives. Fix this by comparing the return value to 1. Signed-off-by: Guido Martínez Signed-off-by: Brian Norris

check the MLC nand type

2013-10-22T23:19:23+00:00

In the current code, the MTD_NANDFLASH stands for both the SLC and MLC. In the kernel, the MTD_NANDFLASH only stands for the SLC now, so in order to keep the logic unchanged, we should also check the MLC NAND by MTD_MLCNANDFLASH. Signed-off-by: Huang Shijie Signed-off-by: Brian Norris

add the MTD_MLCNANDFLASH case

2013-10-22T23:17:52+00:00

The MTD_MLCNANDFLASH case is missed in the current code. This patch adds it. Signed-off-by: Huang Shijie Signed-off-by: Brian Norris

consistency between u_int32_t / off_t / off64_t

2012-09-25T15:06:50+00:00

We should use the off_t type instead of off64_t or u_int32_t as its length is controlled by the WITHOUT_LARGEFILE flag. Signed-off-by: Richard Genoud Signed-off-by: Artem Bityutskiy

libmtd_legacy: don't open device in R/W

2012-02-29T07:19:17+00:00

On legacy kernels with ROM devices, we can get mtdinfo errors like: libmtd: error!: cannot open "/dev/mtd4" error 13 (Permission denied) mtdinfo: error!: libmtd failed get MTD device 4 information error 13 (Permission denied) We don't need O_RDRW access for informational ioctls(), so make this O_RDONLY. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy

libmtd: perform device checking first

2012-02-29T07:19:17+00:00

If we don't check for the MTD before calling `legacy_get_dev_info1', we may get errors like: libmtd: MTD subsystem is old and does not support sysfs, so MTD character device nodes have to exist libmtd: error!: "/dev/mtd2" is not a character device mtdinfo: error!: libmtd failed get MTD device 2 information error 22 (Invalid argument) So reverse the order of these two checks. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy

libmtd: fix mtd_write() issues for large data-only writes

2012-02-14T09:01:20+00:00

ioctl(MEMWRITE) is implemented with memdup_user(), and so it allocates kernel memory in contiguous regions. This limits its usefulness for large amounts of data, since contiguous kernel memory can become scarce. I have experienced "out of memory" problems with ubiformat, for instance, which writes in eraseblock-sized regions: ... ubiformat: flashing eraseblock 12 -- 72 % complete ubiformat: page allocation failure. order:8, mode:0xd0 Call Trace: [<8043fa7c>] dump_stack+0x8/0x34 [<8008c940>] __alloc_pages_nodemask+0x408/0x618 [<800bd748>] cache_alloc_refill+0x400/0x730 [<800bdbbc>] __kmalloc+0x144/0x154 [<8009cae4>] memdup_user+0x24/0x94 [<802d04e4>] mtd_ioctl+0xba8/0xbd0 [<802d0544>] mtd_unlocked_ioctl+0x38/0x5c [<800d43c0>] do_vfs_ioctl+0xa4/0x6e4 [<800d4a44>] sys_ioctl+0x44/0xa0 [<8000f95c>] stack_done+0x20/0x40 ... libmtd: error!: MEMWRITE ioctl failed for eraseblock 12 (mtd0) error 12 (Cannot allocate memory) ubiformat: error!: cannot write eraseblock 12 error 12 (Cannot allocate memory) This error can be mitigated for now by only using ioctl(MEMWRITE) when we need to write OOB data, since we can only do this in small transactions anyway. Then, data-only transactions (like those originating from ubiformat) can be carried out with write() calls. This issue can also be solved within the kernel ioctl(), but either way, this patch is still useful, since write() is more straightforward (and efficient?) than ioctl() for data-only writes. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy