Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1873202rwb; Fri, 19 Aug 2022 10:49:29 -0700 (PDT) X-Google-Smtp-Source: AA6agR68SE7StRG84wJYshjC+JtG4i0/n+7+H0yIMk33b91HQzxBziFq6zNn9yRe5+rdxvV2IgUG X-Received: by 2002:a17:90b:605:b0:1fa:b5c5:3449 with SMTP id gb5-20020a17090b060500b001fab5c53449mr14121378pjb.103.1660931369565; Fri, 19 Aug 2022 10:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660931369; cv=none; d=google.com; s=arc-20160816; b=WssmTj3TSbXJ0OKiwcpNNNlWCPoZROX9cVwyEZuo6/vYP6PmtDcqOuozx2qYZlGbzn PWV1stYLLOAv6IUmEnCe3Ci9ldAKowvFhc6zWK15dPs84J4kr2E45B7HtfWNKFF43Ef6 7TkBKWP8sKR5S1Zmpjc/stpn3UYZJunuC90B3Oea3tWFq4H4AkYcx/Xh0wybg0Q31BGq MXUdxxEVDl5Pt2TcbLNwPavdpUXA8Ri+Kbm+aHc0m7igDDwfJE+ygmHXPYKKpksnAyex j7lW+MmGZt+dIL9736sgu3vGtM/KZAJM8Q761iAj2YFELAKX7Coxho5UK8izfjHFFg1T Y15g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=H/4mvViWUl57A1az6fHnkvC2V1VDyS0ZsWKbuu9P7NM=; b=gZHOBtByFaGQ8TYNNwBwAmGK+VNvpiYABsd1zLc9Jo9qT5YPR6z8MYPyI+qMcQ+Jlz PoS81O2uJQuyMziP8lzWlrnuzKZdcPJgJ42PR/l7i8yb62XY6N1MaCRjWgnbszSv/31F ZpqUqHCS6SQPHHGIi9SytRleTQpmTTmQjd0lQ8UH8Sh6ky351xTiG+RCPPV2YX3WyTl4 JCYzAIdmjaIaqhjk8yPkqVARaMss4VrqxMLW/s9UP2K/R3S+3jr175dhqRkuflLONxSi 49WSF8nRSOU//WumisHVwu2/dmSYne7HW626YTMHL8iYNlH7+4iPCi5Emd+SA4l7JkYp PRbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sipsolutions.net header.s=mail header.b=gFF0rdPw; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=sipsolutions.net Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s21-20020a17090ae69500b001f2fa0b5ad0si4830081pjy.67.2022.08.19.10.49.15; Fri, 19 Aug 2022 10:49:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sipsolutions.net header.s=mail header.b=gFF0rdPw; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=sipsolutions.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354841AbiHSRtL (ORCPT + 63 others); Fri, 19 Aug 2022 13:49:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354825AbiHSRsU (ORCPT ); Fri, 19 Aug 2022 13:48:20 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5201E10E94C for ; Fri, 19 Aug 2022 10:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=H/4mvViWUl57A1az6fHnkvC2V1VDyS0ZsWKbuu9P7NM=; t=1660929433; x=1662139033; b=gFF0rdPwpEwLx5pPq6vyyzoApoQ3LYcvsdrf8a3byGe/Rua sW+s+N7t3jrFmwvGRtMVvgkmtRhk63JboLOS+izn4FLjGQEYuhOGFIGeOrCX+HSe2gofoUV9HA1UB NIorbY2eycBw5kslXkHL/Ntm+Do387AoDiSfNGwx7zv3c4WGcFxWLBhCj8RluP4/BKUvBz3wI8O+N OZNSbKYVvHlQZK8/he7u++paAwEGIJfz8P87H2YnpK7DwBosaTGoJw5C5WuPwFKpoIE0ffjoIfuyX 4BWxbqtBlZQ5v6GsuR8F9HGqnfAnXphUlhxhAqS0QjELEViDrWIzwCfXR0VYgPlQ==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1oP5cB-00C6oW-2V; Fri, 19 Aug 2022 19:16:59 +0200 Message-ID: <096c975e7287cbe22fd355bcfd4b3889c890bdc7.camel@sipsolutions.net> Subject: Re: [PATCH 1/9] wifi: mac80211: allow enabling chanctx until hw registration From: Johannes Berg To: Sean Wang Cc: Sean Wang =?UTF-8?Q?=28=E7=8E=8B=E5=BF=97=E4=BA=98=29?= , Felix Fietkau , lorenzo.bianconi@redhat.com, Soul.Huang@mediatek.com, YN.Chen@mediatek.com, Leon.Yen@mediatek.com, Eric-SY.Chang@mediatek.com, Deren Wu , km.lin@mediatek.com, jenhao.yang@mediatek.com, robin.chiu@mediatek.com, Eddie.Chen@mediatek.com, ch.yeh@mediatek.com, posh.sun@mediatek.com, ted.huang@mediatek.com, Stella.Chang@mediatek.com, Tom.Chou@mediatek.com, steve.lee@mediatek.com, jsiuda@google.com, frankgor@google.com, kuabhs@google.com, druth@google.com, abhishekpandit@google.com, shawnku@google.com, linux-wireless@vger.kernel.org, "moderated list:ARM/Mediatek SoC support" Date: Fri, 19 Aug 2022 19:16:58 +0200 In-Reply-To: References: <473fc7b169f288b7815a7736cf33ac0ec1599a09.1660606893.git.objelf@gmail.com> <5b24421363048bff1a9f03174cb0223b3e226bf9.camel@sipsolutions.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-malware-bazaar: not-scanned X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi Sean, > > If we really, really need to allow changing the ops, then we should > > probably make a much larger change to not even pass the ops until > > register, though I'm not really sure it's worth it just to have mt7921 > > avoid loading the firmware from disk before allocation? > Thanks for your input. I thought I'd try to write a patch to follow up > on the idea you mentioned here. >=20 I think you will introduce a bug into mt7921 when you do this, and I'm curious if you will find it ;-) Seriously though, this approach also seems fragile, and I don't even know if other bugs would be introduced. And splitting into three functions (alloc -> set_ops -> register) also feels a bit awkward. Is there really no chance you could add bits to the firmware _file_ format so you can query the capabilities before you actually _run_ the firmware? I guess you could even validate it at runtime again (and just fail is somebody messed up the file), but it would make things a lot simpler, I'm sure. johannes