[U-Boot] sf: proposed status register protect

[Jagan Teki]

On Thu, Oct 6, 2016 at 8:32 PM, George McCollister
<george.mccollister at 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?

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

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.