All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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 16:33:21 +0300	[thread overview]
Message-ID: <540F01A1.3050903@ti.com> (raw)
In-Reply-To: <20140909132708.GA3315@arch.hh.imgtec.org>

On 09/09/2014 04:27 PM, Ezequiel Garcia wrote:
> 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.
> 

OK. Let's stick with your patch then.

cheers,
-roger

WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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 16:33:21 +0300	[thread overview]
Message-ID: <540F01A1.3050903@ti.com> (raw)
In-Reply-To: <20140909132708.GA3315@arch.hh.imgtec.org>

On 09/09/2014 04:27 PM, Ezequiel Garcia wrote:
> 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.
> 

OK. Let's stick with your patch then.

cheers,
-roger

  reply	other threads:[~2014-09-09 13:33 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
2014-09-09 13:27       ` Ezequiel Garcia
2014-09-09 13:33       ` Roger Quadros [this message]
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=540F01A1.3050903@ti.com \
    --to=rogerq@ti.com \
    --cc=computersforpeace@gmail.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=guido@vanguardiasur.com.ar \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --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.