From patchwork Sat Aug 17 18:14:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 267995 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (unknown [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B4E862C00AA for ; Sun, 18 Aug 2013 04:15:31 +1000 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VAl1x-0007Lw-Lg; Sat, 17 Aug 2013 18:15:17 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VAl1v-0000d5-VO; Sat, 17 Aug 2013 18:15:15 +0000 Received: from mail-pa0-x231.google.com ([2607:f8b0:400e:c03::231]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VAl1t-0000bv-Df for linux-mtd@lists.infradead.org; Sat, 17 Aug 2013 18:15:14 +0000 Received: by mail-pa0-f49.google.com with SMTP id ld10so3124129pab.22 for ; Sat, 17 Aug 2013 11:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=o5lfaYvl5PeQK8JppbDx5ej0HI8xeoi6K1YeZxC3ZKY=; b=D1eOzmsvrJGFAsoBV9X5wlNVNGfouIau9VQ/UTzbwVGhpo31VCxHuYEz8bSIbccgxi 55va9jP1lK/SmgyjrDsS6nxPSfzfaKtGGh33Xyhyxz363l3NaIf3PgpDN3ByJfNTGlHe U7kN3+wC1KOcrrhMgvgITLv5wr8JyX2/qVkGkY4VJ9Yg6qQuuqzJcJTiVnG6ub7T6Q9t ojVCen8R1rHfksm7j8Y1Y5EOqQ6T9CqRmoSMLLHKO5OT+IzGjvIFtNQJaX8VjsZsi+Eu dnA9EAB0CvSBq7Z29Z+cKrd5w1jDfLyLVVEqoLJwearKlbtqEuAiSwJ2v2a7FnkIeKcz jHQw== X-Received: by 10.68.137.134 with SMTP id qi6mr2846798pbb.154.1376763291001; Sat, 17 Aug 2013 11:14:51 -0700 (PDT) Received: from norris.computersforpeace.net (cpe-76-174-184-249.socal.res.rr.com. [76.174.184.249]) by mx.google.com with ESMTPSA id sz6sm5273315pab.5.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 17 Aug 2013 11:14:50 -0700 (PDT) Date: Sat, 17 Aug 2013 11:14:47 -0700 From: Brian Norris To: Huang Shijie Subject: Re: [PATCH v4 6/6] mtd: update the ABI document about the ecc step size Message-ID: <20130817181447.GC5034@norris.computersforpeace.net> References: <1376619009-8622-1-git-send-email-b32955@freescale.com> <1376619009-8622-7-git-send-email-b32955@freescale.com> <1376660759.2089.358.camel@sauron.fi.intel.com> <20130817032644.GA27332@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130817032644.GA27332@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130817_141513_626737_0DFBF4DD X-CRM114-Status: GOOD ( 16.27 ) X-Spam-Score: -2.0 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (computersforpeace[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Huang Shijie , linux-mtd@lists.infradead.org, dwmw2@infradead.org, pekon@ti.com, Artem Bityutskiy X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Fri, Aug 16, 2013 at 11:26:47PM -0400, Huang Shijie wrote: > On Fri, Aug 16, 2013 at 04:45:59PM +0300, Artem Bityutskiy wrote: > > On Fri, 2013-08-16 at 10:10 +0800, Huang Shijie wrote: > > > + > > > +What: /sys/class/mtd/mtdX/ecc_step_size > > > +Date: May 2013 > > > +KernelVersion: 3.10 > > > +Contact: linux-mtd@lists.infradead.org > > > +Description: > > > + The size of each ECC step which is used for ECC. > > > + Note that some devices will have multiple ecc steps within each > > > + writesize region. > > > > Actually this phrase is a bit confusing because it may be interpreted as > > that one write-size may have ECC steps of multiple sizes. Would you > > re-phrase, may be? > What's about the following: > ----------------------------------------------------------------- > The size of each ECC step which is used for ECC. > Note that some devices will have multiple ecc steps within each > writesize region, and the ecc steps share the same size. > ----------------------------------------------------------------- I took pieces of your message and rewrote it myself. Diff pasted below (I edited ecc_strength to be less redundant and added a few details that were worth mentioning). Let me know if you want to revise it, but I'll push it to l2-mtd.git. Brian --- Documentation/ABI/testing/sysfs-class-mtd | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd index 3105644..a795582 100644 --- a/Documentation/ABI/testing/sysfs-class-mtd +++ b/Documentation/ABI/testing/sysfs-class-mtd @@ -128,9 +128,8 @@ KernelVersion: 3.4 Contact: linux-mtd@lists.infradead.org Description: Maximum number of bit errors that the device is capable of - correcting within each region covering an ecc step. This will - always be a non-negative integer. Note that some devices will - have multiple ecc steps within each writesize region. + correcting within each region covering an ECC step (see + ecc_step_size). This will always be a non-negative integer. In the case of devices lacking any ECC capability, it is 0. @@ -173,3 +172,16 @@ Description: This is generally applicable only to NAND flash devices with ECC capability. It is ignored on devices lacking ECC capability; i.e., devices for which ecc_strength is zero. + +What: /sys/class/mtd/mtdX/ecc_step_size +Date: May 2013 +KernelVersion: 3.10 +Contact: linux-mtd@lists.infradead.org +Description: + The size of a single region covered by ECC, known as the ECC + step. Devices may have several equally sized ECC steps within + each writesize region. The step size counts only the data area, + not the spare area. + + It will always be a non-negative integer. In the case of + devices lacking any ECC capability, it is 0.