From patchwork Mon Dec 16 17:04:01 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: 1210644 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=silabs.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=silabs.onmicrosoft.com header.i=@silabs.onmicrosoft.com header.b="YxWwfAYb"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47c74D0QBDz9sRM for ; Tue, 17 Dec 2019 04:07:24 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726470AbfLPRHW (ORCPT ); Mon, 16 Dec 2019 12:07:22 -0500 Received: from mail-dm6nam11on2044.outbound.protection.outlook.com ([40.107.223.44]:54496 "EHLO NAM11-DM6-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727982AbfLPRHF (ORCPT ); Mon, 16 Dec 2019 12:07:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dOx5qC7pxCuDMU8/uaquC2IQAsF6hIrmgT/aW0T11KOf+wb3uO3MZXS7KIGf+WbWuSp+ZlX5QPhbtEmUsf3qcLmjDY5D3qtyzTY7ML5nqijF24F5R3gQAsQS09b4hzGb2+m//fzDGEVxxwkUgHxoUZ0KwEoharwDFHicTERIXLD3QbaGbUI3MLS/pt2ou/xK2QZ0xMJUzasDln9lfvA5oO2EY7B5CLsQSzwonB2i0LH8EHebH4numfS2fjZjIcHSQAZnojCMvUj+Jf+j8r0yz+3cdf/58bjNJk8h9nEPAjpnnNFd9rMJbAXo6Dl5tgOQk6sTs02jyFQIHWqLHPf5fg== 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=3nSgIrJVjHtXm0OSE4HQ+oKKLDyCvgi1hyXl0I9fo4U=; b=Ju3CJa2SRuiUD949YE7904dvzPcMyFaf7ryiZ3e+Hntib89zrTmHg2++r1ZkP247lNL7ZWLCpOMCLXm1fcNnQGy7XzGH5eyqcXnTm7thvjWb0+U0Td1P+xZ7uRZQaiz133MaWHM8FNHvtVpb9vXvLtpFE8ejgrvD8nElQAFcIfQgD7IMP74EadhrsySrrihRggBPXP3Hi53VaFEM2d4Qkfq0w7TMrsi7cNrWe6LhDPGkZaHJ4l5SkJTauA7hykvuMncNAJMt88oc5nbUhglNpqWCfrt1I+G0gIp/1VtFWRKu1ZzuycLtW+NSGRMxsybNEZT6tobJ4xX+LCZxQErQpQ== 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=3nSgIrJVjHtXm0OSE4HQ+oKKLDyCvgi1hyXl0I9fo4U=; b=YxWwfAYbi7YsFPwcpCfmjhbpbB5KAOCUZyNcHH/zX+EoWz8tqzNida/PweO2b6uogKKo9/7Z3wuvqA0Df2wRXZSoV/Sfw98VFkp41gbv7fF8Z56A/mRYFCU4CQWwy8ZFJotL7UJJlWiTHfWU9S9GZIil9q70TIH5KVoNzJlPKbw= Received: from MN2PR11MB4063.namprd11.prod.outlook.com (10.255.180.22) by MN2PR11MB4445.namprd11.prod.outlook.com (52.135.37.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Mon, 16 Dec 2019 17:06:51 +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; Mon, 16 Dec 2019 17:06:51 +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?SsOpcsO0bWUgUG91?= =?utf-8?q?iller?= Subject: [PATCH 55/55] staging: wfx: update TODO Thread-Topic: [PATCH 55/55] staging: wfx: update TODO Thread-Index: AQHVtDLQ/BtiUAAMk0KMGEMeh2Xbgg== Date: Mon, 16 Dec 2019 17:04:01 +0000 Message-ID: <20191216170302.29543-56-Jerome.Pouiller@silabs.com> References: <20191216170302.29543-1-Jerome.Pouiller@silabs.com> In-Reply-To: <20191216170302.29543-1-Jerome.Pouiller@silabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jerome.Pouiller@silabs.com; x-originating-ip: [37.71.187.125] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fad92e05-b22d-44c8-bcab-08d7824a5836 x-ms-traffictypediagnostic: MN2PR11MB4445: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39850400004)(396003)(136003)(189003)(199004)(110136005)(6486002)(107886003)(36756003)(186003)(316002)(66946007)(54906003)(5660300002)(66574012)(66446008)(66556008)(85182001)(66476007)(76116006)(91956017)(64756008)(2616005)(6506007)(15650500001)(85202003)(2906002)(26005)(71200400001)(6512007)(966005)(4326008)(8936002)(81166006)(1076003)(478600001)(86362001)(81156014)(6666004)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4445; 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: HUKN1TWGmiR8eIDZIAWPqyesgxvIP54GBjndjbatA55BSwFMoQ0NTO1cC6mVT9vsTQs6r/rz/8gtePiqEDRXfR11urRHJx80QiHQdIQ+Tn53sjswjJ/0gBScNnm3v4i2rkg2SCvQirIjb/vGx+ps7iRnS58r9euCzno/itjJXm54zVBJ/Cfr3d7rzocSPcHlAmtjKPK+LMKFdQuH6oCmaBuv310+I8Z9SFP95l5C/FGtnughHOT5FH0uFKNBaVmiGYYEidd3Q89H/TKj5DLmnWhuC2+NYX0+Qlvm49KAvUNXtoSjhZzIg/Ybv+k3v97sOihoTJnu91JuOijmxhod5hHkjYGtJAz0v+90pRJZ/S5SaxFfgRbf+dH8MnTk1PlcBkzhZiXJJFjjYVqvoMYOCuGz84uFz3tC4D9kxdmM298KoLhRlMLHJZEA7nbRULj1SOCjxti2yEWGfTfZhtVr6foGXaj865UtmkE5UonV+DE= Content-ID: <909C6621AB20434384C9954A0E10B010@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: silabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: fad92e05-b22d-44c8-bcab-08d7824a5836 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2019 17:04:01.0303 (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: KqrQe9S1bPwJlEMhKQmL57wryivRXqp/9VgOHDpWDSjAvytYz6M4xjwQDY5ed2isCocNNbQR+CNqnwuTER3kzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4445 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@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 | 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@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. + + - 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.