From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tolunay Orkun Date: Wed, 15 Mar 2006 19:13:05 -0600 Subject: [U-Boot-Users] flash protection code in cfi_flash In-Reply-To: <4dd15d180603150807x3ca2ab0bj7fec61d17d03cf6a@mail.gmail.com> References: <4dd15d180603141115g748f2303h9846f5d8b0e9b59e@mail.gmail.com> <20060314205857.E1235353A57@atlas.denx.de> <4dd15d180603150807x3ca2ab0bj7fec61d17d03cf6a@mail.gmail.com> Message-ID: <4418BBA1.7090102@orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de David Ho wrote: >>> I'm looking at the flash protection code in the cfi_flash driver, can >>> anyone tell me why it claims intel's unprotect unprotects all locking? >>> Certainly my K3 flash can unlock on a per block basis. >> Which exactl line(s) of code are you alking about? > > Inside flash_real_protect in cfi_flash.c from your gitweb. > Line# 671 to 679 > > If you haven't noticed this function has not changed since the intial commit. > 5653fc335a450fa46d89989e1afe5e8bb9a0a52e > > If no one has any objection, I will remove the part of the code that > relock each sector, for submission. I do object! First, That behavior is required because some Intel flash parts incorrectly unlock all sectors (not just current sector) so after unlocking the current sector we must redo the locking of all others that were supposed to remain locked. Again, the comment in that code reflects and explains this. Secondly, AMD parts did not previously support real locking/unlocking so CFG_FLASH_PROTECTION option (which is needed to get the code you are talking) was not applicable for those parts. If that code now needs to be fixed for other parts that has this capability, fix it without breaking existing code. Thirdly, even in its current form, has this code caused any problem at all? It just unnecessarily re-locks all those sectors/blocks that are supposed to remain locked wasting some time at the execution of "protect off" command. Best regards, Tolunay