Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp4362699rwb; Tue, 20 Sep 2022 12:47:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7/YN4kj+onv8tLL4gFr+DqOibjn3nCQfM5VWWZ7X+3isCIVySZrM5H3UvAm3jIGJ9vjqlz X-Received: by 2002:a05:6402:4505:b0:451:1551:7b14 with SMTP id ez5-20020a056402450500b0045115517b14mr21630476edb.300.1663703220477; Tue, 20 Sep 2022 12:47:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663703220; cv=none; d=google.com; s=arc-20160816; b=e9Tntmh3rUEx+S0lMg4lf3qYSyw3NwLXopF4Gq5KgRQ3l/PBCrLagLGsrqj5FJUtZB SNz8byXr5csqBBIDJjPTP3hDbzz0H3mvg8ElouBY5TjvInPAgTZ0FgDN2prrCIjGEHHP yEOMfpd3LEWHTATf3pH61mYox6UtYmP/WcyTjU76jDB0TVRSBv5+882AxuWHe4f3eokM QN47wRBp/OnrQLK3NEJkX7VmK3zjBXrfql0qvZBEIQRUY6/o6c0NGRI7TfvVDBizW5yW j9lXr7v+YSdztfRIdIQ0NUjTmYo90qaNeQBhHWDSGheI9yO9xHlRJqhz8weKTU7uzYAc yf2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date; bh=UAmEix1QfHuxjtqsYyeiGJvK0tAhw3dNCs2DWnq3Oko=; b=ytB8KxpeyTSXSrEdCxJETuea8tEqjU//o98iwWBYgCh6lcmGGFxuHJpMEUYUvoZlQn fc+q7bp9DCMAtCEtCRhza8L5jAqyaeqsfvhr9+V128FwIsItNcOBDb7mMr3o7VcoVOnP 0gUvH4VtP5ABGu4gDMGJCnUFMrg+eW1Mk7uWTwhhYpvlXqezO6gC2mnhgngS8i9lcvl8 aJdq6OeBw7Cy5BD0qE7mHm+20wE2b8fSOQXN6g0Iv28hXHqnXqRreyqNKxYQ8in9JqlW 3VvDj6FB1jH7E+rXbfN/chXFlTYYMxgX537/20va9IDhupOhKJH6b7Xg3vtiw/XU+Amg JmSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n4-20020a5099c4000000b0044f0a023da0si649309edb.118.2022.09.20.12.46.33; Tue, 20 Sep 2022 12:47:00 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229596AbiITTMD convert rfc822-to-8bit (ORCPT + 99 others); Tue, 20 Sep 2022 15:12:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229529AbiITTMB (ORCPT ); Tue, 20 Sep 2022 15:12:01 -0400 Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5352732EE6 for ; Tue, 20 Sep 2022 12:11:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 2ACD563BBD4B; Tue, 20 Sep 2022 21:11:55 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Sucjpe0Cfkhy; Tue, 20 Sep 2022 21:11:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 664E763BBD41; Tue, 20 Sep 2022 21:11:54 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8wHuVCEmh8N2; Tue, 20 Sep 2022 21:11:54 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 3BC2C63BBD38; Tue, 20 Sep 2022 21:11:54 +0200 (CEST) Date: Tue, 20 Sep 2022 21:11:54 +0200 (CEST) From: Richard Weinberger To: =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= Cc: Miquel Raynal , Vignesh Raghavendra , Boris Brezillon , linux-mtd , linux-kernel Message-ID: <955252833.244763.1663701114159.JavaMail.zimbra@nod.at> In-Reply-To: <20220629125737.14418-5-kernel@kempniu.pl> References: <20220629125737.14418-1-kernel@kempniu.pl> <20220629125737.14418-5-kernel@kempniu.pl> Subject: Re: [PATCH v4 4/4] mtdchar: add MEMREAD ioctl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF97 (Linux)/8.8.12_GA_3809) Thread-Topic: mtdchar: add MEMREAD ioctl Thread-Index: x3jbmUpbWewkvCtv3NAUFhw8zSthgg== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- 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: https://www.infradead.org/pipermail/linux-mtd/2016-April/067085.html > > 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 Thanks, //richard