The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, packages must first be changed so that they use the inline comparison functions.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, tests must first be changed so that they use the inline comparison functions.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, drivers must first be changed so that they use the inline comparison functions.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, drivers and other modules must first be changed so that they use the inline comparison functions.
The rv32imac supports the A (atomic) extensions containing
read-modify-store operations. This commit modifies the GPIO code to use
these for all bitwise operations. The atomic operations are emitted with
relaxed ordering as they do not require multiprocessor synchronization.
This decreases the duration of the gpio operations from 59 ns to 50 ns
per call. depending a bit on the type of operation.
Just because a user pulls in the DNS client (`sock_dns`) doesn't mean
they want to pull in RDNSS option support as well. Besides, since
`gnrc_ipv6_nib_dns` depends on `gnrc_ipv6_nib`, this forms a circular
dependency that really isn't necessary.
The other applications using `sock_dns` do it too
(`tests/gnrc_sock_dns` and `tests/gnrc_ipv6_nib_dns`) and besides it
doesn't make much sense to include RDNSS option support
(aka `gnrc_ipv6_nib_dns`) just because someone uses the DNS client
(aka `sock_dns`). This dependency will be removed in a later commit.
This is a small optimization to the RISC-V trap handler. By splitting
the call to sched_run from the trap_handle call, loading the previous
thread ptr can be delayed until after it is determined that a schedule
run is required. This shaves of a few cycles during regular interrupts
that do not trigger the scheduler.
