We cannot just decrement the reference counter of power modes without
any coordination. First, this will trigger an `assert()`ion on non
STM32 MCUs that have power modes that are not used (the ref count would
be decremented below zero). Second, there hopefully is a reason a
certain power mode is blocked, e.g. because a periph driver needs a
certain clock to function.
Likely the `periph_uart` driver on STM32 boards keeps power modes
blocked after TX is completed even when no RX callback is present, which
is the waste of power this hack tries to address. But that should be
addressed there.
The Makefile rule to regenerate model.h has been left in place, but
just adding the header to the test allows to build the application
without heaving emlearn installed, which is convenient for the CI.
Actual users of emlearn will like still want to generate the header.
This explicitly spells out what informally has been the coding
convention for some time on preprocessor directives, making it
more transparent and easier to find.
This is particularly useful as the code base has at least three
different styles. Deducing what actually is the current policy
would require a details look at how the style has changed over
time, rather than being obvious from a quick `grep` over the
code base.
This formats the code to improve readability and apply the coding
convention. This is a whitespace only change that will not change
generated binaries.
Add some tests to verify that when creating or importing keys,
the usage flags PSA_KEY_USAGE_SIGN_HASH/PSA_KEY_USAGE_VERIFY_HASH
automatically set the usage flags PSA_KEY_USAGE_SIGN_MESSAGE/
PSA_KEY_USAGE_VERIFY_MESSAGE on the key.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Specifying the password of the SUIT private key on the command line
and thereby committing it to shell history is a security issue.
Instead ask for the password interactively when an encrypted private
key is used.
This makes it easier to work with encrypted keys and multiple keys.
The firmware binary can contain multiple public keys that are used
to verify the manifest.
The use case is that we want to include the production public key
in the debug build, so we can seamlessly update to the production
version without re-flashing the device.
If the public keys is always generated on the fly, this would still
require the production key password even for the debug build.
Instead if we store the (unencrypted) public key, we can always
include it in the debug build.
