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

From: JÃrÃme Pouiller
Date: Tue Dec 17 2019 - 11:16:49 EST


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 | 81 +++++++++++++++++++++++++++++++++-------
1 file changed, 67 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/wfx/TODO b/drivers/staging/wfx/TODO
index e44772289af8..6b1cdd24afc9 100644
--- a/drivers/staging/wfx/TODO
+++ b/drivers/staging/wfx/TODO
@@ -1,17 +1,70 @@
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.
+
+ - As suggested by Felix, rate control could be improved following this idea:
+ 3099559.gv3Q75KnN1@pc-42/">https://lore.kernel.org/lkml/3099559.gv3Q75KnN1@pc-42/
+
+ - 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.24.0