radio_esp32::coex

The nineteen _coex_* entries: Wi-Fi/Bluetooth coexistence.

What coexistence is, and why these are all zero

The ESP32 has one radio. Wi-Fi and Bluetooth share the antenna, the RF front end and the PHY’s common clocks, so when both are up something has to decide which one transmits in any given microsecond. That arbiter is libcoexist.a, and these nineteen entries are how the Wi-Fi driver asks it for a slot, tells it a channel changed, and reads back the schedule.

FlintOS runs one radio today — BLE is #66 and nothing brings up the controller — so there is nothing to arbitrate. Both references answer that case the same way, and neither by leaving the entries null: esp-idf’s esp_adapter.c and NuttX’s esp32_wifi_adapter.c each wrap every one in #if CONFIG_SW_COEXIST_ENABLE and, in the #else, return zero, return NULL, or do nothing.

So these are not stubs. They are the arm of a conditional that both references compile when coexistence is off, transcribed rather than invented. 0 from _coex_init is ESP_OK — the driver is being told coexistence started fine, which is true, because there is no second radio for it to fail to arbitrate with.

What changes when BLE lands

Every function here becomes a call into libcoexist.a: coex_init, coex_enable, coex_wifi_request and so on are already in the archive this crate links. That is the whole change — the signatures below are the archive’s, so the bodies get a call and the module doc loses this section.

Until then, the danger worth naming: if the Bluetooth controller is ever started without these being wired up, the two radios will transmit over each other. The symptom is packet loss on both, under load, with nothing in either driver’s logs. radio-bt is the feature that would do it, and kernel::radio is where that gate lives.