From: Sangmoon Kim <dogoil@etinsys.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] cfi_flash.c patches
Date: Tue, 23 Aug 2005 17:39:14 +0900 [thread overview]
Message-ID: <001001c5a7be$272a8510$212d4cdc@smkim> (raw)
In-Reply-To: 17162.52418.483528.710697@astp0002.localdomain
Dear Yuli Barcohen,
I'm almost exhausted by this topic. The patch is only an option.
It is just for convenience and consistency of environment variables between
boards.
It has nothing to do with any philosophy.
> If the above mentioned board designer chooses to use
> a boot block, he/she selects flash which is protected by default.
Bootblock and environment is protected again just after the unprotection.
Please check the code.
> If U-Boot must automatically change this behaviour,
It is not mandatory. It is an option again.
> why to use such a flash in the first place?
People do mistakes. And to currect it on software is easy.
Changing hardware is very expensive and time consuming.
Although I come to think changing software is more difficult sometimes
because of this issue.
> Regarding the implementation, unprotecting the flash
> on U-Boot's start up requires exactly the same operations as implemented
> in the flash_real_protect function (which is controlled by
> CFG_FLASH_PROTECTION) so IMHO the same function must be used for
> automatic unprotection too to avoid code duplication though I agree with
> Tolunay that defining CFG_FLASH_PROTECTION and calling "protect off" is
> the way to go.
>
flash_protect calls flash_real_protect if CFG_FLASH_PROTECTION is defined.
It is not a code duplication.
If flash_init tries to directly calls flash_real_protect without
CFG_FLASH_PROTECTION.
It produces compile time error because flash_real_protect is not defined
without CFG_FLASH_PROTECTION.
I don't think such dependency between configuration is a good
implementation.
If you still don't like the implementation just send a better patch.
Again, I don't really like to mess up with you because of some philosophy or
spirit.
Software engineering is just for convenience after all.
Best regards,
Sangmoon Kim
next prev parent reply other threads:[~2005-08-23 8:39 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
2005-08-22 22:46 ` Wolfgang Denk
2005-08-23 7:14 ` Yuli Barcohen
2005-08-23 8:39 ` Sangmoon Kim [this message]
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='001001c5a7be$272a8510$212d4cdc@smkim' \
--to=dogoil@etinsys.com \
--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