On 3/28/2024 8:11 PM, Johannes Berg wrote:
On Thu, 2024-03-28 at 12:59 +0530, Karthikeyan Periyasamy wrote:
From: Vasanthakumar Thiagarajan <quic_vthiagar@xxxxxxxxxxx>
Currently, iface combination param supports single physical hardware.
To support multi physical hardware, add hardware specific checks on the
channel context creation and populate hardware specific parameters from
the channel definition for which the interface combination need to check.
I haven't gone through this patch in detail, but again like on patch 9,
I'm not so sure about the implementation of the XOR behaviour of
checking global and per-HW limitations.
I probably wrote on the other patch that it seems it should check both,
but I realize now that doesn't make sense: After all, the top-level
combinations data must encode something that's supported _regardless_ of
channels, so likely only a subset of the combinations supported across
the different HW.
But that doesn't mean that I'm yet convinced that the design in patch 9
is actually good, with how it checks that depending on the 'chandef'
parameter. I'd like to explore other possibilities such as a different
function for that, for example. It could use the same underlying helpers
and mechanics, but it seems that might be better overall.
Or probably better yet: explore an approach where mac80211 doesn't even
have to _know_ about the cfg80211_get_hw_idx_by_chan() and all that, but
just prepares the information in a way that encodes enough data to
handle that, which really means going from
int num_different_channels;
int iftype_num[...];
to
struct {
enum nl80211_iftype iftype;
u32 freq;
} interfaces[];
or something like that.
I was almost going to write "links" instead of "interfaces" there, which
reminds me that none of this really even works well for MLO yet. Not
sure if that's better addressed as a separate first step?
Sure, will post this change as a separate RFC patch.
--
Karthikeyan Periyasamy
--
கார்த்திகேயன் பெரியசாமி
