Hi all, Chao, please no top-post on mailing list. Also check your mail client, it seems to inject a lot of bogus newlines.
On 08.09.21 06:55, chaochao2021666 wrote: > > > > HI Jagan > > > > sorry for the delay response. > > > And I have checked the maser. There is still a problem with this feature。 > > > reproduce steps: > 1. enable the flash protect function > 2. using sf cmd to erase the flash. I can get the erase "OK",not the "error". > > > > I think the root cause is that the detection mechanism is missing and to > judge the permissions of the action > > So pull this PR to improve the erase flow > > > another question: > how can I visit the u-boot-spi/next? do there any link? > See MAINTAINERS: https://source.denx.de/u-boot/custodians/u-boot-spi.git But also that tree contains no usage of the flash_is_locked callback. That was once evaluated by drivers/mtd/spi/spi_flash.c but then forgotten in the new SPI NOR framework it seems. Chao's patch makes sense to me to restore this feature. Jan > > > > > BRs > Chao > > > > At 2021-06-29 21:50:28, "Jagan Teki" <[email protected]> wrote: >> On Tue, Jun 22, 2021 at 10:51 AM chao zeng <[email protected]> wrote: >>> >>> From: Chao Zeng <[email protected]> >>> >>> When operating the write-protection flash,spi_flash_std_write() and >>> spi_flash_std_erase() would return wrong result.The flash is protected, >>> but write or erase the flash would show "OK". >>> >>> Check the flash write protection state if the write-protection has enbale >>> before operating the flash. >>> >>> Signed-off-by: Chao Zeng <[email protected]> >>> --- >> >> Does it broken on master? if yes can you check in u-boot-spi/next? >> >> Jagan. -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
