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;
Message-ID: <a9813545a25cd63f71cc31476230514a80350802.camel@sipsolutions.net>
Subject: Re: [PATCH 2/3] cfg80211: validate RU puncturing bitmap
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Aloka Dixit <quic_alokad@quicinc.com>,
        linux-wireless@vger.kernel.org
Date:   Tue, 15 Feb 2022 09:19:39 +0100
In-Reply-To: <20220214223051.3610-3-quic_alokad@quicinc.com>
References: <20220214223051.3610-1-quic_alokad@quicinc.com>
         <20220214223051.3610-3-quic_alokad@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.3 (3.42.3-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 2022-02-14 at 14:30 -0800, Aloka Dixit wrote:
> 
> +/* IEEE P802.11be/D1.31, December 2021, Table 36-30 5-bit punctured channel
> + * indication for the non-OFDMA case in an EHT MU PPDU
> + */
> +static const u16 ru_punct_bitmap_80[] = {0xF, 0xE, 0xD, 0xB, 0x7};
> +static const u16 ru_punct_bitmap_160[] = {0xFF, 0xFE, 0xFD, 0xFB, 0xF7, 0xEF,
> +					  0xDF, 0xBF, 0x7F, 0xFC, 0xF3, 0xCF,
> +					  0x3F};
> +static const u16 ru_punct_bitmap_320[] = {0xFFFF, 0xFFFC, 0xFFF3, 0xFFCF,
> +					  0xFF3F, 0xFCFF, 0xF3FF, 0xCFFF,
> +					  0x3FFF, 0xFFF0, 0xFF0F, 0xF0FF,
> +					  0x0FFF, 0xFFC0, 0xFF30, 0xFCF0,
> +					  0xF3F0, 0xCFF0, 0x3FF0, 0x0FFC,
> +					  0x0FF3, 0x0FCF, 0x0F3F, 0x0CFF,
> +					  0x03FF};
> +
> +bool cfg80211_ru_punct_bitmap_valid(const struct cfg80211_chan_def *chandef)
> 

Heh. We wrote basically the same code just the other day (except I think
inverting the bitmasks or something?) in mac80211 for the client side,
i.e. when receiving puncturing from the AP ...

Can we export this function maybe so mac80211 can use it?


Conceptually, I'm wondering if it really belongs into the chandef? Can
you explain why it's part of the channel configuration? If you've got
two chandefs with the same control channel, CCFS and bandwidth, but
different puncturing, does it really make sense to treat them as two
separate channel contexts, e.g. in mac80211? It seems strange to do
that.

johannes