feat(kconfig): add Kconfig/hal_config module-selection system and templates

## Description Commits `zephyr/Kconfig` and `zephyr/CMakeLists.txt` (the module's `kconfig-ext`/`cmake-ext` integration — one config/library-source entry per MSS peripheral, bridging `CONFIG_HAL_AWR6843_*` to the `ENABLE_*_MODULE` macros `hal/mss` headers check), plus `hal/util/hal_config_mss.h` and `hal_config_dss.h` (the two files those headers actually include), and `template/hal_config_{mss,dss}_template.h` documenting how a non-Zephyr integrator copies and customizes them. ## Why Change justification per ISO 9001 section 7.5.2: one of several small PRs landing the previously-uncommitted module-selection system (see #16), split out from the individual driver-module PRs since it's a distinct concern (config plumbing, not driver logic) even though every `hal/mss`/`hal/dss` module header depends on `hal_config_mss.h`/`hal_config_dss.h` existing. ## Related Issue Closes #21. Relates to #16. ## Type of Change - [x] New feature ## Impact Assessment - **Functional impact:** None yet — `zephyr/CMakeLists.txt` references driver `.c` sources (e.g. `hal/mss/esm/hal_esm.c`) that land in their own separate PRs; those references are inert until both sides exist, same as any other incremental module wiring. - **Regulatory impact:** None. - **QMS impact:** None. - **Risk impact:** No — existing risk coverage sufficient. ## Testing - [x] CI pipeline passes (compile, unit tests, integration tests, static analysis) — no CI job exercises Kconfig/Zephyr builds yet (that's part of issue #16's remaining scope, added once the driver modules and CI workflow PRs land). - [x] Manually tested: read both `hal_config_{mss,dss}.h` against their templates to confirm they match 1:1 (same macro names, same module list). - [x] No regressions observed in related areas. ## PR Size - [x] M (50–150 lines) **Size justification / exemption (if L or XL):** N/A — 278 lines across 6 small, tightly related config files. ## Checklist - [x] Commit messages follow `type(scope): description` convention with `Relates to #<issue>` footer - [x] PR template filled in completely - [x] No unverified external binaries introduced (see QMS-GITFLOW-001 Binary Security section) - [x] All commits leave the codebase in a compilable, passing-tests state (Commit Integrity Rule) — config headers only, no code that compiles against them yet in this branch's history - [x] Reviewer assigned - [x] QMS maintainer approval obtained (required for QMS and device repository changes) ## Summary - `zephyr/Kconfig` — `menuconfig HAL_AWR6843` + one `config HAL_AWR6843_<X>` per MSS peripheral - `zephyr/CMakeLists.txt` — `zephyr_library_sources_ifdef` per module - `hal/util/hal_config_mss.h` — Kconfig bridge + `ENABLE_*_MODULE` fallback (MSS) - `hal/util/hal_config_dss.h` — plain `ENABLE_*_MODULE` opt-in, no Kconfig bridge (DSS) - `template/hal_config_mss_template.h`, `template/hal_config_dss_template.h` — usage templates for non-Zephyr integrators

hoogv commented

2026-07-21 20:50:27 +00:00

(Migrated from codeberg.org)

Description

Commits zephyr/Kconfig and zephyr/CMakeLists.txt (the module's kconfig-ext/cmake-ext integration — one config/library-source entry per MSS peripheral, bridging CONFIG_HAL_AWR6843_* to the ENABLE_*_MODULE macros hal/mss headers check), plus hal/util/hal_config_mss.h and hal_config_dss.h (the two files those headers actually include), and template/hal_config_{mss,dss}_template.h documenting how a non-Zephyr integrator copies and customizes them.

Why

Change justification per ISO 9001 section 7.5.2: one of several small PRs landing the previously-uncommitted module-selection system (see #16), split out from the individual driver-module PRs since it's a distinct concern (config plumbing, not driver logic) even though every hal/mss/hal/dss module header depends on hal_config_mss.h/hal_config_dss.h existing.

Closes #21. Relates to #16.

Type of Change

New feature

Impact Assessment

Functional impact: None yet — zephyr/CMakeLists.txt references driver .c sources (e.g. hal/mss/esm/hal_esm.c) that land in their own separate PRs; those references are inert until both sides exist, same as any other incremental module wiring.
Regulatory impact: None.
QMS impact: None.
Risk impact: No — existing risk coverage sufficient.

Testing

CI pipeline passes (compile, unit tests, integration tests, static analysis) — no CI job exercises Kconfig/Zephyr builds yet (that's part of issue #16's remaining scope, added once the driver modules and CI workflow PRs land).
Manually tested: read both hal_config_{mss,dss}.h against their templates to confirm they match 1:1 (same macro names, same module list).
No regressions observed in related areas.

PR Size

M (50–150 lines)

Size justification / exemption (if L or XL):

N/A — 278 lines across 6 small, tightly related config files.

Checklist

Commit messages follow type(scope): description convention with Relates to #<issue> footer
PR template filled in completely
No unverified external binaries introduced (see QMS-GITFLOW-001 Binary Security section)
All commits leave the codebase in a compilable, passing-tests state (Commit Integrity Rule) — config headers only, no code that compiles against them yet in this branch's history
Reviewer assigned
QMS maintainer approval obtained (required for QMS and device repository changes)

Summary

zephyr/Kconfig — menuconfig HAL_AWR6843 + one config HAL_AWR6843_<X> per MSS peripheral
zephyr/CMakeLists.txt — zephyr_library_sources_ifdef per module
hal/util/hal_config_mss.h — Kconfig bridge + ENABLE_*_MODULE fallback (MSS)
hal/util/hal_config_dss.h — plain ENABLE_*_MODULE opt-in, no Kconfig bridge (DSS)
template/hal_config_mss_template.h, template/hal_config_dss_template.h — usage templates for non-Zephyr integrators

hoogv added the

Rows
Columns

feat(kconfig): add Kconfig/hal_config module-selection system and templates #19