[v5,3/5] mtd: handle partitioning on devices with 0 erasesize
diff mbox

Message ID 20170602032119.22282-4-chris.packham@alliedtelesis.co.nz
State Changes Requested
Headers show

Commit Message

Chris Packham June 2, 2017, 3:21 a.m. UTC
erasesize is meaningful for flash devices but for SRAM there is no
concept of an erase block so erasesize is set to 0. When partitioning
these devices instead of ensuring partitions fall on erasesize
boundaries we ensure they fall on writesize boundaries.

Helped-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Changes in v3:
- new
Changes in v4:
- None
Changes in v5:
- None (yet). There is some active discussion on this so it may change.
  patch 4/5 is somewhat dependent on this but only if partitions are
  specified on the dt node.

 drivers/mtd/mtdpart.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

Comments

Brian Norris June 8, 2017, 11:26 p.m. UTC | #1
On Fri, Jun 02, 2017 at 03:21:17PM +1200, Chris Packham wrote:
> erasesize is meaningful for flash devices but for SRAM there is no
> concept of an erase block so erasesize is set to 0. When partitioning
> these devices instead of ensuring partitions fall on erasesize
> boundaries we ensure they fall on writesize boundaries.
> 
> Helped-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v3:
> - new
> Changes in v4:
> - None
> Changes in v5:
> - None (yet). There is some active discussion on this so it may change.
>   patch 4/5 is somewhat dependent on this but only if partitions are
>   specified on the dt node.
> 
>  drivers/mtd/mtdpart.c | 25 ++++++++++++++++---------
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index ea5e5307f667..5cef1247806c 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -393,8 +393,11 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
>  			const struct mtd_partition *part, int partno,
>  			uint64_t cur_offset)
>  {
> +	int wr_alignment = master->erasesize ? : master->writesize;

I'd prefer this be checked based on the MTD_NO_ERASE flag, as the
erasesize is essentially undefined. That might also help other drivers,
which might currently fake an erasesize just to satisfy this check. Now,
they won't have to.

i.e.

	int wr_alignment = (master->flags & MTD_NO_ERASE) ? master->erasesize :
							    master->writesize;

or similar.

>  	struct mtd_part *slave;
> +	u32 remainder;
>  	char *name;
> +	u64 tmp;
>  
>  	/* allocate the partition structure */
>  	slave = kzalloc(sizeof(*slave), GFP_KERNEL);

...

Brian
Chris Packham July 4, 2017, 3:22 a.m. UTC | #2
Hi,

On 02/06/17 15:21, Chris Packham wrote:
> erasesize is meaningful for flash devices but for SRAM there is no
> concept of an erase block so erasesize is set to 0. When partitioning
> these devices instead of ensuring partitions fall on erasesize
> boundaries we ensure they fall on writesize boundaries.
> 
> Helped-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>

I had someone mention to me in passing that mtdinfo was failing for them 
(crashing with some floating point error). I'm wondering if we've 
created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. 
I don't have any other info and right now I don't have access to the 
system I had with the mchp23lcv1024 sram.

Andrew, do you still have access to your device?
Brian Norris July 8, 2017, 1:14 a.m. UTC | #3
On Tue, Jul 04, 2017 at 03:22:52AM +0000, Chris Packham wrote:
> I had someone mention to me in passing that mtdinfo was failing for them 
> (crashing with some floating point error). I'm wondering if we've 
> created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. 
> I don't have any other info and right now I don't have access to the 
> system I had with the mchp23lcv1024 sram.

Wouldn't be that surprising. mtdinfo is actually developed under the
"ubi-utils" directory of mtd-utils, and UBI wouldn't know what to do
with and SRAM like that.

Brian

Patch
diff mbox

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index ea5e5307f667..5cef1247806c 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -393,8 +393,11 @@  static struct mtd_part *allocate_partition(struct mtd_info *master,
 			const struct mtd_partition *part, int partno,
 			uint64_t cur_offset)
 {
+	int wr_alignment = master->erasesize ? : master->writesize;
 	struct mtd_part *slave;
+	u32 remainder;
 	char *name;
+	u64 tmp;
 
 	/* allocate the partition structure */
 	slave = kzalloc(sizeof(*slave), GFP_KERNEL);
@@ -499,10 +502,11 @@  static struct mtd_part *allocate_partition(struct mtd_info *master,
 	if (slave->offset == MTDPART_OFS_APPEND)
 		slave->offset = cur_offset;
 	if (slave->offset == MTDPART_OFS_NXTBLK) {
+		tmp = cur_offset;
 		slave->offset = cur_offset;
-		if (mtd_mod_by_eb(cur_offset, master) != 0) {
-			/* Round up to next erasesize */
-			slave->offset = (mtd_div_by_eb(cur_offset, master) + 1) * master->erasesize;
+		remainder = do_div(tmp, wr_alignment);
+		if (remainder) {
+			slave->offset += wr_alignment - remainder;
 			printk(KERN_NOTICE "Moving partition %d: "
 			       "0x%012llx -> 0x%012llx\n", partno,
 			       (unsigned long long)cur_offset, (unsigned long long)slave->offset);
@@ -567,19 +571,22 @@  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)) {
+	tmp = slave->offset;
+	remainder = do_div(tmp, wr_alignment);
+	if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
 		/* 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",
+		printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an erase/write block boundary -- force read-only\n",
 			part->name);
 	}
-	if ((slave->mtd.flags & MTD_WRITEABLE) &&
-	    mtd_mod_by_eb(slave->mtd.size, &slave->mtd)) {
+
+	tmp = slave->mtd.size;
+	remainder = do_div(tmp, wr_alignment);
+	if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
 		slave->mtd.flags &= ~MTD_WRITEABLE;
-		printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an erase block -- force read-only\n",
+		printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an erase/write block -- force read-only\n",
 			part->name);
 	}