[PATCH] mtd: cfi: Fix PPB lock status readout

[Joakim Tjernlund]

On Thu, 2021-04-15 at 07:25 +0200, Stefan Roese wrote:
> On 11.04.21 20:47, Marek Vasut wrote:
> > According to S26KL512S datasheet [1] and S29GL01GS datasheet [2],
> > the procedure to read out PPB lock bits is to send the PPB Entry,
> > PPB Read, Reset/ASO Exit. Currently, the code does send incorrect
> > PPB Entry, PPB Read and Reset/ASO Exit is completely missing.
> > 
> > The PPB Entry sent is implemented by sending flash_unlock_seq()
> > and flash_write_cmd(..., FLASH_CMD_READ_ID). This translates to
> > sequence 0x555:0xaa, 0x2aa:0x55, 0x555:0x90=FLASH_CMD_READ_ID.
> > However, both [1] and [2] specify the last byte of PPB Entry as
> > 0xc0=AMD_CMD_SET_PPB_ENTRY instead of 0x90=FLASH_CMD_READ_ID,
> > that is  0x555:0xaa, 0x2aa:0x55, 0x555:0xc0=AMD_CMD_SET_PPB_ENTRY.
> > Since this does make sense, this patch fixes it and thus also
> > aligns the code in flash_get_size() with flash_real_protect().
> > 
> > The PPB Read returns 00h in case of Protected state and 01h in case
> > of Unprotected state, according to [1] Note 83 and [2] Note 17, so
> > invert the result. Moreover, align the arguments with similar code
> > in flash_real_protect().
> > 

Just saw the PPB lock words passing by and remembered the problems we had with
u-boot using PPB to lock/unlock flash.

This method is slow and persistent(unlike the Intel method) and this carries
all the way to fw_setenv.

PPB will write to internal flash bits(same bits every time) and this causes wear
on said flash. We had disable flash lock/unlock here due to this wear.

The DYB method is a much better fit for u-boot/linux flash locking needs.

 Jocke