From: "Timofei V. Bondarenko" <timm@ipi.ac.ru>
To: Todd Poynor <tpoynor@mvista.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: nand locking
Date: Thu, 28 Apr 2005 11:00:15 +0400 [thread overview]
Message-ID: <427089FF.4020704@ipi.ac.ru> (raw)
In-Reply-To: <426FD97D.9000105@mvista.com>
Todd Poynor wrote:
> Timofei V. Bondarenko wrote:
>
>> It would be nice to unlock the rw partitions only.
>> After add_mtd_partitions() my startap code has no handle to actual
>> partition info.
>> The mtd_partition.mtdp seems only choice, though it prevents
>> partitions from registering...
>> So, could couple of lines in add_mtd_partitions() do that work?
>
> If I understand correctly, it may be the same issue I ran into on Intel
> NOR flash: the chip driver (which may have the knowledge of whether the
> particular chips are locked or lockable) gets to see the "whole device"
> struct mtd_info at probe time, but doesn't see the "partition" structs
> registered later via add_mtd_partitions(), which have the per-partition
> r/w flags.
Yes, exactly.
> I tried adding a callback to the chip driver at each device/partition
> add (see first patch attempt in recent "Fixup Intel flash that powers up
> locked" thread). But I believe that was part of what was (justifiably)
> deemed messy about the patch.
Do you mean 'mtd_info::notify_add' ?
I've mentioned the 'mtd_partition::mtdp' - it could be an alternative
(a bit complicated though). The register_mtd_user() also may help...
> So far the general verdict on these flashes that power up locked seems
> to be either leave all blocks locked or unlock all blocks (either in the
> bootloader or at flash probe time), and let custom code in userspace
> lock/unlock what is needed. I do like the idea of the kernel rectifying
> lock status with the map flags myself, though...
I'm not complaining about.
--
Timofei
next prev parent reply other threads:[~2005-04-28 7:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-27 7:34 nand locking Timofei V. Bondarenko
2005-04-27 9:00 ` Thomas Gleixner
2005-04-27 9:09 ` Timofei V. Bondarenko
2005-04-27 10:45 ` Thomas Gleixner
2005-04-27 10:27 ` Timofei V. Bondarenko
2005-04-27 10:32 ` Artem B. Bityuckiy
2005-04-27 11:35 ` Thomas Gleixner
2005-04-27 11:19 ` Timofei V. Bondarenko
2005-04-27 18:27 ` Todd Poynor
2005-04-28 7:00 ` Timofei V. Bondarenko [this message]
2005-04-29 22:19 ` Todd Poynor
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=427089FF.4020704@ipi.ac.ru \
--to=timm@ipi.ac.ru \
--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 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.