From patchwork Tue Dec 17 16:15:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?SsOpcsO0bWUgUG91aWxsZXI=?= X-Patchwork-Id: 11298111 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C60986C1 for ; Tue, 17 Dec 2019 16:16:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 908B221835 for ; Tue, 17 Dec 2019 16:16:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=silabs.onmicrosoft.com header.i=@silabs.onmicrosoft.com header.b="WSx9dI7y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729280AbfLQQQq (ORCPT ); Tue, 17 Dec 2019 11:16:46 -0500 Received: from mail-eopbgr680042.outbound.protection.outlook.com ([40.107.68.42]:26848 "EHLO NAM04-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729156AbfLQQQJ (ORCPT ); Tue, 17 Dec 2019 11:16:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PUJ1+GyR4vJ4S5c+7XVOKWz5AEACpK5VXnXpkQ7w+NqEu1BWvUuQLNrpooQv54Cro4uMhbSHNkZpSRweyjkxFXfp/mMbNqiGe5gHBdC2x+qJ6JSVU54sYNC8T9zRIIEarKFe5YsjcfedvRU7gI3catoSALPZPA5Q3KGi25xd2jfhJktamENfp2WxIS3iOVwuO7iT3MeN/QWPGaeuP1KfswaOUBLRrbjHkgEKt7eNzuzPTz68t9G75aOca5J96GdLmNCUGoatAhL25xIhaTqKHKjHcqYoEYmvhMK7jjVzXyjQywlJJR9DV4Io61NzUOoPwvUTDunuqjHmmbSQMqy24A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lrvld7QLg+34BaehMcizNTeqjcM2jdt+MzrGluOpN+U=; b=aaUuYsHVHOZWX2VR+PrWHsUjj0RqC17wp1EBKQzEyfb7ywN08WC44jW3glGzNS/RKciWIT5pUcSGMijeJZVjrbLb6VFkm0Gu1cFcvfVpLphAdvpfK0AW1OiyfIUA2au2z69pgY5oK9w2HOwPzbNVSMiDX4sjCr0DTALd6S0uAJ88JQf+TYYGQXnGXjDcdvNO5rF3v/VDae2SUgypwPmT2bMzuJRrzAcPP7PETjFFJrNYatmqmZpwJVS6FXlQSA62UzGWrfHI9eu/Hcv0e1240LJ6QMOOC4XCiikc6BKdrfxuT7dYA8vNwBRaoKzR+08CFYPQ72/nzPzLncHi4764ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=silabs.com; dmarc=pass action=none header.from=silabs.com; dkim=pass header.d=silabs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=silabs.onmicrosoft.com; s=selector2-silabs-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lrvld7QLg+34BaehMcizNTeqjcM2jdt+MzrGluOpN+U=; b=WSx9dI7yw84xtUHr/o5t34R1DDnQLavKk3hobBKr+2DrhQRwZ6H7f+IjCrijdpmqX5U9MJsAV0lsd1iPiOES3plqiwVi/sOp7dSquzUK4mT//yGK3SGBeswujqM+YGSdGSdXHPyrpk9XAiHsA2nItvs8C5Ox7hLyrpH4lfzGrMY= Received: from MN2PR11MB4063.namprd11.prod.outlook.com (10.255.180.22) by MN2PR11MB3791.namprd11.prod.outlook.com (20.178.254.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Tue, 17 Dec 2019 16:16:06 +0000 Received: from MN2PR11MB4063.namprd11.prod.outlook.com ([fe80::f46c:e5b4:2a85:f0bf]) by MN2PR11MB4063.namprd11.prod.outlook.com ([fe80::f46c:e5b4:2a85:f0bf%4]) with mapi id 15.20.2538.019; Tue, 17 Dec 2019 16:16:06 +0000 From: =?utf-8?b?SsOpcsO0bWUgUG91aWxsZXI=?= To: "devel@driverdev.osuosl.org" , "linux-wireless@vger.kernel.org" CC: "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Kalle Valo , "David S . Miller" , =?utf-8?b?SsOpcsO0bWUgUG91aWxsZXI=?= Subject: [PATCH v2 55/55] staging: wfx: update TODO Thread-Topic: [PATCH v2 55/55] staging: wfx: update TODO Thread-Index: AQHVtPU6C/GkqvVkY0OgUfqfRu8C9A== Date: Tue, 17 Dec 2019 16:15:42 +0000 Message-ID: <20191217161318.31402-56-Jerome.Pouiller@silabs.com> References: <20191217161318.31402-1-Jerome.Pouiller@silabs.com> In-Reply-To: <20191217161318.31402-1-Jerome.Pouiller@silabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: PR0P264CA0174.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1c::18) To MN2PR11MB4063.namprd11.prod.outlook.com (2603:10b6:208:13f::22) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jerome.Pouiller@silabs.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: git-send-email 2.24.0 x-originating-ip: [37.71.187.125] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a35cfc4f-93d0-454e-028c-08d7830c5d36 x-ms-traffictypediagnostic: MN2PR11MB3791: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(396003)(376002)(366004)(346002)(136003)(39860400002)(189003)(199004)(2906002)(52116002)(107886003)(2616005)(86362001)(478600001)(6486002)(15650500001)(4326008)(64756008)(66556008)(66476007)(81156014)(966005)(66946007)(6506007)(1076003)(316002)(66446008)(8936002)(71200400001)(81166006)(5660300002)(36756003)(26005)(186003)(8676002)(85202003)(6666004)(66574012)(85182001)(110136005)(54906003)(6512007);DIR:OUT;SFP:1101;SCL:1;SRVR:MN2PR11MB3791;H:MN2PR11MB4063.namprd11.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: silabs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: D0d0TNcCV9I6VzbCVelZGhwjwy7eHP2uCXgmE09912exIvcLfSBjr+oChgIyxBj4OiVhhg95m8dxZhpkHZiVMk+KeokTTFSj8XmQ/b2Ww8kuWG1WRjHS9gt6A9QMurjgUVVTuiSq40UfQbhrJpLWBnoADXXo2G7QbLU6S7MKXgDqHFj+iUlIf4uo2orCY5BenYgwJJMhiQZbStlUlB6Xv2KT9Wk232Yxo6h4mnYdFd+ZaF0AJRFYtlaYsA61CWC4Ffm0OC2xxt4TutsgbsUF44a8sTtlSqi55MWk85gJgbI/bQpCRhuext67KRIdwl7LnUe4ObAEF+2VfLpnvzcdCxHhE26ABpQ1ieAG8VkAsQ11GKsmUHbvIgYmu8rqD3oc/dJcIkQgPNCTjL0IIh3Jn9cgRNxrHRX5oi7TIPTx1YLYTE2OGNXcVIXnMyxKEIEWYtMMvTIB3hbK0A8XR1vpo8PxK6SW2nKmB0scR8P7Ck0= Content-ID: <59C5E5F22469AC4DB54424F3CB45A775@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: silabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: a35cfc4f-93d0-454e-028c-08d7830c5d36 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2019 16:15:42.4340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54dbd822-5231-4b20-944d-6f4abcd541fb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PCGzH/MkwkBvlFG1OBMlxUMz3Hk5XlxT95YXGwUqxnvXENO/McgQuUne1+ogFzp8pu2wj7nLrm0lup71GcZtlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3791 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org From: Jérôme Pouiller Update the TODO list of wfx driver with a more precise list of items. Signed-off-by: Jérôme Pouiller --- 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@ZenIV.linux.org.uk + + - 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.