adding support for locking on macronix flashes

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
participants (1)
-
Rasmus Villemoes