Received-SPF: softfail (google.com: domain of transitioning linux-wireless-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <6cf56be5-16d6-2bcd-150f-bf29f98b7f1b@quicinc.com>
Date:   Tue, 15 Feb 2022 16:37:58 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.0
Subject: Re: [PATCH 2/3] cfg80211: validate RU puncturing bitmap
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        <linux-wireless@vger.kernel.org>
References: <20220214223051.3610-1-quic_alokad@quicinc.com>
 <20220214223051.3610-3-quic_alokad@quicinc.com>
 <a9813545a25cd63f71cc31476230514a80350802.camel@sipsolutions.net>
From:   Aloka Dixit <quic_alokad@quicinc.com>
In-Reply-To: <a9813545a25cd63f71cc31476230514a80350802.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/15/2022 12:19 AM, Johannes Berg wrote:
> On Mon, 2022-02-14 at 14:30 -0800, Aloka Dixit wrote:
>>
>> +
>> +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 ...
>

I instead reverted the passed bitmap inside the function because that 
way if the map is not provided at all, it will be all 0's by default and 
will be considered as all channels active.

> Can we export this function maybe so mac80211 can use it?
> 
Sure, will add in the next version.

> 
> 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

Added it here so that any command working with chandef will be updated 
without any other change.
Example: During channel switch, user can provide a puncturing bitmap 
with a new option I added in userspace, and because it is part of 
chandef, the same code path validates it for that command automatically.

Regarding if different puncturing pattern should be considered as a new 
context - yes, depending on if it is HE or non-HE mode, the new bitmap 
may be invalid and the operation should fail.

Thanks,
Aloka