-
Brian Norris authored
This code was a bit sloppy, would produce a lot of copy-and-paste, and did not always provide a sensible interface: * It didn't validate the length for LOCK and the offset for UNLOCK, so we were essentially discarding half of the user-supplied data and assuming what they wanted to lock/unlock * It didn't do very good error checking * It didn't make use of the fact that this operation works on power-of-two dimensions So, rewrite this to do proper bit arithmetic rather than a bunch of hard-coded condition tables. Now we have: * More comments on how this was derived * Notes on what is (and isn't) supported * A more exendible function, so we could add support for other protection ranges * More accurate locking - e.g., suppose the top quadrant is locked (75% to 100%); then in the following cases, case (a) will succeed but (b) will not (return -EINVAL): (a) user requests lock 3rd quadrant (50% to 75%) (b) user requests lock 3rd quadrant, minus a few blocks (e.g., 50% to 73%) Case (b) *should* fail, since we'd have to lock blocks that weren't requested. But the old implementation didn't know the difference and would lock the entire second half (50% to 100%) This refactoring work will also help enable the addition of mtd_is_locked() support and potentially the support of bottom boot protection (TB=1). Signed-off-by: Brian Norris <computersforpeace@gmail.com>
62593cf4