mtdchar: add MEMREAD ioctl
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.htmlSuggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Michał Kępień <kernel@kempniu.pl> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220629125737.14418-5-kernel@kempniu.pl
Showing
Please register or sign in to comment