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.
next prev parent 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.