zephyr/drivers/crypto
James Harris b10428163a kernel: sem: add K_SEM_MAX_LIMIT
Currently there is no way to distinguish between a caller
explicitly asking for a semaphore with a limit that
happens to be `UINT_MAX` and a semaphore that just
has a limit "as large as possible".

Add `K_SEM_MAX_LIMIT`, currently defined to `UINT_MAX`, and akin
to `K_FOREVER` versus just passing some very large wait time.

In addition, the `k_sem_*` APIs were type-confused, where
the internal data structure was `uint32_t`, but the APIs took
and returned `unsigned int`. This changes the underlying data
structure to also use `unsigned int`, as changing the APIs
would be a (potentially) breaking change.

These changes are backwards-compatible, but it is strongly suggested
to take a quick scan for `k_sem_init` and `K_SEM_DEFINE` calls with
`UINT_MAX` (or `UINT32_MAX`) and replace them with `K_SEM_MAX_LIMIT`
where appropriate.

Signed-off-by: James Harris <james.harris@intel.com>
2021-03-05 08:13:53 -06:00
..
CMakeLists.txt
Kconfig
Kconfig.ataes132a
Kconfig.nrf_ecb drivers: crypto_nrf_ecb: Convert to use devicetree 2021-01-13 12:57:13 +01:00
Kconfig.stm32
crypto_ataes132a.c kernel: sem: add K_SEM_MAX_LIMIT 2021-03-05 08:13:53 -06:00
crypto_ataes132a_priv.h
crypto_mtls_shim.c
crypto_nrf_ecb.c drivers: crypto_nrf_ecb: Convert to use devicetree 2021-01-13 12:57:13 +01:00
crypto_stm32.c soc: stm32: convert to use DEVICE_DT_GET for clocks 2021-02-16 17:01:37 -06:00
crypto_stm32_priv.h
crypto_tc_shim.c
crypto_tc_shim_priv.h