add default radio parameters for RDKB_ONE_WIFI_PROD, DFS, channel and…

[janewang2026]

This PR is generate to port default parameters required by RDKB_ONE_WIFI_PROD after factory reset

1. Enable 11ax for 2G band
2. Enable DFS for 5G band
3. Enable default chanspec to 160MHz for 5G band

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[Copilot]

Pull request overview

Ports RDKB_ONE_WIFI_PROD default WiFi radio/RFC settings so that after factory reset (and during DB init/upgrade) the platform comes up with expected PROD defaults: 2.4GHz 11ax enabled, 5GHz DFS enabled, and 5GHz defaulting to 160MHz where applicable.

Changes:

• On factory reset, force-enable twoG80211axEnable_rfc (PROD) and enable DFS RFC + persist to PSM (PROD).
• Update DB default radio configs (notably 5GHz-high) to use channel 100 and 160MHz (PROD) and set RFC defaults for DFS (PROD).
• Add PROD-specific DB upgrade logic to correct stale 5GHz channels and force 160MHz + DFS, and ensure DFS RFC cache is updated when toggled.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
source/dml/dml_webconfig/dml_onewifi_api.c	Adjusts factory reset behavior to restore PROD RFC defaults (2.4GHz AX, 5GHz DFS) and persist DFS RFC to PSM.
source/db/wifi_db.c	Updates non-OVSDB default radio parameters for 5GHz-high to PROD defaults (channel/width).
source/db/wifi_db_apis.c	Sets PROD RFC defaults (DFS), applies PROD upgrade corrections, and updates default radio/vap config defaults for 160MHz + DFS.
source/core/wifi_ctrl_queue_handlers.c	Ensures DFS RFC toggle updates the in-memory RFC cache in addition to persisting it.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

source/dml/dml_webconfig/dml_onewifi_api.c:2096

• The DFS factory-reset comment has an unmatched closing parenthesis and is a bit unclear; consider rewriting it as a single complete sentence.

        //Update DFS RFC for 5GHz radio
        //default bandwidth, which spans DFS channels, is retained after factory reset)

source/db/wifi_db.c:129

• RDKB_ONE_WIFI_PROD defaults the 5H radio to channel 100 (a DFS channel) and 160MHz, but cfg.DfsEnabled is never set here (it remains 0 due to the earlier memset). This can produce an inconsistent default configuration (DFS channel selected while DFS is disabled).

#if defined(RDKB_ONE_WIFI_PROD)
            cfg.channel = 100;
            cfg.channelWidth = WIFI_CHANNELBANDWIDTH_160MHZ;

source/dml/dml_webconfig/dml_onewifi_api.c:2087

• In the 2.4GHz AX restore block, dfs_rfc is also forced to true and persisted, but the comment (and the surrounding logic) is specifically about restoring twoG80211axEnable_rfc. Keeping DFS updates in the 5GHz/DFS section avoids unrelated side effects and redundant RFC DB writes during the per-radio loop.

            // Restore the 2.4 GHz 802.11ax enable to its default on factory reset so the
            // AX (and BE) variant is not stripped from the radio by the RFC apply path.
            rfc_param->twoG80211axEnable_rfc = true;
            rfc_param->dfs_rfc = true;
            get_wifidb_obj()->desc.update_rfc_config_fn(0, rfc_param);

source/core/wifi_ctrl_queue_handlers.c:2808

• get_wifi_db_rfc_parameters() returns a pointer to the shared wifi_mgr_t::rfc_dml_parameters struct. Updating dfs_rfc without taking data_cache_lock can race with other readers/writers of the RFC cache. Please guard the assignment with the existing mutex (or update the cached struct via a dedicated API that does so).

    get_wifi_db_rfc_parameters()->dfs_rfc = type;

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

source/core/wifi_ctrl_queue_handlers.c:2810

• update_rfc_config_fn() is called before rfc_param->dfs_rfc is set, so the DB update uses the previous value and may not persist the requested DFS RFC state. Also, comparing against literal 0 is inconsistent with the rest of this file (which uses RETURN_OK).

    int rfc_ret = get_wifidb_obj()->desc.update_rfc_config_fn(0, rfc_param);
    if (rfc_ret == 0) {
	rfc_param->dfs_rfc = type;
    }
    get_wifi_db_rfc_parameters()->dfs_rfc = type;

source/db/wifi_db.c:130

• For builds that use this non-ONEWIFI_DB_SUPPORT default initializer, the PROD-specific 5GHz defaults are only applied to WIFI_FREQUENCY_5H_BAND. WIFI_FREQUENCY_5_BAND / WIFI_FREQUENCY_5L_BAND remain at 80MHz and DFS disabled, which contradicts the PR description (“Enable DFS for 5G band” and “default chanspec to 160MHz for 5G band”). Consider aligning 5/5L defaults with the PROD behavior used elsewhere (wifi_db_apis.c).

            cfg.operatingClass = 128;
#if defined(RDKB_ONE_WIFI_PROD)
            cfg.channel = 100;
            cfg.channelWidth = WIFI_CHANNELBANDWIDTH_160MHZ;
	    cfg.DfsEnabled = true;

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

source/core/wifi_ctrl_queue_handlers.c:2810

• process_dfs_rfc() updates RFC config in the DB before setting rfc_param->dfs_rfc, so the persisted value will not reflect the requested type. Also, get_wifi_db_rfc_parameters()->dfs_rfc is updated even if the DB update fails, which can desync the runtime cache from persisted state.

    int rfc_ret = get_wifidb_obj()->desc.update_rfc_config_fn(0, rfc_param);
    if (rfc_ret == 0) {
	rfc_param->dfs_rfc = type;
    }
    get_wifi_db_rfc_parameters()->dfs_rfc = type;

source/db/wifi_db.c:134

• For RDKB_ONE_WIFI_PROD, the defaults here only enable DFS + 160MHz for WIFI_FREQUENCY_5H_BAND. The WIFI_FREQUENCY_5_BAND/WIFI_FREQUENCY_5L_BAND defaults still come up as 80MHz with DFS disabled (because cfg is zero-initialized), which contradicts the PR goal of enabling DFS + 160MHz for 5GHz defaults and is inconsistent with wifidb_init_radio_config_default() in wifi_db_apis.c.

        case WIFI_FREQUENCY_5H_BAND:
            cfg.operatingClass = 128;
#if defined(RDKB_ONE_WIFI_PROD)
	    cfg.channel = 100;
	    cfg.channelWidth = WIFI_CHANNELBANDWIDTH_160MHZ;
	    cfg.DfsEnabled = true;
#else
            cfg.channel = 157;
            cfg.channelWidth = WIFI_CHANNELBANDWIDTH_80MHZ;
#endif /* RDKB_ONE_WIFI_PROD */

source/db/wifi_db_apis.c:4837

• For RDKB_ONE_WIFI_PROD, dfs_rfc is defaulted to true, but twoG80211axEnable_rfc is still gated only by ALWAYS_ENABLE_AX_2G / NEWPLATFORM_PORT. Since this function seeds the default RFC config, a factory-reset / fresh DB init can still end up with 2.4GHz AX disabled unless those other macros are defined, which conflicts with the PR requirement to enable 11ax by default on 2.4GHz for PROD.

#if defined(RDKB_ONE_WIFI_PROD)
    rfc_config.dfs_rfc = true;
#else
    rfc_config.dfs_rfc = false;
#endif /* RDKB_ONE_WIFI_PROD */