From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Roger Quadros <rogerq@ti.com>
Cc: "Tony Lindgren" <tony@atomide.com>,
linux-omap@vger.kernel.org,
"Brian Norris" <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org,
"Guido Martínez" <guido@vanguardiasur.com.ar>
Subject: Re: [PATCH v2 1/3] nand: omap2: Add support for flash-based bad block table
Date: Tue, 9 Sep 2014 10:27:08 -0300 [thread overview]
Message-ID: <20140909132708.GA3315@arch.hh.imgtec.org> (raw)
In-Reply-To: <540EBBEC.0@ti.com>
On 09 Sep 11:35 AM, Roger Quadros wrote:
> Ezequiel,
>
> On 09/08/2014 02:27 PM, Ezequiel Garcia wrote:
> > This commit adds a new platform-data boolean property that enables use
> > of a flash-based bad block table. This can also be enabled by setting
> > the 'nand-on-flash-bbt' devicetree property.
>
> I'm not much aware of how on-flash-BBT works internally, but will it break things if
> we keep on-flash-BBT "enabled" as the default option and add a DT property only to
> explicitly disable the on-flash-BBT?
>
No, that wouldn't work because the DT property already exists and it works to
enable the flash BBT when it's present.
Documentation/devicetree/bindings/mtd/nand.txt
Of course, we can add a new no-nand-on-flash-bbt, but I really don't see the
point. Users can just put the property in all the devicetree board files where
it's needed.
And moreover, I don't want to change the default behavior of the driver; it's
better to allow to *add* a new feature, if such feature is desired.
Otherwise, users with some data in a flash's last blocks would be wiped and
replaced with the BBT.
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Roger Quadros <rogerq@ti.com>
Cc: "Brian Norris" <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org,
"Guido Martínez" <guido@vanguardiasur.com.ar>,
"Tony Lindgren" <tony@atomide.com>,
linux-omap@vger.kernel.org
Subject: Re: [PATCH v2 1/3] nand: omap2: Add support for flash-based bad block table
Date: Tue, 9 Sep 2014 10:27:08 -0300 [thread overview]
Message-ID: <20140909132708.GA3315@arch.hh.imgtec.org> (raw)
In-Reply-To: <540EBBEC.0@ti.com>
On 09 Sep 11:35 AM, Roger Quadros wrote:
> Ezequiel,
>
> On 09/08/2014 02:27 PM, Ezequiel Garcia wrote:
> > This commit adds a new platform-data boolean property that enables use
> > of a flash-based bad block table. This can also be enabled by setting
> > the 'nand-on-flash-bbt' devicetree property.
>
> I'm not much aware of how on-flash-BBT works internally, but will it break things if
> we keep on-flash-BBT "enabled" as the default option and add a DT property only to
> explicitly disable the on-flash-BBT?
>
No, that wouldn't work because the DT property already exists and it works to
enable the flash BBT when it's present.
Documentation/devicetree/bindings/mtd/nand.txt
Of course, we can add a new no-nand-on-flash-bbt, but I really don't see the
point. Users can just put the property in all the devicetree board files where
it's needed.
And moreover, I don't want to change the default behavior of the driver; it's
better to allow to *add* a new feature, if such feature is desired.
Otherwise, users with some data in a flash's last blocks would be wiped and
replaced with the BBT.
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
next prev parent reply other threads:[~2014-09-09 13:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-08 11:27 [PATCH v2 0/3] nand: omap2: Two and a half improvements Ezequiel Garcia
2014-09-08 11:27 ` Ezequiel Garcia
2014-09-08 11:27 ` [PATCH v2 1/3] nand: omap2: Add support for flash-based bad block table Ezequiel Garcia
2014-09-08 11:27 ` Ezequiel Garcia
2014-09-09 8:35 ` Roger Quadros
2014-09-09 8:35 ` Roger Quadros
2014-09-09 13:27 ` Ezequiel Garcia [this message]
2014-09-09 13:27 ` Ezequiel Garcia
2014-09-09 13:33 ` Roger Quadros
2014-09-09 13:33 ` Roger Quadros
2014-09-08 11:27 ` [PATCH v2 2/3] nand: omap2: Remove horrible ifdefs to fix module probe Ezequiel Garcia
2014-09-08 11:27 ` Ezequiel Garcia
2014-09-08 11:27 ` [PATCH v2 3/3] nand: omap2: Replace pr_err with dev_err Ezequiel Garcia
2014-09-08 11:27 ` Ezequiel Garcia
2014-09-08 11:57 ` Roger Quadros
2014-09-08 11:57 ` Roger Quadros
2014-09-08 14:35 ` Ezequiel Garcia
2014-09-08 14:35 ` Ezequiel Garcia
2014-09-09 8:33 ` Roger Quadros
2014-09-09 8:33 ` Roger Quadros
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=20140909132708.GA3315@arch.hh.imgtec.org \
--to=ezequiel@vanguardiasur.com.ar \
--cc=computersforpeace@gmail.com \
--cc=guido@vanguardiasur.com.ar \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=rogerq@ti.com \
--cc=tony@atomide.com \
/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.