Fix the following build warning seen with GCC
Compile [ 51.2%]: thread_bootstrap.c
[Warning] thread_extension.h@88,44: statement with no effect [-Wunused-value]
Fix the following build warning seen with both GCC and ARM_CC
[Warning] btle.cpp@115,0: #177-D: variable "clockConfiguration" was declared but never referenced
Fix the following build warning seen when building with GCC
Compile [ 54.2%]: icmpv6.c
[Warning] icmpv6.c@1091,16: this statement may fall through [-Wimplicit-fallthrough=]
An entropy source is required in order to use the PSA Crypto API. The
only devices Mbed OS knows are guaranteed by default to have an entropy
source are those devices with a TRNG. Don't enable the PSA Crypto API by
default for devices that Mbed OS can't know have an entropy source. This
avoids run-time errors when an entropy source is not present on these
targets.
Applications can add their own entropy source by place entropy into
their systems, implementing their own NV Seed read and write callbacks,
and then enabling the MBEDTLS_ENTROPY_NV_SEED configuration option to
notify the PSA Crypto implementation that an entropy source is present
and how to use it.
See https://os.mbed.com/docs/mbed-os/v5.11/porting/entropy-sources.html
for the background on why entropy is fundamental to system security and
how to inject entropy into systems that lack an on-board source of
entropy.
mbed_psa_reboot_and_request_new_security_state() API replaced its_reset() which is now a secure API only
This change is necessary for a clean environment for the test
Fix the following build warning
Compile [ 83.4%]: mbed_error.c
[Warning] mbed_error.c@71,21: 'compute_crc32' defined but not used [-Wunused-function]
compute_crc32 usage is guraded with #define, but not the definition.
Use the same #define around the definition of compute_crc32()
Fix this build warning seen when building with ARMCC
Compile [ 13.7%]: UBLOX_AT_CellularNetwork.cpp
[Warning] UBLOX_AT_CellularNetwork.cpp@65,0: #111-D: statement is unreachable
Aborting of asynchronous operation is necessarily hazardous, as
operation can end in interrupt anywhere from the point of decision
until it is actually aborted down the abort_...() method.
Proper deep sleep unlocking requires then use of the critical
section and should be contained completely within API implementation.
1. As RX and TX flows are separate on Serial device, read and write
functionalities should be completely separate, including any deep
sleep locking etc.
2. User may want to use asynchronous API without a callback (especially
for write operations), for example in a command-response scheme
end of write operation is usually meaningless. The intuitive
method is to submit NULL pointer for a callback. For this reason
depending on the _callback field in determining whether the
operation is in progress seems to be uncertain, so introduced
additional flags for this purpose.