wifi: esp32: add wifi station support

[sylvioalves]

This PR is part of the #29394.

It adds support for ESP32 WiFI SoC.

Note: Zephyr has no support yet for non-offloaded wifi. Once we have support for it, we shall integrate.

Closes #3723.

[github-actions]

The following projects have a revision update in this Pull Request:

Name	Old Revision	New Revision
hal_espressif	zephyrproject-rtos/hal_espressif@416ae58	zephyrproject-rtos/hal_espressif@1610702 (zephyr)

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[sylvioalves]

@mniestroj PTAL

[sylvioalves]

@carlescufi @tbursztyka ok, make sense. @rlubos, I'll wait some input from you as well before moving ahead. Thanks.
Perhaps renaming the base folder do espressif and subfolders with device specific is also a good approach.

[mniestroj]

• drivers/wifi/esp/ (already in tree) is a offloaded network driver for any Zephyr platform, which is connected over UART to ESP chip hosting ESP-AT firmware.
• drivers/wifi/esp32/ (submitted here) is a network driver that will run natively on esp32 chip.

There will be no shared code between both drivers. Maybe we should move drivers/wifi/esp/ to drivers/wifi/esp-at/ to make space for native driver introduced in this PR?

[rlubos]

Well, we don't have exactly the same case in the tree yet (unless I miss something), the closest I could find is the eswifi which have to implementations - one utilizing socket offloading and other using net offloading. But in this case the drivers share some common sources, the socket offloading is optional (https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/wifi/eswifi/CMakeLists.txt#L22).

Since the implementations are separate here IMO the cleanest would be to move them into some subdirectories under drivers/wifi/esp and then have top level Kconfig with a general menuconfig WIFI_ESP switch and a choice WIFI_ESP_MODE to select between WIFI_ESP_NATIVE and WIFI_ESP_OFFLOADED. Based on the selection, the appropriate subdirectory could be added in the CMakeLists.txt. This should have minimal impact on the existing and new code/Cmake files/Kconfig files.

[sylvioalves]

Well, we don't have exactly the same case in the tree yet (unless I miss something), the closest I could find is the eswifi which have to implementations - one utilizing socket offloading and other using net offloading. But in this case the drivers share some common sources, the socket offloading is optional (https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/wifi/eswifi/CMakeLists.txt#L22).

Since the implementations are separate here IMO the cleanest would be to move them into some subdirectories under drivers/wifi/esp and then have top level Kconfig with a general menuconfig WIFI_ESP switch and a choice WIFI_ESP_MODE to select between WIFI_ESP_NATIVE and WIFI_ESP_OFFLOADED. Based on the selection, the appropriate subdirectory could be added in the CMakeLists.txt. This should have minimal impact on the existing and new code/Cmake files/Kconfig files.

I am ok with this approach.
I'll PR this in here and we can continue discussing any necessary modifications.

[mniestroj]

Since the implementations are separate here IMO the cleanest would be to move them into some subdirectories under drivers/wifi/esp and then have top level Kconfig with a general menuconfig WIFI_ESP switch and a choice WIFI_ESP_MODE to select between WIFI_ESP_NATIVE and WIFI_ESP_OFFLOADED. Based on the selection, the appropriate subdirectory could be added in the CMakeLists.txt. This should have minimal impact on the existing and new code/Cmake files/Kconfig files.

I don't agree about choosing driver "mode" over Kconfig. Those are two different drivers, for two different platforms. One is utilizing ESP chip connected over UART, the other runs natively on ESP. The offloaded driver doesn't even need to communicate with ESP (can be any other WiFi capable chip), as long as the other end is implementing all the AT commands documented (implemented) in ESP-AT interface.

So I would consider two possibilities:

1. use drivers/wifi/esp-at/ and drivers/wifi/esp32/ (I opt for that),
2. use drivers/wifi/esp/at/ and drivers/wifi/esp/esp32/, both should be supported simultaneously, without any Kconfig "choice".

[rlubos]

Those are two different drivers, for two different platforms. One is utilizing ESP chip connected over UART, the other runs natively on ESP.

This sheds some new light on the topic, thanks. Based on the previous discussion I had an impression we talk about two variants of a driver for ESP chip, just integrated with the network stack at a different level. But from what you say, the offloaded driver can run on any device with ESP connected over UART/SPI, right? @tbursztyka @carlescufi Based on this feedback, do you still think it makes sense to "merge" the two drivers?

[sylvioalves]

@mniestroj great point. If adding as Kconfig option, it should be possible to use both simultaneously as each one implements different stuff.
If option 1 (use drivers/wifi/esp-at/ and drivers/wifi/esp32/ (I opt for that)) is the way, we won't have to change this PR regarding that.

[mniestroj]

But from what you say, the offloaded driver can run on any device with ESP connected over UART/SPI, right?

Right. Currently only UART, but potentially could be other bus as well.

If option 1 (use drivers/wifi/esp-at/ and drivers/wifi/esp32/ (I opt for that)) is the way, we won't have to change this PR regarding that.

Correct. I can rename s/esp/esp-at/ if others agree that is the way to go.

[mniestroj]

@tsvehagen Including you into discussion, as the original author of ESP offloaded driver.

[carlescufi]

@tbursztyka @carlescufi Based on this feedback, do you still think it makes sense to "merge" the two drivers?

No, I don't. I think that the proposal by @mniestroj makes sense.

[nandojve]

Since I use this to keep some infrastructure in subsys, I would like to mention that agreed with @mniestroj proposal.

[sylvioalves]

@mahavir, PTAL

[nandojve]

Updated the dtsi file as suggest by @galak.

Great!