adding support for locking on macronix flashes

[Rasmus Villemoes]

I need to add support for locking on macronix flashes. They don't quite
fit into the existing stm_*() functions, so I suppose I will have to
create a new family (mx_*lock*).

They do have the same SR_BP{0,1,2} bits, but also a fourth SR_BP3.
Moreover, they also support bottom protect, but the bit for that lives
in the configuration register, not the status register. Moreover, that
bit is OTP, so once set to bottom protect, the can_be_top logic would
always be false.

So, the problems I immediately run into:

(1) We're out of flag bits in struct flash_info. One can of course [a]
make flags a u32, but it seems a bit wrong to keep adding
vendor-specific flags.

I'm thinking either [b] the flash_info should grow a real "struct
flash_lock_ops *" member which can then point to (newly introduced)
"stm_lock_ops", "sst26_lock_ops" or "mx_lock_ops", or [c] one can add
the SPI_NOR_HAS_LOCK bit to all the chips that currently get the lock
ops via one of the first three clauses in

	if (JEDEC_MFR(info) == SNOR_MFR_ST ||
	    JEDEC_MFR(info) == SNOR_MFR_MICRON ||
	    JEDEC_MFR(info) == SNOR_MFR_SST ||
			info->flags & SPI_NOR_HAS_LOCK) {

and then inside the "if (info->flags & SPI_NOR_HAS_LOCK)" choose lock
ops based on JEDEC_MFR(info). Or [d] keep the above if() as-is, then
inside the block have a "if (JEDEC_MFR(info) == SNOR_MFR_MACRONIX)",
then just add the SPI_NOR_HAS_LOCK bit to the macronix flashes?

Which of [a,b,c,d] should I go for, or is there some [e] that is better?

(2) From a UI perspective, I don't know if a "sf protect lock" should be
allowed to set an OTP bit without some explicit opt-in. Thoughts?

Rasmus