Fix the issue where the default configuration parameters for the log

[yangbryant]

fix the issue where the default configuration parameters for the log do not take effect

[qodo-code-review]

Review Summary by Qodo

Fix default log configuration parameters not taking effect

🐞 Bug fix

Walkthroughs

Description

• This description is generated by an AI tool. It may have inaccuracies
• Fixes default log configuration parameters not taking effect
• Changes PG_REGISTER to PG_REGISTER_WITH_RESET_TEMPLATE macro
• Ensures reset template is properly applied to log configuration

Diagram

flowchart LR
  A["PG_REGISTER macro"] -- "replaced with" --> B["PG_REGISTER_WITH_RESET_TEMPLATE"]
  B -- "applies reset template" --> C["Default log config parameters"]
  C -- "now take effect" --> D["Log configuration initialized correctly"]

Loading

File Changes

1. src/main/common/log.c 🐞 Bug fix +1/-1

Use reset template macro for log configuration

• Changed PG_REGISTER to PG_REGISTER_WITH_RESET_TEMPLATE for logConfig registration
• Ensures the reset template with default values is properly applied during initialization
• Fixes issue where default log level and topics were not being set

src/main/common/log.c

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (0)   📎 Requirement gaps (0)   🎨 UX Issues (0)

🐞\ ≡ Correctness (1)

1. Defaults won't migrate 🐞 ≡

Description

logConfig is still registered with version 0, so pgLoad() will restore any existing EEPROM
record over the new reset-template defaults and the fixed defaults won't take effect until EEPROM is
reset. This undermines the PR goal for users upgrading from builds that previously saved a
zero-initialized logConfig.

Code

src/main/common/log.c[57]

+PG_REGISTER_WITH_RESET_TEMPLATE(logConfig_t, logConfig, PG_LOG_CONFIG, 0);

Evidence

The PR keeps PG_LOG_CONFIG registration version at 0, and the config loader always resets then
copies EEPROM data back when the stored version matches the registered version—so existing stored
values override the newly-wired reset template. On first boot with invalid EEPROM, the firmware
resets configs and writes them, meaning older builds likely persisted the previously-zeroed
logConfig to EEPROM; after upgrading, that stored record is still loaded because the version
matches.

src/main/common/log.c[57-62]
src/main/config/parameter_group.c[86-94]
src/main/config/config_eeprom.c[220-240]
src/main/fc/config.c[381-390]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`logConfig` now has a reset template wired via `PG_REGISTER_WITH_RESET_TEMPLATE`, but because the registered version is still `0`, any existing EEPROM record with version `0` will be copied back over the template defaults during `pgLoad()`. This prevents the new defaults from taking effect for upgraded devices unless they reset EEPROM.

### Issue Context
- `pgLoad()` resets to defaults and then restores EEPROM data only when `version == pgVersion(reg)`.
- `ensureEEPROMContainsValidData()` will reset and write defaults when EEPROM is invalid; older firmware likely wrote a zero-initialized `logConfig` due to being registered without a reset template.

### Fix Focus Areas
- src/main/common/log.c[57-57]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Defaults won't migrate 🐞 Bug ≡ Correctness

logConfig is still registered with version 0, so pgLoad() will restore any existing EEPROM
record over the new reset-template defaults and the fixed defaults won't take effect until EEPROM is
reset. This undermines the PR goal for users upgrading from builds that previously saved a
zero-initialized logConfig.

Agent Prompt

### Issue description
`logConfig` now has a reset template wired via `PG_REGISTER_WITH_RESET_TEMPLATE`, but because the registered version is still `0`, any existing EEPROM record with version `0` will be copied back over the template defaults during `pgLoad()`. This prevents the new defaults from taking effect for upgraded devices unless they reset EEPROM.

### Issue Context
- `pgLoad()` resets to defaults and then restores EEPROM data only when `version == pgVersion(reg)`.
- `ensureEEPROMContainsValidData()` will reset and write defaults when EEPROM is invalid; older firmware likely wrote a zero-initialized `logConfig` due to being registered without a reset template.

### Fix Focus Areas
- src/main/common/log.c[57-57]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools