Messages in this thread | | | From | Miquel Raynal <> | Subject | Re: [PATCH v4 4/4] mtdchar: add MEMREAD ioctl | Date | Wed, 21 Sep 2022 10:40:38 +0200 |
| |
On Wed, 2022-06-29 at 12:57:37 UTC, =?utf-8?b?TWljaGHFgiBLxJlwaWXFhA==?= wrote: > User-space applications making use of MTD devices via /dev/mtd* > character devices currently have limited capabilities for reading data: > > - only deprecated methods of accessing OOB layout information exist, > > - there is no way to explicitly specify MTD operation mode to use; it > is auto-selected based on the MTD file mode (MTD_FILE_MODE_*) set > for the character device; in particular, this prevents using > MTD_OPS_AUTO_OOB for reads, > > - all existing user-space interfaces which cause mtd_read() or > mtd_read_oob() to be called (via mtdchar_read() and > mtdchar_read_oob(), respectively) return success even when those > functions return -EUCLEAN or -EBADMSG; this renders user-space > applications using these interfaces unaware of any corrected > bitflips or uncorrectable ECC errors detected during reads. > > Note that the existing MEMWRITE ioctl allows the MTD operation mode to > be explicitly set, allowing user-space applications to write page data > and OOB data without requiring them to know anything about the OOB > layout of the MTD device they are writing to (MTD_OPS_AUTO_OOB). Also, > the MEMWRITE ioctl does not mangle the return value of mtd_write_oob(). > > Add a new ioctl, MEMREAD, which addresses the above issues. It is > intended to be a read-side counterpart of the existing MEMWRITE ioctl. > Similarly to the latter, the read operation is performed in a loop which > processes at most mtd->erasesize bytes in each iteration. This is done > to prevent unbounded memory allocations caused by calling kmalloc() with > the 'size' argument taken directly from the struct mtd_read_req provided > by user space. However, the new ioctl is implemented so that the values > it returns match those that would have been returned if just a single > mtd_read_oob() call was issued to handle the entire read operation in > one go. > > Note that while just returning -EUCLEAN or -EBADMSG to user space would > already be a valid and useful indication of the ECC algorithm detecting > errors during a read operation, that signal would not be granular enough > to cover all use cases. For example, knowing the maximum number of > bitflips detected in a single ECC step during a read operation performed > on a given page may be useful when dealing with an MTD partition whose > ECC layout varies across pages (e.g. a partition consisting of a > bootloader area using a "custom" ECC layout followed by data pages using > a "standard" ECC layout). To address that, include ECC statistics in > the structure returned to user space by the new MEMREAD ioctl. > > Link: https://www.infradead.org/pipermail/linux-mtd/2016-April/067085.html > > Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> > Signed-off-by: Michał Kępień <kernel@kempniu.pl> > Acked-by: Richard Weinberger <richard@nod.at>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
Miquel
| |