drivers: flash: Introduce API function for flash extended operations

Besides of standard flash operations like write or erase, flash
controllers also support additional features like write protection or
readout protection. These features are not available in every flash
controller, what's more controllers can implement it in a different way.

It doesn't make sense to add a separate flash API function for every
flash controller feature, because it could be unique (supported on small
number of flash controllers) or the API won't be able to represent the
same feature on every flash controller.

Extended operation interface provides flexible way for supporting flash
controller features. Code space is divided equally into Zephyr codes
(MSb == 0) and vendor codes (MSb == 1). This way we can easily add
extended operations to the drivers without cluttering the API or
problems with API incompatibility. Extended operation can be promoted
from vendor codes to Zephyr codes if the feature is available in most
flash controllers and can be represented in the same way.

Signed-off-by: Patryk Duda <pdk@semihalf.com>
This commit is contained in:
Patryk Duda 2022-11-10 14:38:47 +01:00 committed by Carles Cufí
commit 8a85f0e87f
3 changed files with 99 additions and 0 deletions

View file

@ -98,3 +98,22 @@ static inline int z_vrfy_flash_read_jedec_id(const struct device *dev,
#include <syscalls/flash_sfdp_jedec_id.c>
#endif /* CONFIG_FLASH_JESD216_API */
#ifdef CONFIG_FLASH_EX_OP_ENABLED
static inline int z_vrfy_flash_ex_op(const struct device *dev, uint16_t code,
const uintptr_t in, void *out)
{
Z_OOPS(Z_SYSCALL_DRIVER_FLASH(dev, ex_op));
/*
* If the code is a vendor code, then ex_op function have to perform
* verification. Zephyr codes should be verified here, but currently
* there are no Zephyr extended codes yet.
*/
return z_impl_flash_ex_op(dev, code, in, out);
}
#include <syscalls/flash_ex_op_mrsh.c>
#endif /* CONFIG_FLASH_EX_OP_ENABLED */