On Thu, Oct 6, 2016 at 8:32 PM, George McCollister <[email protected]> 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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
