[lkml]   [2022]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4 4/4] mtdchar: add MEMREAD ioctl
----- Ursprüngliche Mail -----
> Von: "Michał Kępień" <>
> An: "Miquel Raynal" <>, "richard" <>, "Vignesh Raghavendra" <>
> CC: "Boris Brezillon" <>, "linux-mtd" <>, "linux-kernel"
> <>
> 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:
> Suggested-by: Boris Brezillon <>
> Signed-off-by: Michał Kępień <>
> ---
> drivers/mtd/mtdchar.c | 139 +++++++++++++++++++++++++++++++++++++
> include/uapi/mtd/mtd-abi.h | 64 +++++++++++++++--
> 2 files changed, 198 insertions(+), 5 deletions(-)

Acked-by: Richard Weinberger <>


 \ /
  Last update: 2022-09-20 22:54    [W:0.057 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site