drivers: wifi: Add WiFi drivers for ESP hosted firmware.

[iabdalkader]

This is a host driver for ESP32 chips running the esp-hosted firmware, which turns ESP32s into a WLAN/BT co-processor. See https://github.com/espressif/esp-hosted

Note I'll update this PR to enable the driver for Arduino Portenta C33, once that board is upstream.

[iabdalkader]

This driver does Not run on ESP32, it runs on other host microcontrollers that control ESP32 as a co-processor. So, I don't think this PR is tagged correctly.

[jukkar]

It mentions ESP32 so I assigned to @sylvioalves. Sylvio, please re-assign if this is not related to your areas.

[sylvioalves]

I am planning to give it a try soon. LGTM.

[sylvioalves]

@iabdalkader Are there any blockers to get this merged?

[iabdalkader]

@iabdalkader Are there any blockers to get this merged?

I was waiting on the Portenta-C33 board support to be merged first, so I can enable the driver and make sure everything is okay. I guess it could also be merged now. CC @pillo79 @facchinm

[facchinm]

Cross linking the PR fro Portenta C33 support #85337

[m-cz]

Which version of the esp-hosted firmware is supported? I can see that this PR adds

typedef enum {
	ESP_HOSTED_STA_IF = 0,
	[...]
} esp_hosted_interface_t;

but in esp_hosted interfaces start with ESP_INVALID_IF and ESP_STA_IF is 1. Also the endpoind names are different, "ctrlResp" and "ctrlEvnt" in the PR vs "RPCRsp" and "RPCEvt" in esp_hosted.

[mantriyogesh]

@m-cz, Please note thaThis is not added directly by Espressif.

When it should happen, we would use https://github.com/espressif/esp-hosted-mcu as a base, as it is a dedicated repository to handle the MCU port.

[pillo79]

@m-cz This PR adds minimal support for the esp_hosted_fg variant, whose definitions match:

https://github.com/espressif/esp-hosted/blob/24c86389142110706fb71f7df63979f0112c7580/esp_hosted_fg/common/include/adapter.h#L59

https://github.com/espressif/esp-hosted/blob/24c86389142110706fb71f7df63979f0112c7580/esp_hosted_fg/common/include/adapter.h#L31-L32

[iabdalkader]

Which version of the esp-hosted firmware is supported? I can see that this PR adds

This driver is for esp_hosted_fg, and it's mainly intended to support the firmware that ships with Arduino's Portenta-C33 boards (I believe it's release/fg-v0.0.5, have to double check to be sure). Note that ESP has changed the protocol for FG in a way that seems to break backward compatibility, so new builds will probably not work.

[mantriyogesh]

@iabdalkader Thanks for the contribution!

The driver is based on ESP-Hosted FG, and the current code remains compatible with the latest esp-hosted-fg master.

Please note, the MCU part has been deprecated in esp-hosted-fg and is now maintained separately at esp-hosted-mcu, which is aligned with newer ESP-IDF versions and ESP32-Cx (any ESP as host or slave) targets.

For ESP32-based hosts with Zephyr, we recommend using esp-hosted-mcu for the MCU side. The FG repo still actively supports the Linux host side.

[iabdalkader]

The driver is based on ESP-Hosted FG, and the current code remains compatible with the latest esp-hosted-fg master.

I don't think so. I compared the proto files, and other than the new request/response pairs and events, which I assume we can safely ignore, the protocol has been changed in a breaking way. The main change is adding band_mode to some request and response messages (such as CtrlMsg_Req_ConnectAP) in espressif/esp-hosted@488a063. This would make the latest firmware incompatible with this driver as it will send/recv different packed messages. Couldn't this have been avoided by using new message to set the band mode?

For ESP32-based hosts with Zephyr, we recommend using esp-hosted-mcu for the MCU side

We don't have any plans to add support for that as our boards ship with FG firmware.

[mantriyogesh]

Yes, band_mode was added to support 5G-capable chipsets.

Protobuf itself is backward-compatible. i.e., older firmware can safely ignore unknown fields (although I would still treat this as a logical inconsistency, as discussed in the later part of the comment) as long as they're added using new field numbers. For instance, in esp-hosted@488a063 example, the field:

int32 band_mode = 6;

is added with a new tag number (6), so existing firmware without knowledge of band_mode will ignore it during decoding.

You would be correct; the older firmware would not support 5G-capable devices. But it is expected, as it is a new addition.

But this would pose a problem if you are using a newer host and an older slave. not at the protobuf level, but logical inconsistencies. For example,
the application starts a 5G capable scan. But old slaves would ignore this 5G argument and still treat it as if it were a 2G scan.

For this reason, we always recommend using the same code commit at the host and the slave in case of ESP-Hosted-FG.

[iabdalkader]

Protobuf itself is backward-compatible. i.e., older firmware can safely ignore unknown fields

Other than unknown fields, the new events that were added, such as Event_StationConnectedToAP, must be handled by this driver, otherwise it will just queue them as responses to requests. It should be relatively easy to support those new events and also add band_mode, but the CtrlMsg itself also has been changed. The new one has uid and req_resp_type before the uinion/payload. Will those also be ignored? Or does the host driver have to set them? I still don't think it will work with newer firmware.

For this reason, we always recommend using the same code commit at the host and the slave in case of ESP-Hosted-FG.

It's easier to update the host than the firmware, we already shipped thousands of boards flashed with older firmware.

@mantriyogesh Thanks for taking the time to reply and explain this.