In order to use the WPA3 with the WF(M)200 through Linux, you could use the following wpa_supplicant.conf:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid="WPA3_000"
psk="xxxxxxxxxxxxx"
key_mgmt= SAE
proto=RSN
pairwise=CCMP
group=CCMP
ieee80211w=2
}

Note ieee80211w could be set to 1 or 2. See the definition of the parameters in the https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf

With a CISCO AP AIR-AP1852E-E-K9, firmware 8.10.105.0 configured with WPA3 security and a Raspberry Pi with the SD-card 3.2 with BRD8022/23A with FW3.8.0 and the Driver WFX 2.5.2, you could get this with WPA3 security enabled:

First with a Wi-Fi scan, you should get SAE on the security used by the AP with WPA3:

pi@rpi-123:~ $ wfx_sta --scan
Starting  wpa_supplicant
Scanning access points...
bssid / frequency / signal level / flags / ssid
x:x:x:x:x:x       2462    -43     [WPA2-PSK+SAE-CCMP][ESS]        WPA3_000
...

Then using the wpa_supplicant_WPA3.conf above, we could get the association like below:

pi@rpi-123:~ $ wfx_sta --conf wpa_supplicant_WPA3.conf
Asking dhcpcd to control wlan0
Starting  wpa_supplicant
Setting up connection
Waiting for connection
Associated
Waiting for DHCP
DHCP lease obtained
Success: wlan0 connected to WPA3_000 with IP X.X.X.X

Then we could get the following status with wpa_cli:

pi@rpi-123:~ $ wpa_cli status
Selected interface 'wlan0'
bssid=xx:xx:xx:xx:xx:xx
freq=2462
ssid=WPA3_000 
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=SAE
pmf=1
mgmt_group_cipher=BIP
sae_group=19
wpa_state=COMPLETED
ip_address=X.X.X.X

We could check the status indicating key_mgmt=SAE and pmf=1 in bold above because it is associated with an AP using the WPA3 security.

Remarks:

• WPA3 security is now mandatory for all Wi-Fi Alliance certified products but it is relatively new and not supported by all Access Point or station already installed or sold in 2020.
• Please note WPA3 could be not supported with old wpa_supplicant release. We have tested successfully this with a Linux kernel 4.19.57-v7l+ and the wpa_supplicant release v2.8-devel.

When the host asks the WF200 or WFM200 to limit the Tx power, WF(M)200 adds FRONT_END_LOSS_TX_QDB from the requested value (see UG404 on the PDS file).

Hence:

• if FRONT_END_LOSS_TX_QDB is 0, the host controls the power limitation at the output of the RF1 and RF2 pin of WF(M)200

• if FRONT_END_LOSS_TX_QDB is set to antenna gain (negative value) and loss on the board or from a FEM (positive value), the host controls the limitation in EIRP

Note that the Linux hosts work with EIRP values. So, if WF(M)200 aims to work with a Linux host, FRONT_END_LOSS_TX_QDB should be set with the antenna gain.

Note also this is only a Tx output limitation and this limitation could be higher than the WF(M)200 Power Amplifier is allowed or able to transmit depending on RF certification constraint and backoff set in the PDS file according to the channel or the PHY rate.

Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:

1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).

2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.

3) The WUP signal should be connected between the host and the WF(M)200.

4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the  source code of WFX driver examples provided on Github).

• When the host CPU is not sending frame to WF200 then the WUP pin should be low in order the WF200 stops the SPI or SDIO interface power consumption during the associated sleep time period (see AN1219 appendix B).
• The SPI or SDIO clock should be stopped when the WUP pin is low.

5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.

6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).

7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.

8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.

9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).

10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
       VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).

Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.

The AN1219 provides some additional details about this (see https://www.silabs.com/documents/public/application-notes/an1219-power-consumption-wfm200.pdf).

WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)

The information in this article is specific to using the wfx driver in SDIO with AllWinner SoCs on Linux.

The allwinner architecture seems to have some race conditions while masking the SDIO IRQs.

In some case the IRQ is reported twice to the wfx driver, then the control register is read twice and data is read twice.

This subject is discussed in this Linux Kernel discussion Thread

This points this an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.

This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.

As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.

There are 2 possible error messages, depending on the first CRC location:

• If the QUEUE length is short (below 24x bytes), there is only 1 CRC: the final one. The message is then related to a 'sunxi data error'.
• If the QUEUE length is long (more than 24x bytes), there are intermediate CRCs. The message is then related to a 'wfx-sdio read error'

At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect  the double SDIO IRQs with the wfx driver and drop them.

A 'workaround/patch' has been created for this purpose.

Symptoms

The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:

sunxi-mmc 1c12000.mmc: data error, sending stop command

wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110

Workaround Patch

This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.

From 61e1e589ce720235ddd0e2d569c5d81fe155ed1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= <jerome.pouiller@silabs.com>
Date: Wed, 22 Apr 2020 10:10:30 +0200
Subject: [PATCH] bh: try to detect duplicated IRQs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The allwinner architecture seems to have some race conditions while
masking the IRQs. So, in some case the IRQ is reported twice to the
driver, then the control register is read twice and data is read twice.

Until now, the duplicated access to the control register always happens
before the access to the data (note that it does not prove it will be
always the case). Thus, it is easy to detect that pattern and drop the
faulty access.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
 bh.c   | 5 +++++
 hwio.c | 7 +++++++
 wfx.h  | 2 ++
 3 files changed, 14 insertions(+)

diff --git a/bh.c b/bh.c
index 55724e4295..dd6b4095d3 100644
--- a/bh.c
+++ b/bh.c
@@ -287,6 +287,10 @@ void wfx_bh_request_rx(struct wfx_dev *wdev)
     u32 cur, prev;
 
     control_reg_read(wdev, &cur);
+    if (cur == ~0) {
+        dev_warn(wdev->dev, "drop probably duplicated IRQ\n");
+        return;
+    }
     prev = atomic_xchg(&wdev->hif.ctrl_reg, cur);
     complete(&wdev->hif.ctrl_ready);
     queue_work(system_highpri_wq, &wdev->hif.bh);
@@ -324,6 +328,7 @@ void wfx_bh_poll_irq(struct wfx_dev *wdev)
     start = ktime_get();
     for (;;) {
         control_reg_read(wdev, &reg);
+        wdev->last_read_reg_is_ctrl = false;
         now = ktime_get();
         if (reg & 0xFFF)
             break;
diff --git a/hwio.c b/hwio.c
index 777217cdf9..ee2fbc112d 100644
--- a/hwio.c
+++ b/hwio.c
@@ -34,6 +34,11 @@ static int read32(struct wfx_dev *wdev, int reg, u32 *val)
     *val = ~0; // Never return undefined value
     if (!tmp)
         return -ENOMEM;
+    if (reg == WFX_REG_CONTROL && wdev->last_read_reg_is_ctrl) {
+        kfree(tmp);
+        return 0;
+    }
+    wdev->last_read_reg_is_ctrl = !!(reg == WFX_REG_CONTROL);
     ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, tmp,
                         sizeof(u32));
     if (ret >= 0)
@@ -149,6 +154,7 @@ static int indirect_read(struct wfx_dev *wdev, int reg, u32 addr,
         goto err;
     }
 
+    wdev->last_read_reg_is_ctrl = false;
     ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, buf, len);
 
 err:
@@ -235,6 +241,7 @@ int wfx_data_read(struct wfx_dev *wdev, void *buf, size_t len)
 
     WARN((long)buf & 3, "%s: unaligned buffer", __func__);
     wdev->hwbus_ops->lock(wdev->hwbus_priv);
+    wdev->last_read_reg_is_ctrl = false;
     ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv,
                         WFX_REG_IN_OUT_QUEUE, buf, len);
     _trace_io_read(WFX_REG_IN_OUT_QUEUE, buf, len);
diff --git a/wfx.h b/wfx.h
index 3ea3a41216..dbb4870ecc 100644
--- a/wfx.h
+++ b/wfx.h
@@ -101,6 +101,8 @@ struct wfx_dev {
 
     struct hif_rx_stats    rx_stats;
     struct mutex        rx_stats_lock;
+
+    bool            last_read_reg_is_ctrl;
 };
 
 struct wfx_vif {
-- 
2.26.1