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: + 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
