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.