errors: move nrfx error enum to bm #318
Draft
+20
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since nrfx is to remove its custom error codes with 4.0 release, error typedef enum has to be moved to bm if intended to still use the symbols.
With nrfx 4.0, we intend to completely remove
nrfx_err_t
enum and return errno values in the drivers in order to get rid of costly error translation in Zephyr drivers. I see two solutions1. Moving the enum (done in this PR, very preferrable)
If nrf-bm is to still use
nrfx_err_t
enum, it would have to be defined here (I assume thatnrf_error.h
header is the appropriate location). With nrfx drivers returning errno values (0 or negative e.g.-ECANCELED
), these would be mapped to the enum. The errors in nrfx would either be replaced 1:1 (e.g. every return ofNRFX_ERROR_INTERNAL
would be changed to-ECANCELED
) or the specific error could get changed to better reflect meaning associated with errno value. Its drawbacks are imperfect value mapping and potenitally big effort to align the two projects.2. Using conditional values in nrfx
In current form, nrfx supports usage of custom error codes with
NRFX_CUSTOM_ERROR_CODES
. If nrf-bm rejects the first variant, we could preserve the error code enum in nrfx which could take both errno values and legacy values to align with both Zephyr drivers and nrf-bm. The drawback would be keeping the layer of abstraction that we want to get rid of.Also, I see that nrf-bm code uses three variants of error codes :
nrfx_err_t
insdk-nrf-bm/include/bm_lpuarte.h
Lines 96 to 110 in 60df6af
sdk-nrf-bm/lib/bm_timer/bm_timer.c
Lines 76 to 85 in 60df6af
sdk-nrf-bm/include/bm_storage.h
Lines 138 to 151 in 60df6af
Is there a pattern to it?
nrfx_err_t
for drivers and errno for libs?