All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Richard Weinberger <richard@nod.at>,
	Artem Bityutskiy <dedekind1@gmail.com>
Cc: Rajeev Kumar <rajeev_kumar@mentor.com>,
	dwmw2@infradead.org, dedekind1@gmail.com,
	linux-mtd@lists.infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] ubi: attach: do not return -EINVAL if the mtd->numeraseregions is 1
Date: Fri, 29 Jul 2016 11:24:49 -0700	[thread overview]
Message-ID: <20160729182449.GA124841@google.com> (raw)
In-Reply-To: <5795EA8B.2040209@nod.at>

(Artem, any opinions, since you had the most opinion last time this came
up?)

On Mon, Jul 25, 2016 at 12:31:39PM +0200, Richard Weinberger wrote:
> Am 25.07.2016 um 11:46 schrieb Rajeev Kumar:
> > If the master mtd does not have any slave mtd partitions,
> > and its numeraseregions is one(only has one erease block), and
> > we attach the master mtd with : ubiattach -m 0 -d 0
> > 
> > We will meet the error:
> > -------------------------------------------------------
> > root ~$ ubiattach /dev/ubi_ctrl -m 0 -d 0
> > UBI: attaching mtd0 to ubi0
> > UBI error: io_init: multiple regions, not implemented
> > ubiattach: error!: cannot attach mtd0
> >            error 22 (Invalid argument)
> > -------------------------------------------------------
> > 
> > In fact, if there is only one "erase block", we should not
> > prevent the attach.
> > 
> > This patch is tested against 3.14 kernel and only build test is
> > performed against current upstream master branch.
> 
> The more interesting question is, why is ->numeraseregions not 0?
> 
> The comment in the header says:
>         /* Data for variable erase regions. If numeraseregions is zero,
>          * it means that the whole device has erasesize as given above.
>          */
> 
> So, if your MTD erase regions with the same size, it should be 0.
> 
> IIRC we had such a discussion already on linux-mtd and it was not clear
> whether numeraseregions of 0 and 1 are equal or not.

I think 0 and 1 are essentially equal. But there's some potential room
for error (e.g., if the driver doesn't configure mtd->erasesize ==
mtd->eraseregions[0].erasesize, and similar). Also, I see some
problematic code like this in cfi_cmdset_0001.c:

	mtd->numeraseregions = cfi->cfiq->NumEraseRegions * cfi->numchips;

So, if there are two chips, but both have a single erase region, with
the same erasesize, we'll still end up with ->numeraseregions == 2. We
can't hack all MTD users to start searching the eraseregions[] array to
see if the device is actually uniform, even if it reports
numeraseregions > 0.

I'm inclined, then, to outlaw numeraseregions == 1 (to make it simpler for MTD
users to handle), and put code either in drivers or in mtdcore.c to be slightly
more intelligent (e.g., if the driver left numeraseregions == 1, then just do
some sanity checking and re-set numeraseregions to 0). It might be good to move
code like this from cfi_cmdset_0001.c into mtdcore.c at the same time too:

	if (offset != devsize) {
		/* Argh */
		printk(KERN_WARNING "Sum of regions (%lx) != total size of set of interleaved chips (%lx)\n", offset, devsize);
		goto setup_err;
	}

BTW, Rajeev, what devices are you testing? Just curious.

Regards,
Brian

  parent reply	other threads:[~2016-07-29 18:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25  9:46 [PATCH 1/2] MTD: UBI: speed up init by moving status messages to debugfs Rajeev Kumar
2016-07-25  9:46 ` [PATCH 2/2] ubi: attach: do not return -EINVAL if the mtd->numeraseregions is 1 Rajeev Kumar
2016-07-25 10:31   ` Richard Weinberger
2016-07-25 11:16     ` Rajeev Kumar
2016-07-25 11:20       ` Richard Weinberger
2016-07-29 18:24     ` Brian Norris [this message]
2016-08-04  6:30       ` Artem Bityutskiy
2016-09-23 11:20         ` Chugh, Sanjeev
2016-09-23 11:37           ` Chugh, Sanjeev
2016-10-26 12:26           ` Chugh, Sanjeev
2016-07-25 10:31 ` [PATCH 1/2] MTD: UBI: speed up init by moving status messages to debugfs Richard Weinberger
2016-07-25 11:23   ` Rajeev Kumar
2016-07-25 11:32     ` Richard Weinberger
2016-07-25 16:47       ` Greg KH
2016-07-25 20:39         ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160729182449.GA124841@google.com \
    --to=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rajeev_kumar@mentor.com \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.