From: Tolunay Orkun <listmember@orkun.us>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] cfi_flash.c patches
Date: Mon, 22 Aug 2005 17:05:32 -0500 [thread overview]
Message-ID: <430A4C2C.60506@orkun.us> (raw)
In-Reply-To: <20050822205352.099A2353D18@atlas.denx.de>
Dear Wolfgang,
Wolfgang Denk wrote:
>Because there simply *is* *no* policy at all. Especially not in a
>
>
That is not true. There are several policies already.
Just a couple of emails ago you were saying all sectors should be in
writable state in U-Boot. This is a policy which is announced today by you.
Leaving the state of sectors (except for U-Boot managed sectors) until
user takes explicit lock/unlock action as they are is another policy .
This has been the policy so far which I would call "common sense" policy.
Providing software protection for flash that does not have hardware
protection is yet another policy.
>one-size-fits-all driver like cfi_flash which is what we are talking
>about.
>
>If you have special requirements please feel free to implement these
>in your board specific code. But don't try to enforce your special
>ideas of how things should be on everybody else.
>
>
I am not trying to implement anything. Existing code works well for me
(well after a couple of fixes which I submitted a patch for).
It is the new patch (not from me) that is introducing new policies and
ways that needs to be questioned and discussed since it is effecting a
common driver. This new patch is enforcing new ideas and policies. I've
raised a number of issue with the new approach which you see to
conveniently avoided. Could you please answer the following?
Why do you think it is OK for U-Boot to unlock sectors/blocks that it
knows nothing about their usage? Wouldn't leaving these sectors in a
safer state a common sense approach?
While you see it important to protect U-Boot environment (for various
reasons and I agree), you do not seem to consider consistent protection
for another area of flash that may be storing equally vital information
for software system. Why?
Best regards,
Tolunay
Note: I had submitted a bug fix on July 2nd for a number of cfi_flash.c
fixes. Do you still have that in your queue? I was expecting it would go
to 1.1.3 since you picked some other fixes to go in that release. I am
now worried that it is lost somewhere.
http://sourceforge.net/mailarchive/message.php?msg_id=12234135
next prev parent reply other threads:[~2005-08-22 22:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-19 4:27 [U-Boot-Users] [PATCH] cfi_flash.c patches Sangmoon Kim
2005-08-19 18:36 ` Tolunay Orkun
2005-08-22 5:37 ` Sangmoon Kim
2005-08-22 6:31 ` Tolunay Orkun
2005-08-22 7:13 ` Sangmoon Kim
2005-08-22 15:37 ` Tolunay Orkun
2005-08-22 16:17 ` Wolfgang Denk
2005-08-22 16:49 ` Tolunay Orkun
2005-08-22 20:49 ` Wolfgang Denk
2005-08-22 16:41 ` Scott McNutt
2005-08-23 1:53 ` Sangmoon Kim
2005-08-22 7:58 ` Wolfgang Denk
2005-08-22 17:02 ` Tolunay Orkun
2005-08-22 20:53 ` Wolfgang Denk
2005-08-22 22:05 ` Tolunay Orkun [this message]
2005-08-22 22:46 ` Wolfgang Denk
2005-08-23 7:14 ` Yuli Barcohen
2005-08-23 8:39 ` Sangmoon Kim
2005-08-23 14:47 ` Brian Waite
2005-08-23 20:24 ` Wolfgang Denk
2005-08-24 5:58 ` Yuli Barcohen
2005-08-24 16:00 ` Detlev Zundel
2005-08-24 21:52 ` Tolunay Orkun
2005-08-24 23:12 ` Wolfgang Denk
2005-08-25 14:37 ` Brian Waite
2005-08-25 16:37 ` Tolunay Orkun
2005-08-26 14:12 ` U-Boot policy on flash protection (was [U-Boot-Users] [PATCH] cfi_flash.c patches) Detlev Zundel
2005-08-26 14:45 ` Wolfgang Denk
2006-02-28 16:34 ` [U-Boot-Users] [PATCH] cfi_flash.c patches Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2005-08-19 18:47 Woodruff, Richard
2005-08-19 20:16 ` Tolunay Orkun
2005-08-19 20:22 Woodruff, Richard
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=430A4C2C.60506@orkun.us \
--to=listmember@orkun.us \
--cc=u-boot@lists.denx.de \
/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