From patchwork Fri Nov 7 21:37:57 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Werner Almesberger X-Patchwork-Id: 7776 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DAEBBDDF46 for ; Sat, 8 Nov 2008 08:42:35 +1100 (EST) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1KyZ1z-0001dN-VV; Fri, 07 Nov 2008 21:38:16 +0000 Received: from mail.openmoko.org ([88.198.124.205]) by bombadil.infradead.org with esmtps (Exim 4.68 #1 (Red Hat Linux)) id 1KyZ1y-0001aF-Fz for linux-mtd@lists.infradead.org; Fri, 07 Nov 2008 21:38:14 +0000 Received: from ol194-228.fibertel.com.ar ([24.232.228.194] helo=ws) by mail.openmoko.org with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1KyZ64-0006LH-6R; Fri, 07 Nov 2008 21:42:30 +0000 Received: by ws (sSMTP sendmail emulation); Fri, 07 Nov 2008 19:37:57 -0200 Date: Fri, 7 Nov 2008 19:37:57 -0200 From: Werner Almesberger To: linux-mtd@lists.infradead.org Subject: [PATCH] clarify and improve calculation in nand_read_subpage Message-ID: <20081107213757.GC5177@almesberger.net> MIME-Version: 1.0 Content-Disposition: inline X-Spam-Score: 0.0 (/) Cc: Alexey Korolev X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org clarify-nand-ecc-access.patch The ECC access calculation in nand_read_subpage is quite hard to understand. This patch makes it more readable. There is a small change in what the algorithm does: while if (eccpos[(start_step + num_steps) * chip->ecc.bytes] & (busw - 1)) looks at the position of the ECC byte following the bytes we're currently reading, aligned_len = ALIGN(eccfrag_len+(pos-aligned_pos), busw); only looks at their length plus the additional data we have to read due to aligning the start position. The latter is more correct than the former, since the next ECC byte could be located anywhere and its location therefore may not give the alignment information we seek. The change also saves 44 bytes on ARM. Signed-off-by: Werner Almesberger Acked-by: Alexey Korolev Index: ktrack/drivers/mtd/nand/nand_base.c =================================================================== --- ktrack.orig/drivers/mtd/nand/nand_base.c 2008-11-02 02:28:19.000000000 -0200 +++ ktrack/drivers/mtd/nand/nand_base.c 2008-11-02 02:38:22.000000000 -0200 @@ -851,12 +851,12 @@ } else { /* send the command to read the particular ecc bytes */ /* take care about buswidth alignment in read_buf */ - aligned_pos = eccpos[start_step * chip->ecc.bytes] & ~(busw - 1); - aligned_len = eccfrag_len; - if (eccpos[start_step * chip->ecc.bytes] & (busw - 1)) - aligned_len++; - if (eccpos[(start_step + num_steps) * chip->ecc.bytes] & (busw - 1)) - aligned_len++; + + int pos; + + pos = eccpos[start_step * chip->ecc.bytes]; + aligned_pos = pos & ~(busw - 1); + aligned_len = ALIGN(eccfrag_len+(pos-aligned_pos), busw); chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + aligned_pos, -1); chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);