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
