Usually flash drivers/controllers doesn't check whether what was requested to be write was written. As flash driver API implements
just write, it doesn't mean that corruption of written data will be detected as error by the driver.
Most of FS and storage system implementation assumes that write/erase operations are reliable (and they usually are).
If corrupted write or corrupted erase occurred then this is not visible for the storage layer. So storage need to read and check the content o its own, which actually is common problem. Also If a flash driver (or flash controller under it) already does the
check, the read operation will be just a waste of time. Looks like suitable will be to move that functionality to layer bellow.
solution part 1
Write with check and erase with check functions API can be introduced.
For flash drivers without write/erase verification build-in this API should read back procedures for check the content.
For drivers which already support checks under write API almost nothing needs to be done. This especially preferred for flash controller with check build-in.
flash driver glue layer might be able to decide which way is the case for the driver and works accordingly basing of a new callbacks fields in API table structures provided by shims.
shouldn't be extended by write check silently - read operation might be time costly as for seral flashes are.
solution part 2
Write with check and rewrite on corruption attempt function API
This would be extension to the Write with check API which perform another try of data write if flash content doesn't match (and the flash controller allows rewrites to same location).
I creating ticked for tracking input on the subject which anyone can provided.