19523: boards/iotlab-m3: enable l3g4200d_ng r=benpicco a=benpicco
19527: drivers/sdcard_spi: small cleanup r=benpicco a=gschorcht
### Contribution description
This PR provides a small cleanup:
- the copy of `sdcard_spi_params_t` is removed (commit bfc2a51f70)
- the documentation was changed to fit the 100 characters per line. (commit 36f0162b34)
It is not necessary to hold a complete copy `sdcard_spi_params_t` in the device descriptor. Constant parameters can be used directly from ROM instead. This saves 24 bytes of RAM.
### Testing procedure
Use any board with SD Card SPI interface. The driver test should still work, for example:
```
BOARD=esp32-wrover-kit make -j8 -C tests/driver_sdcard_spi flash term
```
```
main(): This is RIOT! (Version: 2023.07-devel-176-g7213c-drivers/sdcard_spi_cleanup)
SD-card spi driver test application
insert SD-card and use 'init' command to set card to spi mode
WARNING: using 'write' or 'copy' commands WILL overwrite data on your sd-card and
almost for sure corrupt existing filesystems, partitions and contained data!
> init
Initializing SD-card at SPI_0...
[OK]
>
```
### Issues/PRs references
19530: sys/xtimer: add missing "modules.h" include to `xtimer.h` r=benpicco a=kaspar030
19532: tests/unittests: tests-core-mbox: add missing `container.h` include r=benpicco a=kaspar030
19533: core: move macros/math.h to core/lib/include/macros r=benpicco a=kaspar030
19535: nanocoap_sock: defuse nanocoap_sock_get() API footgun r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19485: sys/shell: Fix missing dependency r=aabadie a=maribu
### Contribution description
The shell commands depend on the shell module being use. This was already the case in KConfig, but was overlooked in the shell's `Makefile.dep`.
In addition, this uncovered that `tests/memarray` had a bogus dependency on shell commands without every using the shell.
### Testing procedure
Ideally binaries should not differ (except for debug section).
### Issues/PRs references
Split out of https://github.com/RIOT-OS/RIOT/pull/19483
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19488: usbus: remove deprecated USBUS_HANDLER_FLAG_TR_FAIL flag r=gschorcht a=dylad
### Contribution description
This PR removes the deprecated `USBUS_HANDLER_FLAG_TR_FAIL` flag.
### Testing procedure
CI should be enough.
### Issues/PRs references
Was deprecated by #17046
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
The shell_cmds module depends on the shell module. This was correctly
added to KConfig, but the Makefile dependencies missed this one. This
commit adds the missing dep.
19436: cpp11-compat: thread::sleep_for in microseconds r=benpicco a=kfessel
### Contribution description
after reviewing #19369 i found that there is a conversion to nanoseconds just to convert it to microseconds some instrunctions later for ztimer64_usec to handle it this removes one of the conversions (convert once direct to microseconds)
### Testing procedure
run the cpp tests
### Issues/PRs references
#19369
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Use symbol `USBDEV_SET_ADDR_AFTER_STATUS` to determine whether the device address has to be set directly after SETUP stage or after the associated STATUS stage.
This extends support for the GET STATUS requests to support endpoints
and interfaces as recipient. It also adds the SET and CLEAR FEATURE
requests for the endpoints with support to set and clear the halt
condition on an endpoint.
Instead of directly stalling an endpoint, handlers should enable the
halt condition on an usbus endpoint to signal error condition.
This can then be cleared via a CLEAR FEATURE request from the host.
This function should not be called by the driver as USBUS will handle it already. So remove this call to prevent duplication
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19402: sys/net/gnrc/netif: fixing no global address wait r=benpicco a=jan-mo
### Contribution description
The function `gnrc_netif_ipv6_wait_global_address()` will always return true, even if no global address is attached to the interface.
Currently the function only waits for any message and does not check if it was from the bus or not. So in `msg.content.ptr` is no valid address and therefore it returns true.
I added just the check, if the message is from the bus of any interface and then checking the address. We could also first check if the address in `msg.content.ptr` is valid, but this will just hide the bug. Also the timeout was never checked. It was just assuming that no other message will be received during the wait.
### Testing procedure
Use two devices, one works as a border router and supports the global address, the other will wait for the global address. You can call the function `gnrc_netif_ipv6_wait_global_address()` on the waiting node and see whether it returns true and finds the global address in the given time-range.
19404: sys/trickle: cleanup deps r=benpicco a=MrKevinWeiss
### Contribution description
Cleans the dependencies of the `trickle` module. This removes the deprecated xtimer and models kconfig.
### Testing procedure
Green murdock
### Issues/PRs references
19405: cpu/efm32: pwm_init errors are zeros r=benpicco a=chrysn
### Contribution description
pwm_init is documented to return 0 on errors, and has an unsigned return value.
EFM32's initialization function returned negative values, which through implicit casting become 0xffffffff or 0xfffffffe, which are successful by the documentation.
This makes all the EFM32 error paths return 0 as they should.
Also, it fixes a variable name and the corresponding error message that used to talk of "initiation" (which would be the start of a process) rather than "initialization" (which is a process that is completed before something else can happen).
### Testing procedure
* on stk3700, tests/periph_pwm, run `init 0 0 10 1000` / `set 0 0 500`
* The init used to respond with "The pwm frequency is set to 4294967294", and the set does nothing.
* The init now responds with "Error: device is not <del>initiated</del><ins>initialized</ins>". The set still does nothing, but then one doesn't expect it to any more.
(But really, looking at the patch and the docs should suffice).
### Issues/PRs references
By-catch from testing the Rust wrappers provided by `@remmirad` at https://github.com/RIOT-OS/rust-riot-wrappers/pull/38
Co-authored-by: Jan Mohr <jan.mohr@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: chrysn <chrysn@fsfe.org>
