All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>,
	Richard Weinberger <richard@nod.at>
Cc: Rajeev Kumar <rajeev_kumar@mentor.com>,
	dwmw2@infradead.org, 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: Thu, 04 Aug 2016 09:30:52 +0300	[thread overview]
Message-ID: <1470292252.2311.48.camel@gmail.com> (raw)
In-Reply-To: <20160729182449.GA124841@google.com>

On Fri, 2016-07-29 at 11:24 -0700, Brian Norris wrote:
> (Artem, any opinions, since you had the most opinion last time this
> came
> up?)

Hi Brian, 

well, I do not have strong opinion. That UBI translates to "I do not
know how to deal with multiple regions", nothing else.

I think this was my understanding of numeraseregions

1. numaraseregions=0: no regions, just uniform flash.

2. numeraseregions=1: basically same as above, but friendlier to the
region-aware software. Indeed, if I care about regions, I do not want
to handle the special case of numerasereions=0, I want a common case
with numerasereionts>0.

Or to put it this way, from the drivers' writer POW:

numaraseregions=0 - do not know anything about regions, do not care.
Also pre-regions dirivers, old stuff

numeraseregions=1 - I want my driver to be ideal. Non-aware SW won't
look to the regions stuff, the aware SW will work nicely.

So my take is: ban numeraseregions=1 if you feel like, but I recommend
to just document the 0 (don't care/legacy) and 1 (same as 0, but care)
and allow for both.

Artem.

  reply	other threads:[~2016-08-04  6:31 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
2016-08-04  6:30       ` Artem Bityutskiy [this message]
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=1470292252.2311.48.camel@gmail.com \
    --to=dedekind1@gmail.com \
    --cc=computersforpeace@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.