From patchwork Fri Jul 14 10:20:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 788296 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3x87yD5wk6z9s78 for ; Fri, 14 Jul 2017 20:21:24 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MnzmW5zQ"; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=Hb1mdsnCIGQTVf5YKx+eSMYMCmGPb9+aU3FJh4AIVPQ=; b=MnzmW5zQQL/1Tm qyKALD3LLd3Hq9UflSCtsbWacC4CbIC0Cr+uox94xmPzK3xZowDvBQSLMfVdszVmVPJ8t2F9zYkMB LuiXj0PcIkmk9b8ll+9YqaAv+GaLwjooz0LQGHh3MMFNzvoc29MUAWgpVxVmvO16AS7UIgopxUHU7 QyW7PAN233Fv4wfX6ZZZZgIkfT4xSV2ObJpPYTxVhKDz1YDKxayBSVGoU++mVG2pSiA9CpGkSrTGb pfS9XzZAdCTO0N8tmHnfq+eaqpd76lAqGT4gIPZYgRVeT3Evc+mgEwwmcKrZP7nFDWppyDZt3kRsa uEdLDOGVRnjvNWksj5gw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dVxik-0004G9-GC; Fri, 14 Jul 2017 10:21:14 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dVxif-0004FI-AL for linux-mtd@lists.infradead.org; Fri, 14 Jul 2017 10:21:12 +0000 Received: from dude.hi.pengutronix.de ([2001:67c:670:100:1d::7]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dVxi6-00052V-H1; Fri, 14 Jul 2017 12:20:34 +0200 Received: from ukl by dude.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1dVxi5-0002iN-2r; Fri, 14 Jul 2017 12:20:33 +0200 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= To: David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen Subject: [PATCH RFC] mtdpart: don't force alignment to eraseblock if flags have MTD_NO_ERASE Date: Fri, 14 Jul 2017 12:20:27 +0200 Message-Id: <20170714102027.9916-1-u.kleine-koenig@pengutronix.de> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::7 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mtd@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170714_032109_573933_94CB8086 X-CRM114-Status: GOOD ( 16.72 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mtd@lists.infradead.org, kernel@pengutronix.de Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Some mtd devices don't need to be erased before writing to them. For these it doesn't make sense to force partition alignment to erase blocks. This patch allows partitioning an Everspin mr25h256 that has erasesize=32768, size=32768 and writesize=1. Signed-off-by: Uwe Kleine-König --- Hello, this is my followup suggestion for From: Bastian Stender Subject: Re: [PATCH 1/2] mtd: spi-nor: make n_sectors in flash_info 32 bit wide Message-Id: It's IMHO ugly because the two bodys of the newly introduced if look very similar, but I think there is not much we can do about this. To ease your reviews: The else body is exactly what we had before. I'm a bit unsure about the check slave->mtd.erasesize >= slave->mtd.writesize because if that is false, the old code is not only inconvenient by not allowing partitions, but also wrong. So probably the check can safely be dropped? Otherwise the logic should be: if (MTD_NO_ERASE): alignto = writesize else: alignto = max(writesize, erasesize) Best regards Uwe drivers/mtd/mtdpart.c | 47 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c index ea5e5307f667..956c8f0ce2dd 100644 --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -567,20 +567,39 @@ static struct mtd_part *allocate_partition(struct mtd_info *master, slave->mtd.erasesize = master->erasesize; } - if ((slave->mtd.flags & MTD_WRITEABLE) && - mtd_mod_by_eb(slave->offset, &slave->mtd)) { - /* Doesn't start on a boundary of major erase size */ - /* FIXME: Let it be writable if it is on a boundary of - * _minor_ erase size though */ - slave->mtd.flags &= ~MTD_WRITEABLE; - printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an erase block boundary -- force read-only\n", - part->name); - } - if ((slave->mtd.flags & MTD_WRITEABLE) && - mtd_mod_by_eb(slave->mtd.size, &slave->mtd)) { - slave->mtd.flags &= ~MTD_WRITEABLE; - printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an erase block -- force read-only\n", - part->name); + if (slave->mtd.flags & MTD_NO_ERASE && + slave->mtd.erasesize >= slave->mtd.writesize) { + /* If we don't need to erase, then align to writesize */ + if ((slave->mtd.flags & MTD_WRITEABLE) && + mtd_mod_by_ws(slave->offset, &slave->mtd)) { + /* Doesn't start on a boundary of page */ + /* FIXME: Can a minor erase block be smaller than a page? */ + slave->mtd.flags &= ~MTD_WRITEABLE; + printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on a page boundary -- force read-only\n", + part->name); + } + if ((slave->mtd.flags & MTD_WRITEABLE) && + mtd_mod_by_ws(slave->mtd.size, &slave->mtd)) { + slave->mtd.flags &= ~MTD_WRITEABLE; + printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on a page boundary -- force read-only\n", + part->name); + } + } else { + if ((slave->mtd.flags & MTD_WRITEABLE) && + mtd_mod_by_eb(slave->offset, &slave->mtd)) { + /* Doesn't start on a boundary of major erase size */ + /* FIXME: Let it be writable if it is on a boundary of + * _minor_ erase size though */ + slave->mtd.flags &= ~MTD_WRITEABLE; + printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an erase block boundary -- force read-only\n", + part->name); + } + if ((slave->mtd.flags & MTD_WRITEABLE) && + mtd_mod_by_eb(slave->mtd.size, &slave->mtd)) { + slave->mtd.flags &= ~MTD_WRITEABLE; + printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an erase block -- force read-only\n", + part->name); + } } mtd_set_ooblayout(&slave->mtd, &part_ooblayout_ops);