Message ID | e84a3f80fe536787f7a2c7180507efc36cd14f95.1682358088.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2910958vqo; Mon, 24 Apr 2023 10:49:07 -0700 (PDT) X-Google-Smtp-Source: AKy350ZJN2oaGzkdlLF1FhSGc7lQkIQjkr8J2X4e7E2pkwYWsmcIxf/yCWteaiDJTFJeeak5AtdT X-Received: by 2002:a17:902:db05:b0:1a6:67e1:4d2c with SMTP id m5-20020a170902db0500b001a667e14d2cmr18828788plx.6.1682358547436; Mon, 24 Apr 2023 10:49:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682358547; cv=none; d=google.com; s=arc-20160816; b=im1zqpWJdbwadeWtYp6wnCmLMEeT7sfkbMc9DynmlI9cMiCw/vDJFNlDCH1zUw7DMR cpEciJW4K/Laf6GOauVSHOCMd0hlSBKw8DPm0wZDHAcDrqlGuLxauJUyDtnZ3vVFUQnZ eUz7LeyhGvzpkxRf1VaFc/A3ePJcOttyV9YWEbQGMfN6JbGxuabV+U7HLOBN7g58qXj1 X93UI+TTHerFnXERqgwOtkyKQBSj5bfRjhX9xv5jQ4BOVtcGKJ0jBrzXVHd1TZSU83Gi EwhH3s3aQSj1DdYofy7kw4Q96Yrk4dBXeB2zPb45xIjcMxXYo82XRurrYk/Lr+IB3yG9 I70w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=RGet4KUq9B1fJpP0L51TGQdjanN5MhnW13ggXU8IDME=; b=a3ElFzIgBAOuRtvKJn1LvlQi21eDgmyygnQHWx0kfpshpXPH6d0forxdcqdg8anVr5 yIx6tjZ44GiO1A82z39IMIGL2VfomK0sdPB1bVXqihOyrHQ7o5mGyJDkIEUjfzlKa2RP 55XBFLQ18YGqwur3QYI0XgoWg4D5N19IlB+5WCAtdp1KHoR4MNpI2egFFoqbCCvAz2/Y DMoPRzSulGqy+dX1/MIfzZYmSLkFenIke2EsqA4Lr3VSdFNA+E+AhGnkcPCuqaczOVzh EdXTZ+y+VSgya0Dn6Oc3EuC3wiK2g+Bi5N8PBswb+pI3DHLIE0o3/UQFNZanK+oFS4Cr ukug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=EeI3HeSg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ix5-20020a170902f80500b001a64541624asi11170107plb.484.2023.04.24.10.48.51; Mon, 24 Apr 2023 10:49:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@wanadoo.fr header.s=t20230301 header.b=EeI3HeSg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231726AbjDXRmP (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Mon, 24 Apr 2023 13:42:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230515AbjDXRmN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Apr 2023 13:42:13 -0400 Received: from smtp.smtpout.orange.fr (smtp-23.smtpout.orange.fr [80.12.242.23]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F082E9 for <linux-kernel@vger.kernel.org>; Mon, 24 Apr 2023 10:42:10 -0700 (PDT) Received: from pop-os.home ([86.243.2.178]) by smtp.orange.fr with ESMTPA id r0CUpcWVXvolhr0CUpT3DX; Mon, 24 Apr 2023 19:42:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1682358129; bh=RGet4KUq9B1fJpP0L51TGQdjanN5MhnW13ggXU8IDME=; h=From:To:Cc:Subject:Date; b=EeI3HeSgO1T+RpbkqVax1D07SQkY7niWGixqo6V6IiUhuatBwX71Rf4spa/flXjx5 +f2rmxEFzxNdx2EPGVUwOAVnmkEKsgI1T015mLAWqkv76eslV1Hh7azG8Zp0BDhqHX SvW2kamNfl8YoUeV6Nm1roaQbjHl+uD1Z7z7QBoYHy4BsZ6P5uOPL19dCxNwJVWN68 f8dQ1Z1Aq0d2Ua/NQKIc/+7gpT2n7m115gwStE2Oqs/C3/3yi0liQSaNkt6HLYB5qx Y1GCdFdvDb+rdJ81rz7eVQcRHcfPAUceHxtUAyHJ7bp457GTNuHQnP5j5l+EIGZ3gP rQHT+QD+KjzXw== X-ME-Helo: pop-os.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Mon, 24 Apr 2023 19:42:09 +0200 X-ME-IP: 86.243.2.178 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: Johannes Berg <johannes@sipsolutions.net>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Aloka Dixit <quic_alokad@quicinc.com>, Muna Sinada <quic_msinada@quicinc.com> Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, Johannes Berg <johannes.berg@intel.com>, linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH net] wifi: mac80211: Fix puncturing bitmap handling in __ieee80211_csa_finalize() Date: Mon, 24 Apr 2023 19:42:04 +0200 Message-Id: <e84a3f80fe536787f7a2c7180507efc36cd14f95.1682358088.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764080795821627705?= X-GMAIL-MSGID: =?utf-8?q?1764080795821627705?= |
Series |
[net] wifi: mac80211: Fix puncturing bitmap handling in __ieee80211_csa_finalize()
|
|
Commit Message
Christophe JAILLET
April 24, 2023, 5:42 p.m. UTC
'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than
an u32.
So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon()
accordingly.
In the commit in Fixes, only ieee80211_start_ap() was updated.
Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile tested only.
---
net/mac80211/cfg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Mon, Apr 24, 2023 at 07:42:04PM +0200, Christophe JAILLET wrote: > 'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than > an u32. > So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon() > accordingly. > > In the commit in Fixes, only ieee80211_start_ap() was updated. > > Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap") > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > Compile tested only. > --- > net/mac80211/cfg.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Horman <simon.horman@corigine.com>
Christophe JAILLET <christophe.jaillet@wanadoo.fr> writes: > 'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than > an u32. > So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon() > accordingly. > > In the commit in Fixes, only ieee80211_start_ap() was updated. > > Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap") > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> FWIW mac80211 patches go to wireless tree, not net.
Le 28/04/2023 à 07:04, Kalle Valo a écrit : > Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org> writes: > >> 'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than >> an u32. >> So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon() >> accordingly. >> >> In the commit in Fixes, only ieee80211_start_ap() was updated. >> >> Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap") >> Signed-off-by: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org> > > FWIW mac80211 patches go to wireless tree, not net. > Hi, net/<something> or drivers/net/<something> goes to 'net'. drivers/net/wireless/<something> goes to 'wireless'. now: net/mac80211/ goes also to 'wireless' as well. ath11 and ath12 are special cases that goes to 'ath'. Based on the get_maintainer.pl, my last patch against drivers/isdn looks well suited to deserve a -net-next as well? without speaking of -next variations. How many other oddities are there? I try to make my best to add net or net-next. I could do the same with wireless. (I guess that there is also a wireless-next?) I can do it when rules are SIMPLE. Is there a place where ALL these "rules" are described? Could MAINTAINERS and scripts be instrumented for that? I DO understand that the easiest it is for maintainers, the better for them, but please stop asking for casual contributors to know that and follow your, not that easy to find or remember, rules. I'm tempt not to TRY to put the right branch in the subject of my commits anymore, because even when I try to do it right and follow simple rules for that, it is not enough and I'm WRONG. Most of my contributions are related to error handling paths. The remaining ones are mostly related to number of LoC reduction. Should my contributions be ignored because of the lack of tools to help me target the correct branch, then keep the bugs and keep the LoC. git log --oneline --author=jaillet --grep Fixes: drivers/net | wc -l 97 git log --oneline --author=jaillet drivers/net | wc -l 341 git log --oneline --author=jaillet --grep Fixes: net | wc -l 7 git log --oneline --author=jaillet net | wc -l 327 No hard feelings, but slightly upset. :/ CJ
Christophe JAILLET <christophe.jaillet@wanadoo.fr> writes: > Le 28/04/2023 à 07:04, Kalle Valo a écrit : >> Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org> writes: >> >>> 'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than >>> an u32. >>> So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon() >>> accordingly. >>> >>> In the commit in Fixes, only ieee80211_start_ap() was updated. >>> >>> Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap") >>> Signed-off-by: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org> >> >> FWIW mac80211 patches go to wireless tree, not net. > > net/<something> or drivers/net/<something> goes to 'net'. > drivers/net/wireless/<something> goes to 'wireless'. > > now: > net/mac80211/ goes also to 'wireless' as well. > ath11 and ath12 are special cases that goes to 'ath'. > > Based on the get_maintainer.pl, my last patch against drivers/isdn > looks well suited to deserve a -net-next as well? > > > without speaking of -next variations. > > > How many other oddities are there? Oddities? We have had separate wireless trees for something like 15 years now, so not a new thing :D But we have also separate trees for most active wireless drivers. For example, Felix has a tree for mt76, Intel for iwlwifi, I have for ath9k/ath10k/ath11k/ath12k and so on. > I try to make my best to add net or net-next. > I could do the same with wireless. (I guess that there is also a > wireless-next?) Yes, there is also wireless-next. > I can do it when rules are SIMPLE. > > Is there a place where ALL these "rules" are described? > Could MAINTAINERS and scripts be instrumented for that? The maintainers file should document what tree to use: QUALCOMM ATHEROS ATH11K WIRELESS DRIVER M: Kalle Valo <kvalo@kernel.org> L: ath11k@lists.infradead.org S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git F: Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml F: drivers/net/wireless/ath/ath11k/ If a wireless driver has no git tree then you can use the tree from the top level entry: NETWORKING DRIVERS (WIRELESS) M: Kalle Valo <kvalo@kernel.org> L: linux-wireless@vger.kernel.org S: Maintained W: https://wireless.wiki.kernel.org/ Q: https://patchwork.kernel.org/project/linux-wireless/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git F: Documentation/devicetree/bindings/net/wireless/ F: drivers/net/wireless/ But of course some of the entries could be out-of-date. Patches welcome if you see those :) > I DO understand that the easiest it is for maintainers, the better for > them, but please stop asking for casual contributors to know that and > follow your, not that easy to find or remember, rules. > > I'm tempt not to TRY to put the right branch in the subject of my > commits anymore, because even when I try to do it right and follow > simple rules for that, it is not enough and I'm WRONG. > > Most of my contributions are related to error handling paths. > The remaining ones are mostly related to number of LoC reduction. > > Should my contributions be ignored because of the lack of tools to > help me target the correct branch, then keep the bugs and keep the > LoC. I don't see anyone saying anything about ignoring your fixes, at least I have always valued your fixes and I hope you can continue submitting them. > git log --oneline --author=jaillet --grep Fixes: drivers/net | wc -l > 97 > git log --oneline --author=jaillet drivers/net | wc -l > 341 > > git log --oneline --author=jaillet --grep Fixes: net | wc -l > 7 > git log --oneline --author=jaillet net | wc -l > 327 > > No hard feelings, but slightly upset. No need to be upset really, this is just coordination between maintainers so that we don't accidentally take wrong patches. Please don't take it personally. If you are not familiar with network trees, I have seen some contributors just using '-next' without specifying the actual tree and letting the maintainers deal with what tree to take it. I consider that as a safe option.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 7317e4a5d1ff..c5e5f783f137 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -3589,7 +3589,7 @@ void ieee80211_channel_switch_disconnect(struct ieee80211_vif *vif, bool block_t EXPORT_SYMBOL(ieee80211_channel_switch_disconnect); static int ieee80211_set_after_csa_beacon(struct ieee80211_sub_if_data *sdata, - u32 *changed) + u64 *changed) { int err; @@ -3632,7 +3632,7 @@ static int ieee80211_set_after_csa_beacon(struct ieee80211_sub_if_data *sdata, static int __ieee80211_csa_finalize(struct ieee80211_sub_if_data *sdata) { struct ieee80211_local *local = sdata->local; - u32 changed = 0; + u64 changed = 0; int err; sdata_assert_lock(sdata);