From: Todd Poynor <tpoynor@mvista.com>
To: Josh Boyer <jdub@us.ibm.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Supporting flash that powers up locked
Date: Wed, 24 Nov 2004 16:37:36 -0800 [thread overview]
Message-ID: <41A52950.4070600@mvista.com> (raw)
In-Reply-To: <1101301663.22829.3.camel@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 2004-11-23 at 16:25, Todd Poynor wrote:
>
> <snip>
>
>>If anyone has any suggestions or comments as to why this wouldn't work
>>for their device or usage model or why this isn't the right way to go
>>about things then I'd appreciate it, thanks. -- Todd
>
>
> Not everyone uses mtd partitions...
Unfortunately options for doing anything terribly intelligent about it
seem to be few in such a case. If somebody wants MTD to automatically
figure out what the proper locking status is for these chips then the
partition map is the only thing we've got to go on (at present anyhow).
So it could be argued that by not using partitions you've decided to
handle it yourself (such as explicit flash_unlock of needed ranges after
userspace startup). I'm guessing that some new way of specifying what
areas of flash are intended to be writeable vs. read-only, apart from
the existing partition maps, would not be well received. But if there
is some nifty way of doing this outside the partition framework then I'm
interested. And doing nothing or doing something simplistic are
certainly options as well. Thanks,
--
Todd
next prev parent reply other threads:[~2004-11-25 0:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-23 22:25 Supporting flash that powers up locked Todd Poynor
2004-11-24 13:07 ` Josh Boyer
2004-11-25 0:37 ` Todd Poynor [this message]
2004-11-24 13:57 ` David Woodhouse
2004-11-25 1:15 ` Todd Poynor
2004-11-25 9:36 ` David Woodhouse
2004-12-01 3:50 ` Todd Poynor
-- strict thread matches above, loose matches on Subject: below --
2007-03-19 8:44 supporting " Rodolfo Giometti
2007-03-21 13:25 ` Josh Boyer
2007-03-21 15:09 ` Rodolfo Giometti
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=41A52950.4070600@mvista.com \
--to=tpoynor@mvista.com \
--cc=jdub@us.ibm.com \
--cc=linux-mtd@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox