[PATCH 55/55] staging: wfx: update TODO

[JÃrÃme Pouiller]

From: JÃrÃme Pouiller <jerome.pouiller@xxxxxxxxxx>

Update the TODO list of wfx driver with a more precise list of items.

Signed-off-by: JÃrÃme Pouiller <jerome.pouiller@xxxxxxxxxx>
---
 drivers/staging/wfx/TODO | 78 ++++++++++++++++++++++++++++++++--------
 1 file changed, 64 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/wfx/TODO b/drivers/staging/wfx/TODO
index e44772289af8..17426d9d8c15 100644
--- a/drivers/staging/wfx/TODO
+++ b/drivers/staging/wfx/TODO
@@ -1,17 +1,67 @@
 This is a list of things that need to be done to get this driver out of the
 staging directory.
 
-  - I have to take a decision about secure link support. I can:
-      - drop completely
-      - keep it in an external patch (my preferred option)
-      - replace call to mbedtls with kernel crypto API (necessitate a
-        bunch of work)
-      - pull mbedtls in kernel (non-realistic)
-
-  - mac80211 interface does not (yet) have expected quality to be placed
-    outside of staging:
-      - Some processings are redundant with mac80211 ones
-      - Many members from wfx_dev/wfx_vif can be retrieved from mac80211
-        structures
-      - Some functions are too complex
-      - ...
+  - Allocation of "link ids" is too complex. Allocation/release of link ids from
+    sta_add()/sta_remove() should be sufficient.
+
+  - The path for packets with IEEE80211_TX_CTL_SEND_AFTER_DTIM flags should be
+    cleaned up. Currently, the process involve multiple work structs and a
+    timer. It could be simplifed. In add, the requeue mechanism triggers more
+    frequently than it should.
+
+  - All structures defined in hif_api_*.h are intended to sent/received to/from
+    hardware. All their members whould be declared __le32 or __le16. These
+    structs should only been used in files named hif_* (and maybe in data_*.c).
+    The upper layers (sta.c, scan.c etc...) should manage mac80211 structures.
+    See:
+       https://lore.kernel.org/lkml/20191111202852.GX26530@xxxxxxxxxxxxxxxxxx
+
+  - Once previous item done, it will be possible to audit the driver with
+    `sparse'. It will probably find tons of problems with big endian
+    architectures.
+
+  - hif_api_*.h whave been imported from firmware code. Some of the structures
+    are never used in driver.
+
+  - Driver try to maintains power save status of the stations. However, this
+    work is already done by mac80211. sta_asleep_mask and pspoll_mask should be
+    dropped.
+
+  - wfx_tx_queues_get() should be reworked. It currently try compute itself the
+    QoS policy. However, firmware already do the job. Firmware would prefer to
+    have a few packets in each queue and be able to choose itself which queue to
+    use.
+
+  - When driver is about to loose BSS, it forge its own Null Func request (see
+    wfx_cqm_bssloss_sm()). It should use mechanism provided by mac80211.
+
+  - AP is actually is setup after a call to wfx_bss_info_changed(). Yet,
+    ieee80211_ops provide callback start_ap().
+
+  - The current process for joining a network is incredibly complex. Should be
+    reworked.
+
+  - Monitoring mode is not implemented despite being mandatory by mac80211.
+
+  - "compatible" value are not correct. They should be "vendor,chip". See:
+       https://lore.kernel.org/driverdev-devel/5226570.CMH5hVlZcI@pc-42
+
+  - The "state" field from wfx_vif should be replaced by "vif->type".
+
+  - It seems that wfx_upload_keys() is useless.
+
+  - "event_queue" from wfx_vif seems overkill. These event are rare and they
+     probably could be handled in a simpler fashion.
+
+  - Feature called "secure link" should be either developed (using kernel
+    crypto API) or dropped.
+
+  - In wfx_cmd_send(), "async" allow to send command without waiting the reply.
+    It may help in some situation, but it is not yet used. In add, it may cause
+    some trouble:
+      https://lore.kernel.org/driverdev-devel/alpine.DEB.2.21.1910041317381.2992@hadrien/
+    So, fix it (by replacing the mutex with a semaphore) or drop it.
+
+  - Chip support P2P, but driver does not implement it.
+
+  - Chip support kind of Mesh, but driver does not implement it.
-- 
2.20.1