All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.