All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.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:18:54 -0700	[thread overview]
Message-ID: <20170608231854.GF102137@google.com> (raw)
In-Reply-To: <92ffaa3cef7d49aeb9d5abae06e10ddb@svr-chch-ex1.atlnz.lc>

On Thu, Jun 01, 2017 at 11:08:08PM +0000, Chris Packham wrote:
> Do we need a flag to indicate SRAM-like properties? I assume there is a 
> difference between NO_ERASE on ROM devices where there is just no way of 
> erasing the data. For {S,F,M}RAM there is no block erase operation but 

I think we already have that:

#define MTD_CAP_ROM             0
#define MTD_CAP_RAM             (MTD_WRITEABLE | MTD_BIT_WRITEABLE | MTD_NO_ERASE)

The key signifier for ROM would be !MTD_WRITEABLE.

> you can overwrite data to destroy it (which is actually my use-case with 
> this SPI SRAM). I was tempted to set erase_size = 1 at one point which 
> in my mind was technically accurate but would probably upset the mtd 
> layer just as much as 0.

I'm not sure what erasesize should be here. I suppose 0, but really, I
think the MTD_NO_ERASE flag is the clearer indication that erase is not
needed, and that one should ignore the erasesize.

Brian

  reply	other threads:[~2017-06-08 23:19 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
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 [this message]
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=20170608231854.GF102137@google.com \
    --to=computersforpeace@gmail.com \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=andrew@lunn.ch \
    --cc=boris.brezillon@free-electrons.com \
    --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.