Upstreaming mac80211 patches?

[Daniel Golle]

On Wed, Dec 14, 2022 at 06:04:40PM +0100, Nick wrote:
> Lately, I had to look at some mac80211 patches and I did not understand why
> some patches are still present or not upstreamed. What about upstreaming
> some of the mac80211 patches or removing some?
> For example "120-cfg80211_allow_perm_addr_change.patch" from 2014 I did not
> find it on typical mailinglist (https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/subsys/120-cfg80211_allow_perm_addr_change.patch)?
> For ath9k we have 28 patches. Some of them are only for changing "channel
> bandwidth to 5/10" (so not 20 or 40 bw included). I guess that is legacy? https://github.com/openwrt/openwrt/commit/9f38d4402bede0c35bb8f4814e577dc0b0a2f184

IEEE 802.11 standard originally intended also operating on 5 MHz and
10 MHz wide channels. However, in Linux mac80211 doesn't handle those
more narrow channels. As ath5k and ath9k hardware does support this, we
have patches to allow using 5 MHz and 10 MHz channels in a non-standard
way. While this is most likely not acceptable for upstream, it is still
very useful as the possible link distance is (naturally) improved quite
a lot when using 10 MHz or even 5 MHz channel bandwidth. Hence this is
popular among amateur radio hams, for example.

> And some were rejected upstream (https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath9k/354-ath9k-force-rx_clear-when-disabling-rx.patch):
> https://patchwork.kernel.org/project/linux-wireless/patch/20180723160300.58024-3-nbd@nbd.name/
> 
> These are just some examples. However, I think it would be beneficial to get
> closer to upstream mac80211 again?

Help with cleaning and (re-)submitting patches upstream is for sure
always welcome ;)
Now that nvmem framework is ready and afaik we got rid of all pre-DTS
platform_data users, many of the MTD EEPROM and MAC address hacks could
be re-implemented using nvmem cells (and then get closer to being
acceptable upstream).