On 28.03.24 08:29, Karthikeyan Periyasamy wrote:
The prerequisite for MLO support in cfg80211/mac80211 is that all the links
participating in MLO must be from the same wiphy/ieee80211_hw. To meet this
expectation, some drivers may need to group multiple discrete hardware each
acting as a link in MLO under single wiphy. So it required to have some
sort of mapping while describing interface combination capabilities for
each of the underlying physical hardware. This patch set tries to add an
infrastructure to advertise underlying hw specific capabilities like
channel and interface combinations.
Some of the todos
- More than one concurrent monitor mode support each operating on
different channels under one ieee80211_hw
- Mechanism for each underlying radio specific configurations like
txpower, channel, etc.
RFC series Link: https://lore.kernel.org/linux-wireless/20220920100518.19705-1-quic_vthiagar@xxxxxxxxxxx/
FYI, I made a replacement for the wiphy radio hardware reporting parts
of this series with a different design:
https://patchwork.kernel.org/project/linux-wireless/list/?series=855042
The key differences are:
- Only band bitmask and optionally frequency ranges are provided, so no
per-radio channel list
This is easier to track and vastly reduces the amount of data sent to
user space in the wiphy dump
- No integration with ifcomb. I don't really see the need for that one
at this point. It can easily be added later if it's actually needed.
- Validation happens in mac80211 instead of cfg80211, because that
removes a lot of complexity
The radio id is tracked per chanctx and only one chanctx per radio is
allowed.
I think if we ever get a non-mac80211 driver that needs multi-radio
support, it should just do its own validation, since that's likely going
to be less complex than having cfg80211 do it in the first place.
- Felix
