Nightlies are failing due to kconfig mismatch.
It would seem this is a result of bringing in the USB stuff.
I assume that this uses ztimer periph_timer as a backend as periph_timer is already selected.
However, kconfig only resolves one and not recursively making it hard to match.
For not a hack is added to override for these boards.
This adds a xtimer_no_ztimer_default that is currently always
selected in Makefile, but that can be switched off in Kconfig.
Removing its inclusion will allow switching the default xtimer
backend to ztimer, while allowing for an easy way back.
This is done to avoid circular dependency, it will currently allow for
ztimer64_xtimer_compat beeing selected as well as xtimer_on_ztimer.
This altough incorrect mimics make, and will be fixed when making
ztimer_xtimer_compat the default xtimer backend
This is a temporary fix for Issue #17060. It allows to disable
auto inclusion of `ztimer_periph_rtt` in cases where another
module or application requires direct access.
Limitations:
- as ifeq are involved order of inclusion matters, therefore
these modules should be included early in the build at application
level and not in modules `Makefile.dep`
- this does not disallow direct inclusions of `ztimer_periph_rtt`,
since this only disables auto inclusion of these modules
This is a temporary solution since this is already possible with
Kconfig, but not in make.
To avoid confusions between `auto_init_ztimer` and `ztimer_auto_init`
rename `ztimer_auto_init` to `ztimer_init`.
This allows for similar handling as `saul_init_devs` and
`auto_init_devs`. Dependencies are therefore done against the USEMODULE
and not DEFAULT_MODULE or checking DISABLE_MODULE. For this, both
`ztimer_init` and `auto_init_ztimer` are added to DEFAULT_MODULE and
both need disabling if the user does not want that module in.
With this, the comment in Kconfig no longer applies.
