On Thu, Oct 6, 2016 at 10:27 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Thu, Oct 6, 2016 at 8:32 PM, George McCollister george.mccollister@gmail.com wrote:
I'm looking into adding a sub-command to sf to protect status registers on Winbond SPI flash parts via the status register protect bits SRP0, SRP1. I propose the sub-command be named sr-protect.
My use case is simple, I want to make the SPI flash read-only when the /WP pin is low. To do this I must do 'sf protect lock 0 $size' then set SRP0 to 1 and hold the /WP pin low. Although my use case doesn't require it, setting SRP1 to 1 allows either Power Supply Lock-Down or One Time Program (if supported by hardware) and I would probably add support for these as well.
All of the current Winbond SPI NOR flash part datasheets that I've looked at show that the parts support the same locking implemented in stm_lock() even though SPI_FLASH_CFI_MFR_WINBOND is not in the list of vendors which use the function. I'll change this to make SPI_FLASH_CFI_MFR_WINBOND parts use stm_lock(), stm_unlock(), stm_is_locked().
Does stm_lock can't protect the Winbond? how different is in the process of doing when compared to stm?
stm_lock() does work with the Winbond parts. The issue is that you can simply unlock from software (stm_unlock). To make it impossible to write to the flash from software you must use stm_lock() then use the status register protect bits to prevent an unlock.
spi_flash_protect() (which ultimately calls either stm_lock() or stm_unlock()) is not part of the driver model (dm_spi_flash_ops). Is there any issue with adding another function (let's call it spi_flash_sr_protect) that is not part of the driver model?
Why spi_flash_sr_protect, why can't existing stm_lock?
Explained above.
thanks!
Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.