Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Miquel Raynal <miquel.raynal@bootlin.com>
To:     =?utf-8?b?TWljaGHFgiBLxJlwaWXFhA==?= <kernel@kempniu.pl>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>
Cc:     Boris Brezillon <boris.brezillon@collabora.com>,
        linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/4] mtdchar: add MEMREAD ioctl
Date:   Wed, 21 Sep 2022 10:40:38 +0200
Message-Id: <20220921084038.733213-1-miquel.raynal@bootlin.com>
In-Reply-To: <20220629125737.14418-5-kernel@kempniu.pl>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

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