From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0746FC3A5A0 for ; Mon, 19 Aug 2019 20:23:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D7E49214DA for ; Mon, 19 Aug 2019 20:23:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728398AbfHSUXe (ORCPT ); Mon, 19 Aug 2019 16:23:34 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:47590 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728055AbfHSUXd (ORCPT ); Mon, 19 Aug 2019 16:23:33 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hzoBa-00044T-W5; Mon, 19 Aug 2019 22:23:27 +0200 Message-ID: Subject: Re: [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm From: Johannes Berg To: Alexander Wetzel , Luca Coelho Cc: linux-wireless@vger.kernel.org Date: Mon, 19 Aug 2019 22:23:24 +0200 In-Reply-To: References: <20190629195015.19680-1-alexander@wetzel-home.de> <20190629195015.19680-4-alexander@wetzel-home.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 2019-08-19 at 17:52 +0200, Alexander Wetzel wrote: > We may also get away by adding only means to pass the keyid of the MPDU > (zero or one) to the HW. That could be done quite simple, I think: > > We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and > IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures > iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3. > When the firmware would check and use the key referenced by the STA + > flag-id prior to the "last installed" key that should be sufficient. > By still using the last installed key without any of the new flags set > we also would remain backward compatible. > > If you have any experimental firmware to test I'm happy to do so:-) > Till then I'm back using older iwlwifi cards. I'm not convinced that we can change the TX API at all, I suspect we have to go detect it as we saw in the other patch. If we do actually have the ability to change the TX API it might be simpler overall, but anyway, I'd have to go look at how this is all implemented before I comment further. Doesn't seem like an intractable problem, the only question is if we get to spend time on it :) johannes