b10428163a
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> |
||
|---|---|---|
| .. | ||
| audio | ||
| dfu | ||
| hid | ||
| netusb | ||
| CMakeLists.txt | ||
| Kconfig | ||
| Kconfig.bt | ||
| Kconfig.cdc | ||
| Kconfig.msc | ||
| Kconfig.template.composite_device_number | ||
| Kconfig.test | ||
| bluetooth.c | ||
| bt_h4.c | ||
| cdc_acm.c | ||
| loopback.c | ||
| msc.c | ||