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>
Since the stm32f429i-disco uses the USB OTG HS instead of USB OTG FS peripheral, the number of available EPs is sufficient for this application. With the change of defining the largest number of available EPs for USBUS instead of the smallest number, the board can use all EPs of the USB OTG HS peripheral.
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>
19344: test/periph_rtc: reset struct tm time between tests r=benpicco a=kfessel
### Contribution description
while reviewing #19340 i found test/periph_rtc to be insufficient to prove rtc_set_time is working. this changes that and avoids accidental reuse of struct tm time and ms values by resetting time and ms;
### Testing procedure
run the test
### Issues/PRs references
#19340
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19242: usbus/msc: add initial Mass Storage Class support r=benpicco a=dylad
### Contribution description
This PR adds the initial support for Mass Storage Class in USBUS. This PR relies on the RIOT MTD implementation to implement the Mass Storage Class support. With the provided test application, a MTD device will be accessible as a normal storage device on your host computer.
Read and Write operations are allowed.
Multiple LUNs are supported so several MTD devices can be exported through USB.
The MSC relies on SCSI protocol to operate.
Currently there are some limitations:
Supported host : Linux & Windows (macOS is untested)
MSC cannot be used if MTD page size > 4096
MTD device must have at least 512 bytes of memory to be exported.
Please be aware that performance are not so great.
### Testing procedure
Flash `tests/usbus_msc` application on a board with at least one MTD device.
Once the shell has started, prepare one or several MTD devices to be exported using `add_lun` command.
Once ready, start the USB connection with `usb_attach`
All MTD exported should appear as` /dev/sdX` on Linux.
### Issues/PRs references
Supersede #15941
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
17612: pkg: add FlashDB r=benpicco a=benpicco
19332: sys/tiny_strerror: make use of flash_utils.h r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
19292: sys/phydat: Fix unit confusion r=miri64 a=maribu
### Contribution description
Previously, `UNIT_G` was used for g-force with the correct symbol `g`, `UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs` (which is an alternative correct symbol).
To avoid confusion between G-Force, Gauss, and Gram the units have been renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition, gram now uses the correct symbol `g`; which sadly is the same as for g-force. But usually there is enough context to tell them apart.
### Testing procedure
Green CI
### Issues/PRs references
None
19307: nanocoap_link_format: fix off-by-one error r=miri64 a=benpicco
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
18746: sys/clif: Fixing out of bounds read under certain conditions r=maribu a=Teufelchen1
Hi 😈
This fixes a potential out of bounds read in clif_encode_link. There is no code in RIOT that can be exploited.
The fix does not break the current API but alters the behaviour slightly. Before the change, the length attributes of `clif_attr_t` where optional. If missing, the length was deduced using `strlen()`. This fix makes those parameters required and if they are `0` it operates as if the length really is `0`. This might not be ideal but it is the only non api breaking fix I could think off.
```c
typedef struct {
char *value;
unsigned value_len; NO LONGER OPTIONAL
const char *key;
unsigned key_len; NO LONGER OPTIONAL
} clif_attr_t;
```
Depends on #18744
cc `@leandrolanzieri`
19161: bors.yaml: re-activate labels check + add block_labels r=miri64 a=miri64
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Previously, `UNIT_G` was used for g-force with the correct symbol `g`,
`UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which
would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs`
(which is an uncommon but correct symbol).
To avoid confusion between G-Force, Gauss, and Gram the units have been
renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition,
gram now uses the correct symbol `g` and Gauss uses `G`.
19297: tests/rmutex: clean up test and reduce stack size r=maribu a=maribu
### Contribution description
As the title says. This results in a few more boards being able to run the test.
Also, the wording in the README.md is improved to not be interpreted as generally threads with lower thread ID being preferred over threads with higher when locking a mutex.
### Testing procedure
```
make -C tests/rmutex BOARD=foo flash test
```
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/19140
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu
### Contribution description
The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details.
In addition, a SAUL layer and auto-initialization is provided.
### Testing procedure
The test application provides access to the servo driver via the `saul` shell command.
```
> saul
2022-08-02 22:12:31,826 # saul
2022-08-02 22:12:31,827 # ID Class Name
2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green)
2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue)
2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red)
2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button)
2022-08-02 22:12:31,838 # #4 ACT_SERVO servo
> saul write 4 0
2022-08-02 22:12:41,443 # saul write 4 0
2022-08-02 22:12:41,445 # Writing to device #4 - servo
2022-08-02 22:12:41,447 # Data: 0
2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255)
2022-08-02 22:12:41,453 # data successfully written to device #4
> saul write 4 256
2022-08-02 22:12:45,343 # saul write 4 256
2022-08-02 22:12:45,346 # Writing to device #4 - servo
2022-08-02 22:12:45,347 # Data: 256
2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255)
2022-08-02 22:12:45,354 # data successfully written to device #4
```
Each write resulted in the MG90S servo that I connected to move to the corresponding position.
### Issues/PRs references
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The previous servo driver didn't provide any benefit over using PWM
directly, as users controlled the servo in terms of PWM duty cycles.
This changes the interface to provide a high level interface that
abstracts the gory PWM details.
In addition, a SAUL layer and auto-initialization is provided.
Co-authored-by: benpicco <benpicco@googlemail.com>
19294: sys/shell: don't include suit command by default r=benpicco a=benpicco
19295: gcoap: Finish the gcoap_get_resource_list_tl -> gcoap_get_resource_list renaming r=benpicco a=chrysn
### Contribution description
In #16688, an argument was added to the `gcoap_get_resource_list` function by creating a new function `gcoap_get_resource_list_tl` with a deprecation and roll-over plan.
This plan has not been acted on so far.
This PR shortens the original plan by just adding the argument to `gcoap_get_resource_list` and removing `gcoap_get_resource_list_tl` in a single go. The rationale for this deviation is that while it's a public API, its only two practical consumers are the (built-in) well-known/core implementation, and the (built-in) CoRE Resource Directory (cord) endpoint. Moreover, a further change to this API (switching over to `coap_block_slicer_t`) is expected to happen within this release cycle, which would take something like 4 total releases to get through otherwise, which is unrealistic for an API that there are no known external users of.
A second commit clean up ToDo items (in the changed function's documentation) that referred to a IETF draft that has long been abandoned by the CoRE WG.
### Testing procedure
Plain inspection and CI passing should suffice.
### AOB
There is a second analogous pair left over from #16688, `gcoap_req_send` / `gcoap_req_send_tl`. As that *is* expected to be used widely, I prefer not to mix these two concerns, and get the present one through without unnecessary hold-up.
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: chrysn <chrysn@fsfe.org>
This is an API change in the latter, which would typically now take an
extra argument GCOAP_SOCKET_TYPE_UNDEF.
Follow-Up-For: https://github.com/RIOT-OS/RIOT/pull/16688
19256: pkg/tinyusb: add GD32VF103 support r=gschorcht a=gschorcht
### Contribution description
This PR provides the tinyUSB support for GD32VF103 and enables the `tinyusb_device` feature as well as `stdio_tinyusb_cdc_acm` for GD32VF103 boards.
### Testing procedure
```
BOARD=sipeeed-longan-nano make -C tests/shell flash term
```
should work
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
* riot-wrappers:
* Fix infinite loop when using a Mutex
* Make ValueInThread Copy/Clone
* riot-sys:
* Export xxx_DEV (eg. I2C_DEV) C macros as functions
* Add auto_init_utils.h
19284: boards: support for the LILYGO TTGO T8 ESP32-S2 board r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the LILYGO TTGO T8 ESP32-S2 board which has a OLED display (not yet supported) and a SD-Card slot on board.
The board is equipped with a USB-C connector that connects either to a USB-to-UART bridge or to the USB-OTG/JTAG interface of the ESP32-S2 via some DIP switches.
The PR includes a very small fix of printf format string in `tests/malloc`. I can split it off.
### Testing procedure
t.b.d.
### Issues/PRs references
19286: cpu/esp_common: use generic WIFI_SSID/WIFI_PASS defines r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19258: drivers/mtd_flashpage: implement pagewise API, don't use raw addresses r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
There are boards that select the STDIO backend used depending on whether `usbus` is enabled. Usually the `fido2_ctap_transport_hid` module pulls in `usbus_hid` and thus `usbus`, but since this dependency resolution is done after reading the `Makefile.dep` of the board, it may happen that the wrong STDIO backend is selected. Therefore `usbus` is selected directly in the `Makefile`.
17045: sys/coding: add XOR based coding module r=benpicco a=benpicco
19243: cpu/gd32v: add periph_gpio_ll and periph_gpio_ll_irq support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_gpio_ll` and `periph_gpio_ll_irq` support for GD32VF103. Level triggered interrupts are emulated.
`periph_gpio_ll_irq` could be split off from this PR as a separate PR if necessary.
### Testing procedure
Use any GD32V board and connect PA0 -> PB0 and PA1 -> PB1 where PA is the output port and PB the input port. With these connections `tests/periph_gpio_ll` should work.
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio_ll flash term
```
If necessary, change the input and output pins by setting the environment variables and connect the corresponding pins, for example for `seeedstudio-gd32` PA1 -> PB8 and PA8 -> PB9:
```
PIN_OUT_0=1 PIN_OUT_1=8 PIN_IN_0=8 PIN_IN_1=9 BOARD=seedstudio-gd32 make -j8 -C tests/periph_gpio_ll flash term
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19251: tests/driver_dac_dds: fix output of sine and saw functions r=benpicco a=benpicco
19254: cpu/gd32v: add periph_rtc_mem support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_rtc_mem` support for GD32VF103.
A modified version of this driver could also be used for STM32F1.
### Testing procedure
`tests/periph_rtt` should work on any GD32V board, for example:
```
BOARD=sipeed-longan-nano make -C tests/periph_rtt flash
```
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.04-devel-319-gebc86-cpu/gd32v/periph_rtc_mem)
RIOT RTT low-level driver test
RTT configuration:
RTT_MAX_VALUE: 0xffffffff
RTT_FREQUENCY: 32768
Testing the tick conversion
Trying to convert 1 to seconds and back
Trying to convert 256 to seconds and back
Trying to convert 65536 to seconds and back
Trying to convert 16777216 to seconds and back
Trying to convert 2147483648 to seconds and back
All ok
Initializing the RTT driver
RTC mem OK
This test will now display 'Hello' every 5 seconds
RTT now: 1
Setting initial alarm to now + 5 s (163841)
rtt_get_alarm() PASSED
RTC mem OK
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18903: pkg/tinyusb: add tinyUSB netdev driver r=dylad a=gschorcht
### Contribution description
This PR adds the tinyUSB netdev driver.
The tinyUSB netdev driver is part of the tinyUSB package and is enabled by module `tinyusb_netdev`. It is available for boards that provide the `tinyusb_device` feature.
**Please note** Since the tinyUSB package is distinct from (and incompatible with) the USB stack provided around USBUS in RIOT (see USB), the tinyUSB netdev driver cannot be used together with with any USBUS device class.
The tinyUSB netdev driver uses Ethernet over USB and supports the following protocols:
- CDC ECM (Ethernet Control Model)
- CDC NCM (Network Control Model)
- RNDIS (Microsoft Remote NDIS)
While Linux and macOS support all these protocols, Microsoft Windows only supports the RNDIS protocol and since Windows version 11 also the CDC NCM protocol. macOS supports the RNDIS protocol since version 10.15 (Catalina).
Which protocol is used is selected by the corresponding pseudomodules `tinyusb_class_net_cdc_ecm`, `tinyusb_class_net_cdc_ncm` and `tinyusb_class_net_rndis`.
The CDC ECM protocol (`tinyusb_class_net_cdc_ecm`) and the RNDIS protocol (`tinyusb_class_net_rndis`) can be used simultaneously to support all operating systems, for example :
```
USEMODULE='tinyusb_netdev tinyusb_class_net_rndis tinyusb_class_net_cdc_ecm' \
BOARD=... make -C ... flash
```
In this case, the CDC ECM protocol is the default protocol and the RNDIS protocol the alternative protocol defined as second device configuration. The CDC NCM protocol cannot be used together with the CDC ECM or the RNDIS protocol.
This PR includes PR #18983 for now to be compilable.
Comparison with USBUS CDC ECM (`nucleo-f767zi` board):
```
text data bss dec hex filename
65916 596 18728 85240 14cf8 tests_pkg_tinyusb_netdev.elf
```
```
text data bss dec hex filename
63120 544 15444 79108 13504 tests_usbus_cdc_ecm.elf
```
### Testing procedure
Use a board that is supported by tinyUSB. Compile and flash the test application for each protocol:
1. RNDIS
```
BOARD=... make -j8 -C tests/pkg_tinyusb_netdev flash
```
2. CDC ECM
```
CLASS=tinyusb_class_net_cdc_ecm BOARD=... make -j8 -C tests/pkg_tinyusb_netdev flash
```
3. CDC NCM
```
CLASS=tinyusb_class_net_cdc_ncm BOARD=... make -j8 -C tests/pkg_tinyusb_netdev flash
```
For each test, a network interface should be added on the host. Use command `ifconfig` on USB device and on the host and check that both have a link local address. In syslog there should be an output like the following:
<details>
```
Nov 13 18:14:46 gunny8 kernel: [4611465.480025] usb 1-2.2: new full-speed USB device number 28 using xhci_hcd
Nov 13 18:14:47 gunny8 kernel: [4611465.581641] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
Nov 13 18:14:47 gunny8 kernel: [4611465.581646] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 13 18:14:47 gunny8 kernel: [4611465.581650] usb 1-2.2: Product: nucleo-f767zi
Nov 13 18:14:47 gunny8 kernel: [4611465.581653] usb 1-2.2: Manufacturer: RIOT-os.org
Nov 13 18:14:47 gunny8 kernel: [4611465.581654] usb 1-2.2: SerialNumber: 6591620BCB270283
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.1066] manager: (usb0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/528)
Nov 13 18:14:47 gunny8 kernel: [4611465.594604] rndis_host 1-2.2:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-2.2, RNDIS device, fa:db:7c:1b:58:80
Nov 13 18:14:47 gunny8 mtp-probe: checking bus 1, device 28: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2"
Nov 13 18:14:47 gunny8 mtp-probe: bus: 1, device: 28 was not an MTP device
Nov 13 18:14:47 gunny8 systemd-udevd[17796]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 kernel: [4611465.643852] rndis_host 1-2.2:1.0 enp0s20f0u2u2: renamed from usb0
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:usb0 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00001002
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.1833] device (usb0): interface index 508 renamed iface from 'usb0' to 'enp0s20f0u2u2'
Nov 13 18:14:47 gunny8 upowerd[2845]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.1
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2037] device (enp0s20f0u2u2): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnetBridge: Adding interface enp0s20f0u2u2 index:508
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2075] device (enp0s20f0u2u2): carrier: link connected
Nov 13 18:14:47 gunny8 upowerd[2845]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2129] settings: (enp0s20f0u2u2): created default wired connection 'Kabelgebundene Verbindung 2'
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <warn> [1668359687.2142] device (enp0s20f0u2u2): connectivity: "/proc/sys/net/ipv4/conf/enp0s20f0u2u2/rp_filter" is set to "1". This might break connectivity checking for IPv4 on this device
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2151] device (enp0s20f0u2u2): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 upowerd[2845]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2
Nov 13 18:14:47 gunny8 systemd-udevd[17796]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2403] policy: auto-activating connection 'Kabelgebundene Verbindung 2' (0b1ae45e-c76e-3efb-a2cd-138ca2b2a59c)
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2414] device (enp0s20f0u2u2): Activation: starting connection 'Kabelgebundene Verbindung 2' (0b1ae45e-c76e-3efb-a2cd-138ca2b2a59c)
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2419] device (enp0s20f0u2u2): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2429] device (enp0s20f0u2u2): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2440] device (enp0s20f0u2u2): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Nov 13 18:14:47 gunny8 NetworkManager[24229]: <info> [1668359687.2445] dhcp4 (enp0s20f0u2u2): activation: beginning transaction (timeout in 45 seconds)
Nov 13 18:14:47 gunny8 vmnetBridge: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 vmnet-natd: RTM_NEWLINK: name:enp0s20f0u2u2 index:508 flags:0x00011043
Nov 13 18:14:47 gunny8 avahi-daemon[1464]: Joining mDNS multicast group on interface enp0s20f0u2u2.IPv6 with address fe80::dba4:adb8:9ffe:d93e.
Nov 13 18:14:47 gunny8 avahi-daemon[1464]: New relevant interface enp0s20f0u2u2.IPv6 for mDNS.
Nov 13 18:14:47 gunny8 avahi-daemon[1464]: Registering new address record for fe80::dba4:adb8:9ffe:d93e on enp0s20f0u2u2.*.
Nov 13 18:14:47 gunny8 kernel: [4611465.895046] userif-1: sent link down event.
Nov 13 18:14:47 gunny8 kernel: [4611465.895052] userif-1: sent link up event.
```
</details>
Ping from and to the host.
### Issues/PRs references
Depends on PR https://github.com/RIOT-OS/RIOT/pull/18983
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18863: boards/esp32s2-mini: add definition for ESP32 S2 Mini r=gschorcht a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19193: rust: Update dependencies, use riot-wrappers from git r=benpicco a=chrysn
### Contribution description
As riot-wrappers has advanced a bit since it was last released, Rust modules are switched to using it from git again. (This is a regular ping-pong between testing the latest release in RIOT master, and using released support crates when they're current).
This primarily updates riot-wrappers, which has accumulated several compatible changes. Several other crates receive updates as well.
### Testing procedure
* Green CI
### Issues/PRs references
Changes on the riot-wrappers side:
* https://github.com/RIOT-OS/rust-riot-wrappers/pull/17
* https://github.com/RIOT-OS/rust-riot-wrappers/pull/22
* https://github.com/RIOT-OS/rust-riot-wrappers/pull/29
* https://github.com/RIOT-OS/rust-riot-wrappers/pull/30
[edit: added:]
This also serves to help preparing a 0.8.1 release of riot-wrappers, which performs some deprecations so that a breaking 0.9 change can be done more effortlessly later on.
19214: cpu/gd32v: add periph_spi support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_spi` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
The driver is a modified version of the driver for STM32F1 with some changes that were necessary to get it working on GD32V.
### Testing procedure
`tests/periph_spi` as well as a test with any SPI sensor should work. `tests/driver_sdcard_spi` should work on `sipeed-longan-nano`.
### Issues/PRs references
Depeneds on PR #19216
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
16782: drivers/mfrc522: add new driver r=benpicco a=HendrikVE
### Contribution description
This PR adds support for the MFRC522. It is quite common in the Arduino world and it is quite cheap. The driver connects to the MFRC522 via SPI and is heavily based on the Arduino driver available [here](https://github.com/miguelbalboa/rfid). Basically it was ported, but with several improvements in readability and documentation.
### Testing procedure
The given (manual) test provides single commands for some driver functions.
19201: cpu/gd32v: add periph_i2c support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_i2c` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
The driver is a modified version of the driver for STM32F1 with some changes that were necessary to get it working on GD32V. As for STM32F1, the driver is using polling instead of interrupts for now. It will be implemented interrupt-driven later.
### Testing procedure
`tests/periph_i2c` as well as a test with any I2C sensor should work. The driver was tested with `tests/driver_l3gxxxx` and `tests/driver_bmp180`.
### Issues/PRs references
Co-authored-by: Hendrik van Essen <hendrik.ve@fu-berlin.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Testing the correct calculation of flash page indices without assuming the `periph_flashpage` feature and enabling the `periph_flashpage` module makes no sense. On ESP32x SoCs for example, the space in the flash is only reserved and `FLASHPAGE_NUMOF` is greater than 0 if `periph_flashpage` is used.
