Comment 330 for bug 1734147

I think the reason why 4.14.x works is because of commit 9d63f17661e2
("spi-nor: intel-spi: Fix broken software sequencing codes").

The current theory is that for certain serial flashes (those
with SPI_NOR_HAS_LOCK set in drivers/mtd/spi-nor/spi-nor.c) Linux
SPI-NOR core wants to clear the status register (SR) in addition to
reading the chip JEDEC ID. This is done to make sure protection bits
(BP0, BP1 and BP2) are cleared.

The sequence looks like this:

  WREN (write enable)
  WRSR with 0 (write status register)

However, the intel-spi driver had an off-by-one bug that causes it to
write two bytes instead of one. So the above sequence actually looks
like:

  WREN (write enable)
  WRSR with 0, X (write status register)

Where X is something that is in FDATA[1] FIFO. Most likely this is part
of the just read chip JEDEC ID. Now, WRSR command is weird in a sense
that it allows writing both the status register and the control
register even though there are separate commands to read them. If the X
above has bit 6 set we end up writing this to the control register which
means that we have:

  SR=0x00 CR=0x40

(CR value can be something else but bit 6 needs to be set)

Because BP0, BP1 and BP2 in SR are 0 and CMP in CR is 1, this means that
the whole chip becomes read-only (CMP complements BP0, BP1 and BP2) and
this prevents the BIOS from saving settings anymore.

The off-by-one bug was already fixed in the mainline kernel by
commit 9d63f17661e2 ("spi-nor: intel-spi: Fix broken software sequencing
codes") in September.