From: Brian Norris <computersforpeace@gmail.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>,
dwmw2@infradead.org, andrew@lunn.ch,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Subject: Re: [PATCH 3/4] mtd: mchp23k256: add partitioning support
Date: Thu, 8 Jun 2017 16:21:10 -0700 [thread overview]
Message-ID: <20170608232110.GG102137@google.com> (raw)
In-Reply-To: <20170602110406.49eda282@bbrezillon>
On Fri, Jun 02, 2017 at 11:04:06AM +0200, Boris Brezillon wrote:
> BTW, MTD_NO_ERASE is not the only problem we have with UBI or JFFS2.
> Are we guaranteed that an erase operation fills an eraseblock with
> ones? Don't we have mem technologies that are filling them with zeros?
> Note that mtdram is artificially setting the mem-region to 0xff in its
> dummy erase operation, so maybe it's a implicit rule that ->_erase() is
> supposed to fill eraseblocks with 0xff.
I've wondered about the general assumption. But mtdram isn't really a
good example, because it clearly calls itself a "test mtd device". So it
makes sense it would emulate common MTDs (i.e., flash memory).
Brian
next prev parent reply other threads:[~2017-06-08 23:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-17 5:39 [PATCH 0/4] mtd: mchp23k256: device tree and mchp23lcv1024 Chris Packham
2017-05-17 5:39 ` [PATCH 1/4] mtd: mchp23k256: Add OF device ID table Chris Packham
2017-05-17 5:39 ` Chris Packham
2017-05-17 11:44 ` Andrew Lunn
2017-05-17 11:44 ` Andrew Lunn
2017-05-17 5:39 ` [PATCH 2/4] mtd: mchp23k256: switch to mtd_device_register() Chris Packham
2017-05-17 11:48 ` Andrew Lunn
2017-05-17 5:39 ` [PATCH 3/4] mtd: mchp23k256: add partitioning support Chris Packham
2017-05-17 14:18 ` Andrew Lunn
2017-05-17 15:29 ` Boris Brezillon
2017-05-22 4:52 ` Chris Packham
2017-05-22 7:38 ` Boris Brezillon
2017-06-01 18:43 ` Brian Norris
2017-06-01 20:47 ` Boris Brezillon
2017-06-01 22:01 ` Brian Norris
2017-06-02 9:04 ` Boris Brezillon
2017-06-08 23:21 ` Brian Norris [this message]
2017-06-01 21:30 ` Chris Packham
2017-06-01 22:23 ` Brian Norris
2017-06-01 23:08 ` Chris Packham
2017-06-08 23:18 ` Brian Norris
2017-05-17 5:39 ` [PATCH 4/4] mtd: mchp23k256: Add support for mchp23lcv1024 Chris Packham
2017-05-17 12:17 ` Andrew Lunn
2017-05-18 4:36 ` Chris Packham
2017-05-18 4:36 ` Chris Packham
2017-05-17 11:41 ` [PATCH 0/4] mtd: mchp23k256: device tree and mchp23lcv1024 Andrew Lunn
2017-05-17 14:19 ` Andrew Lunn
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=20170608232110.GG102137@google.com \
--to=computersforpeace@gmail.com \
--cc=andrew@lunn.ch \
--cc=boris.brezillon@free-electrons.com \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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.