Messages in this thread | | | Date | Tue, 20 Sep 2022 21:11:54 +0200 (CEST) | From | Richard Weinberger <> | Subject | Re: [PATCH v4 4/4] mtdchar: add MEMREAD ioctl |
| |
----- Ursprüngliche Mail ----- > Von: "Michał Kępień" <kernel@kempniu.pl> > An: "Miquel Raynal" <miquel.raynal@bootlin.com>, "richard" <richard@nod.at>, "Vignesh Raghavendra" <vigneshr@ti.com> > CC: "Boris Brezillon" <boris.brezillon@collabora.com>, "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" > <linux-kernel@vger.kernel.org> > Gesendet: Mittwoch, 29. Juni 2022 14:57:37 > Betreff: [PATCH v4 4/4] 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.html > > Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> > Signed-off-by: Michał Kępień <kernel@kempniu.pl> > --- > drivers/mtd/mtdchar.c | 139 +++++++++++++++++++++++++++++++++++++ > include/uapi/mtd/mtd-abi.h | 64 +++++++++++++++-- > 2 files changed, 198 insertions(+), 5 deletions(-)
Acked-by: Richard Weinberger <richard@nod.at>
Thanks, //richard
| |