From: David Woodhouse <dwmw2@infradead.org>
To: Todd Poynor <tpoynor@mvista.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Supporting flash that powers up locked
Date: Thu, 25 Nov 2004 09:36:21 +0000 [thread overview]
Message-ID: <1101375381.13352.22.camel@localhost.localdomain> (raw)
In-Reply-To: <41A53246.7040704@mvista.com>
On Wed, 2004-11-24 at 17:15 -0800, Todd Poynor wrote:
> David Woodhouse wrote:
> > We already have a bit to set in the partition flags to show that a
> > partition should be read-only.
>
> Yeah I saw that the bit is really an amalgam of
> MTD_CLEAR_BITS|MTD_SET_BITS that are also involved in other capability
> combos (MTD_CAP_NANDFLASH, et al) and wasn't sure if there were other
> side effects of messing with those at runtime.
No, we have it separately for partitions.
> > I'd rather do this with a blacklist of the chips which lock themselves,
> > and have the chip driver automatically unlock it at boot time and
> > suspend time (or automatically as required).
>
> I did receive some pushback when I previously tried to do something
> similar, since we'd often be unlocking bootloader firmware and such.
Look at the use of MTD_WRITEABLE in, e.g., solutionengine.c. We already
have a way to prevent accidental access to the bootloader.
When they made the locking automatic instead of remembering the previous
state, the whole point of it changed. It's no longer useful for
protecting bootloaders all by itself; you can't infer anything useful
from the fact that you found the flash locked.
On the new chips of which you speak, all the locking can do is give us a
little more protection against random read/write cycles causing damage
to the contents of the flash. So let's use it for that. Leave the flash
locked at most times, and unlock a sector as we need to use it.
--
dwmw2
next prev parent reply other threads:[~2004-11-25 9:36 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
2004-11-24 13:57 ` David Woodhouse
2004-11-25 1:15 ` Todd Poynor
2004-11-25 9:36 ` David Woodhouse [this message]
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=1101375381.13352.22.camel@localhost.localdomain \
--to=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tpoynor@mvista.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox