19394: tests/rmutex: Drop output dump from README.md r=maribu a=maribu
### Contribution description
We use test scripts to automatically classify the output of a test application as passing / failing. Users are not expected to manually compare the output with a dump of the output in a readme.
### Testing procedure
Doesn't apply
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/19140
Fixes https://github.com/RIOT-OS/RIOT/issues/19298
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad a=gschorcht
### Contribution description
This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device.
#### Background
In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work.
#### Solution
Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert.
### Testing procedure
1. Green CI
2. Compilation of
```python
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm
```
should lead to compilation error
```python
sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded"
_Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS,
^~~~~~~~~~~~~~
Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed
```
while compilation of
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm
```
should work.
### Issues/PRs references
Fixes issue #19359 partially.
19382: tests/pkg_nanors: use static allocation r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=gschorcht a=gschorcht
### Contribution description
This PR disables the DMA mode for HS cores due to several problems found:
- The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in https://github.com/RIOT-OS/RIOT/pull/17085#issuecomment-1464928744
- The Enumeration fails for CDC ECM interface which uses URB support (PR #17091)
### Testing procedure
Use a STM32 board with USH OTG HS interface:
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash
```
Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`)
```python
[377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd
[377629.854349] usb 1-2.3: device descriptor read/all, error -71
[377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd
[377630.038261] usb 1-2.3: device descriptor read/all, error -71
[377630.038711] usb 1-2-port3: attempt power cycle
[377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd
[377630.666066] usb 1-2.3: device descriptor read/8, error -71
[377630.794076] usb 1-2.3: device descriptor read/8, error -71
[377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd
[377631.002092] usb 1-2.3: device descriptor read/8, error -71
[377631.130091] usb 1-2.3: device descriptor read/8, error -71
[377631.238344] usb 1-2-port3: unable to enumerate USB device
```
or the enumeration of the CDC ECM interface stops with error.
```python
[377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd
[377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[377972.929230] usb 1-2.3: Product: stm32f723e-disco
[377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org
[377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B
[377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device
[377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32
[377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
```
With this PR the enumeration should work as it should:
```python
[378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd
[378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[378484.395301] usb 1-2.3: Product: stm32f723e-disco
[378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org
[378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B
[378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device
[378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba
[378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19390: doxygen: Point to contributing.md document r=kaspar030 a=bergzand
### Contribution description
Shortcuts a referral on the wiki
### Testing procedure
Check the url in the doxygen main page
### Issues/PRs references
None
19391: cord: convert to ztimer r=kaspar030 a=bergzand
### Contribution description
As the subject describes
### Testing procedure
The `examples/cord_ep` example should work as before.
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
DMA mode is disabled for now due to several problems:
- The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the SET_LINE_CODING request. In this case the enumeration of further interfaces, for example CDC ECM is stopped.
- The Enumeration fails for CDC ECM interface which uses URB support.
19386: usbus/dfu: do not create alt interface if NUM_SLOTS=1 r=benpicco a=dylad
### Contribution description
In some cases, it is really useful to build `riotboot` with `NUM_SLOTS=1`.
When use in combination with `riotboot_dfu`, there is no need to export the second slot if `riotboot` is built with `NUM_SLOTS=1`.
Thus, prevent the alt interface declaration in dfu if `NUM_SLOTS=1` so that only slot0 can be used to flash.
### Testing procedure
Add `NUM_SLOTS=1` to `bootloaders/riotboot_dfu/Makefile`
Flash the riotboot DFU bootloader to any board supported by USBUS:
`make BOARD=xxx -C bootloaders/riotboot_dfu flash`
and run
`dfu-util -l`
With NUM_SLOTS=2 you will get:
```
dfu-util -l
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [1209:7d02] ver=0100, devnum=11, cfg=1, intf=0, path="1-4", alt=1, name="RIOT-OS Slot 1", serial="AB88DCAE80893484"
Found DFU: [1209:7d02] ver=0100, devnum=11, cfg=1, intf=0, path="1-4", alt=0, name="RIOT-OS Slot 0", serial="AB88DCAE80893484"
```
with NUM_SLOTS=1 you will get:
```
dfu-util -l
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-4", alt=0, name="RIOT-OS Slot 0", serial="AB88DCAE80893484"
```
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
If riotboot is built with NUM_SLOTS=1, there is no reason to advertise a second slot in the bootloader
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19383: cord: include gcoap_req_send returning 0 in error r=benpicco a=bergzand
### Contribution description
gcoap_req_send returns 0 if it was unable to send the CoAP request. CoRD did not include that case in the return code checks. This changes CoRD to include it and drop the registration if CoAP could not send the request. The old behaviour made the CoRD thread lock up.
### Testing procedure
- Check with the gcoap API docs.
- I can reliable trigger the issue with a RIOT application including both the `cord_ep_standalone` module and some measurement reported both sending requests to the same application. If at some point the application is shut down, gcoap has all its memo's occupied with the measurement reporting and can't add the CoRD update request. Thus the CoRD update request fails with a zero code and the thread (previously) would lock up.
### Issues/PRs references
None
19385: cpu/stm32/periph/timer: fix clobered IRQ flag r=benpicco a=Enoch247
### Contribution description
From the git commit:
> The STM32 periph_timer driver reads the timer's status flags, then clears them all. It is possible that a timer interrupt could occur between reading the flag and clearing it. This would lead to a lost interrupt.
>
> The timer's status flags can be cleared by software, but can only be set by the hardware. This patch takes advantage of this by only clearing the flags it knows are set. The rest of the flags are set, which doesn't actually change their state.
I had trouble finding anything in ST's datasheet saying that software could not set the timer's status flags, but testing showed that this is how it works in practice. Further, [ST's own HAL ](https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_tim.h#L1258)confirms this. If the hardware didn't work this way, it would be impossible to atomically read-modify-write the flags.
### Testing procedure
I tested by doing the following:
1. `make -C tests/periph_timer BOARD=nucleo-f767zi all flash term`
2. press s
3. press [ENTER]
4. observe test passes
5. `make -C tests/periph_timer_periodic BOARD=nucleo-f767zi all flash term`
6. press s
7. press [ENTER]
8. observe test passes
9. `make -C tests/periph_timer_short_relative_set BOARD=nucleo-f767zi all flash term`
10. press s
11. press [ENTER]
12. observe test passes
### Issues/PRs references
- none known
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
The STM32 periph_timer driver reads the timer's status flags, then
clears them all. It is possible that a timer interrupt could occur
between reading the flag and clearing it. This would lead to a lost
interrupt.
The timer's status flags can be cleared by software, but can only be set
by the hardware. This patch takes advantage of this by only clearing the
flags it knows are set. The rest of the flags are set, which doesn't
actually change their state.
19384: sam0/usbdev: partial revert of #17086 r=gschorcht a=dylad
### Contribution description
Reverting theses changes from #17086 because it breaks SAM0 `usbdev` in master.
The idea was to following the USB spec but for not obvious reason yet, it doesn't work as intended.
So revert these changes so `usbdev` works again on master.
We will try to figured out what's wrong later.
### Testing procedure
Test any `usbus` related test application w/ a SAM0-based board.
### Issues/PRs references
See discussion in #17086
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Since `auto_init_usb` provides a static auto configuration for a single USBUS stack instance using a single USB device, a static assert can be used here to check whether the number of EPs required by the configuration does not exceed the number of EPs provided by the USB device.
gcoap_req_send returns 0 if it was unable to send the CoAP request. CoRD
did not include that case in the return code checks. This changes CoRD
to include it and drop the registration if CoAP could not send the
request. The old behaviour made the CoRD thread lock up.
To be able to check during compilation that the number of endpoints provided by a USB peripheral is not exceeded, each interface class has to define the number of IN and OUT endpoints it requires.
19380: driver/usbdev_synopsys_dwc2: use correct number of EPs r=gschorcht a=gschorcht
### Contribution description
This PR fixes the problem that the driver uses the wrong number of EPs when using the USB OTG HS core.
The constant `DWC2_USB_OTG_FS_NUM_EP` was used in several places independent on whether the USB OTG FS core or the USB OTG HS core is used even though there is a function `_max_endpoints` which takes into account the configuration used. For most MCUs this was not a problem, because they have only a USB OTG FS core anyway. But for MCUs like the STM32, which have both a USB OTG FS core and a USB OTG HS core, it matters.
### Testing procedure
Use either
```
USEMODULE='stdio_cdc_acm' BOARD=stm32f429i-disc1 make -j8 -C tests/usbus_cdc_ecm flash
```
or
```
BOARD=stm32f429i-disco make -j8 -C tests/usbus_cdc_ecm flash
```
Without this PR it just stucks due to an `assert` here: 19da279ba5/sys/usb/usbus/cdc/ecm/cdc_ecm.c (L217-L221) The reason is that the USB OTG FS core has only 4 EPs but the application requires 5 IN EPS.
With the PR it works as expected.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
This commit fixes the problem that the driver uses the wrong number of EPs when using the USB OTG HS core. The reason is that the constant `DWC2_USB_OTG_FS_NUM_EP` is used in several places even though there is a function `_max_endpoints` which takes into account the configuration used. For most MCUs this is not a problem, because they have only a USB OTG FS core anyway. But for MCUs like the STM32, which has both a USB OTG FS core and a USB OTG HS core, it matters.
19374: makefiles/boards/stm32: fix DFU_USB_ID handling r=benpicco a=gschorcht
### Contribution description
This PR fixes the still existing problem that an application can't be flashed to a STM32 board if it uses `riotboot_dfu` with default VID/PID (1209:7d02).
In PR #18964 item 1, the problem was already described that an application can't be flashed on a board that is using `riotboot_dfu`. Using for example
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util all riotboot/flash-slot0
```
always leads to error
```python
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boards/stm32.inc.mk:28: *** DFU_USB_ID is not set. Stop.
/home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/makefiles/boot/riotboot.mk:87: recipe for target 'riotboot/bootloader/binfile' failed
```
even if `DFU_USB_ID` variable is set as described in documentation.
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util DFU_USB_ID=1209:7d02 all riotboot/flash-slot0
```
The reason is that the variable `DFU_USB_ID` isn't exported and the check 8dc8bf3567/makefiles/boards/stm32.inc.mk (L27-L29) sees an empty `DFU_USB_ID` variable here. It prevents to use `dfu-util` event though the following `dfu-util.mk` will generate a default value for this variable from the `USB_VID` and `USB_PID` variables if necessary.
Commit 6a76b94c6e0ae97bc743cc90d0811e691a35869e of PR #18964 tried to fix this problem but wasn't merged for any reason.
To fix this problem, the check is completely removed. If a board such as `weact-f4x1cx` uses a DFU boorloader and requires a certain VID/PID combination, board's makefile is responsible to set `DFU_USB_ID` variable.
### Testing procedure
It is not necessary to use a real boad, checking the compilation process is sufficient.
1. Using default VID/PID as described in documentation:
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
PROGRAMMER=dfu-util all riotboot/flash-slot0
```
can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
```python
dfu-util --device 1209:7d02 --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
```
2. Using a VID/PID as described in documentation:
```python
FEATURES_REQUIRED+=riotboot USEMODULE+=usbus_dfu make -C examples/saul BOARD=nucleo-f767zi \
DFU_USB_ID=1209:affe PROGRAMMER=dfu-util all riotboot/flash-slot0
```
can't be compiled without this PR but calls `dfu-util` correctly with this PR using the default VID/PID:
```python
dfu-util --device 1209:affe --alt 0 --download examples/saul/bin/nucleo-f767zi/riotboot_files/slot0.1678440536.bin
```
3. Compiling a board with DFU bootloader
```python
make -C examples/saul flash BOARD=weact-f411ce
```
should still call dfu-util with correct VID/PID:
```python
dfu-util --device 0483:df11 --alt 0 --download /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/examples/saul/bin/weact-f411ce/saul_example.bin --dfuse-address 0x8000000:leave
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19375: tools/renode: add support for target reset r=benpicco a=aabadie
19376: boards/stm32f4discovery: use default port to access stdio via cdc acm r=benpicco a=aabadie
19377: pkg/tinyusb: fix default VID/PID configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the default VID/PID configuration if tinyUSB board reset feature is used.
While reviewing PR #19086 I was wondering why `esp32s2-wemos-mini` requires to set `USB_VID`/`USB_PID` explicitly to `USB_VID_TESTING`/`USB_PID_TESTING`. The reason was that tinyUSB board reset feature wasn't declared as RIOT internal.
### Testing procedure
Flashing `esp32s2-wemos-mini` should still work.
```
BOARD=esp32s2-wemos-mini make -C tests/shell flash
```
The VID/PID should be `1209:7d00` and not `1209:7d01`.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Defining the feature as RIOT internal avoids that the board has to set USB_VID and USB_PID explicit to USB_VID_TESTInG/USB_PID_TESTING if tinyUSB board reset feature is used.
The variable `DFU_USB_ID` is used by `dfu-util` to specify the device to be flashed. The STM32 make system prevents `dfu-util` from being used as programmer if this variable is not set, although `dfu-util.mk` generates a default value for this variable from the `USB_VID` and `USB_PID` variables if necessary. Therefore, checking the `DFU_USB_ID` variable is removed here. If a board requires a specific combination of VID/PID for `dfu_util`, it is responsible for setting the `DFU_USB_ID` variable.
19362: sys/usbus: handle exceeding number of endpoints r=dylad a=gschorcht
### Contribution description
This PR fixes issue #19359 for STM32 USB OTG cores partially:
1. It must not be silently ignored if the number of endpoints is not sufficient for an application. Instead of producing a non-working application, the application stops now with `kernel_panic` if the number of EPs is exhausted. This fixes the problem described in issue #19359 for USB cores with CID version 1.x, e.g. for STM32F439ZI FS interface (CID 1200) since they only have 4 IN and 4 OUT endpoints including the control endpoint EP0.
2. [Update: this part was fixed by PR #17086] ~If a feature is not supported, the device has to signal a STALL on the endpoint that should be used for the data phase in a control transaction. This means that for control read transactions the IN endpoint must signal a STALL and for control write transactions the OUT endpoint must signal a STALL. In former implementation, only the IN endpoint signaled a STALL independent on whether it was a control read or control write transaction. The change also fixes the problem that the enumeration stopped for about 5 seconds if module `usb_reset_board` isn't used. The reason is that the host sends a `SET LINE CODING` request to the CDC ACM interface and the device must signal a STALL on the OUT endpoint if it is not supported.~
### Testing procedure
1. Use a STM32 board with USB OTG version 1.x, for example a `nucleo-f439zi`:
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm flash
```
Without this PR, the application seems to run but the CDC ECM interface is not working. The `ping` command can't be executed. With this PR, the application stops with `kernel_panic`. Because `stdio_cdc_acm` is used which doesn't work in this case, the `kernel_panic` has to be observed in debugger.
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm debug
```
2. [Update: this part was fixed by PR #17086] ~Use a STM32 board with USB OTG version 2.x and USB FS connector, for example a `nucleo-f767zi`:
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm flash
```
Without this PR a delay of 5 seconds in enumeration of the CDC ACM interface can be observed before the CDC ECM interface is enumerated. With this PR there is no delay anymore.~
### Issues/PRs references
Fixes issue #19359 patially.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
If the number of endpoints is not sufficient for an application, it should not be silently ignored and cause a non-working application. Rather, should cause an assertion as it is a configuration issue.
17086: usbdev: Add dedicated stall functions r=benpicco a=bergzand
### Contribution description
This PR adds dedicated stall functions for usbdev peripherals. Two
functions are added. The first function (usbdev_ep_stall) to enable and
disable the stall condition on generic endpoints. The second function is
a dedicated function to set the stall condition on endpoint zero in both
directions. This status can only be set and should automatically be
cleared by the usbdev implementation (or hardware) after a new setup
request is received from the host.
### Testing procedure
- examples/usbus_minimal should still enumerate correctly on the host side.
- #17085 can be used to demonstrate the ep0_stall function with the `tests/usbus_cdc_acm_stdio/` test
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
