Hi, So ... I don't think this is correct, for multiple reasons. One, you're completely removing *any* validation of the (global) interface combinations in case per-radio interface combinations are present. This is clearly not desirable. You're arguing the DFS vs. multi-channel check shouldn't be done, but that doesn't imply removing all checks entirely. Secondly, I'm not convinced that the DFS vs. multi-channel check should actually be removed, though I'll admit that this may be a bit questionable. My argument would be something like this: The global interface combinations exist to let existing software (that isn't aware of multi-radio yet) continue functioning as-is. Since it is not radio- aware, multi-channel can mean many different things to it, including the ability to use say two 2.4 GHz channels at the same time, by time- sharing. This is e.g. used to support concurrent P2P-GO and (BSS) client today. But DFS capability on this is broken, since you're not on the correct channel all the time, hence the check. Therefore, I think this patch is entirely wrong, and you need to advertise only a lowest common denominator on the global interface combinations (where the num_different_channels is actually possible to support on each individual radio, since no band separating is implied by it). johannes
