The driver is pretty old. There may be some exceptional cases that worked like this a long time ago, or maybe some odd flash from a different series than we use. Anyway:

> it's not desireable to change these bits unexpectedly

I agree.

> We can probably just add a devicetree variable for jedec,spi-nor devices

There's already sort of a flag for this. See "lock":

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/partition.txt#L35

That's currently only supported for partitions, and not on every driver.

I can look at cleaning that up.

Oh BTW, I think one reason other people might want the current behavior: if they want to be able to mount a R/W filesystem from NOR flash immediately (without some initramfs code to unlock the device before mounting). So supporting the above optional flag seems reasonable.

Re #2: Yep, "lock" seems to be what we want if it can be supported in spi-nor easily.

Re #3: That makes perfect sense. The comment is still rather misleading IMO given our use case, but the explanation you provided sounds good. Not sure if it's worth putting effort into re-wording it upstream.

Thanks for checking into this!

I still don't really get it... what does "tend to power up with the bits set" mean? Aren't these bits supposed to be sticky? Isn't the whole block protection mechanism based on the status register being persistent? In that case I also don't see how wanting it writeable immediately would matter... wouldn't you just turn off the protection in that case and it should stay off across reboots?

According to my usual motto "if you can't figure out why it is written that way, assume that whoever wrote it had no clue what they were doing", I'd suggest trying to take it out completely first. If anyone upstream complains they can tell you which parts exactly behave in this way, if any. I think chances are that nobody will care because this probably didn't make any sense in the first place.

Re #5: I think that's just leftover from some very old chips where the scheme was to have software WP block erase/write operations even if hardware /WP is not asserted. AFAIK this is just a naive protection for noisy environments and multi-slave SPI channels. An example is the AMIC A25L020: http://www.amictechnology.com/datasheets/A25L020.pdf (table 7).

Flashrom also attempts to clear those bits, but it restores them when it's done. Perhaps the same method can be applied to the kernel where block protect is changed only when an erase/write operation is requested instead of lazily clobbering them at startup. That would at least be more consistent with the intention of the scheme on old chips since the chip won't be left totally unprotected when content is not being changed, although there would be performance penalty due to the extra transactions that might be significant if the NOR flash is used as a filesystem or some such.

This was obviously not time critical...