On Thu, 2024-06-06 at 20:07 +0200, Felix Fietkau 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.
This is of course the motivation now, but I do wonder if this wouldn't
potentially also apply to a single device that's full dual-band capable
in some way? But doesn't really matter now.
But the thing is that it would let userspace differentiate between what
we mostly have today in a single device (multiple channels can be used,
but you have to go to powersave etc.), vs. a fully concurrent device.
IOW, it feels like this could be used to advertise fully concurrent
capabilities?
> + * struct wiphy_radio - This structure describes a physical radio belonging
> + * to a wiphy. It is used to describe concurrent-channel capabilities of the
> + * phy. Only one channel can be active on the radio described by struct
> + * wiphy_radio.
that's a bit long for the 'short description' :P
maybe just say "struct wiphy_radio - physical radio of a wiphy" and move
the full description down.
> + *
> + * @radio: radios belonging to this wiphy
> + * @n_radio: number of radios
Somewhere - either here or above - we should probably say that it's
assumed you only have a single radio (with the properties covered by the
interface combinations in the wiphy itself) if this isn't given at all.
(Which is what we assume today, more or less.)
> +++ b/include/uapi/linux/nl80211.h
> @@ -3401,6 +3401,8 @@ enum nl80211_attrs {
>
> NL80211_ATTR_ASSOC_SPP_AMSDU,
>
> + NL80211_ATTR_RADIOS,
missing docs
> +/**
> + * enum nl80211_wiphy_radio_attrs - wiphy radio attributes
> + *
> + * @__NL80211_WIPHY_RADIO_ATTR_INVALID: Invalid
maybe if this is WIPHY_RADIO also call it NL80211_ATTR_WIPHY_RADIOS
above?
> + * @NL80211_WIPHY_RADIO_ATTR_FREQ_RANGES: Nested array of frequency ranges
> + * supported by this radio.
Do we really want this complexity? We only have a single range now, do
we expect that to change? Non-contiguous ranges, where a hole in the
middle is supported by another radio?
Not sure I see the value vs. just having min/max freq directly here?
> + freqs = nla_nest_start_noflag(msg, NL80211_WIPHY_RADIO_ATTR_FREQ_RANGES);
Please don't add new _noflag code.
> + nl_combis = nla_nest_start_noflag(msg,
> + NL80211_WIPHY_RADIO_ATTR_INTERFACE_COMBINATIONS);
same here
(and yes maybe userspace wants to unify the parsing of this with the
existing interface combinations attribute and pass the attribute ID or
something, but then it can fix the nested flag too.)
johannes
