-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-threading flash access is not supported by flash_write_protection_set() #31217
Comments
@nvlsianpu Your proposed solution would not work for flash chip that automatically enables write protection after write or erase command. I have a custom board with such a flash chip and I'm impacted by this bug. The only solution I found so far is to hack the driver so that the lock is acquired by |
IMHO the only proper way to address this problem is to change the flash API. Removing the |
I think you understand me bad. I put the code sample in the description (same here https://docs.zephyrproject.org/latest/reference/peripherals/flash.html#c.flash_write_protection_set) - this code sample reflect usage with the automatic flash protection your mentioned, that why ther are dedicated flash disable calls before each write/erase operations. Solution I suggested will work for this case as well. API change you mentioned is also possible solution worth to be considered. |
@nvlsianpu, the thread awareness seems unnecessary complex. Maybe it is better to make |
@Laczen Agree, that will be much simpler but requires modification in each driver. I would go this way. Probably need to first present this on the API meeting. |
Maybe it is best to standardize to the way it is used in |
^^That's another option, and can be used besides |
API meeting 9th March 2021 Conclusion is to go with the approach described as Alternative 1: deprecate |
@carlescufi, agreed. |
The problem
When two or more threads writes to flash device it is possible that flash protection will be enabled by one of threads despite another thread(s) still needs it disabled.
Impact
flash_write() or flash_erase() operation might fail unexpectedly while flash device is written or erased from multiple thread. This will be race condition.
Solution
Remember that below code is allowed:
Count flash protection disable/enable operation (with thread instance awareness, a thread might only increase/decrease counter by one).
Re-enable protection only once is zero.
Solution Alternative 1
make
flash_write_protection_set()
a nop and to include this inflash_write()
andflash_erase()
.Solution Alternative 2
flash_write_protection_set()
reserves flash access for the caller. Looks like this approach can be combined with Solution Alternative 1.The text was updated successfully, but these errors were encountered: