On Fri, 2016-04-22 at 14:52 +0000, Kanchanapally, Vidyullatha wrote: > > > So I'm thinking something like > > > > supported_on_all = iftype_ext_capab[0] > > for i in 1..num_iftype_ext_capab-1: > > supported_on_all &= iftype_ext_capab[i] > > WARN_ON(wiphy->ext_capa_mask & ~supported_on_all) > We were thinking whether this is an appropriate validation or not > since we cannot be sure how the Extended Capabilities are defined. > They need not necessarily be all positive capabilities, they could > couple both the positive and negative capabilities as well. > Please let us know if this change is really needed. I'm ambivalent about this. I don't think it makes sense to see drivers that register both, i.e. would result in the warning I suggested. I don't think *negative* capabilities can really be added, since the spec always assumes that capabilities that you don't list are zero. In considering multi-bit values, you might have a point, if - for example - you had a MAX-MSDU-IN-AMSDU value of 0b11 for some interfaces, and 0b01 for all the others. Realistically though, does that make sense? I would expect this to be the only multi-bit field that might ever be supported this way, since in the future drivers would likely only specify the current subset of capabilities in the wiphy ext_capab, and put all newer extensions into the per-iftype ext_capa, assuming that they're running on a newer supplicant. So on the whole, I don't really see a good reason to not do pretty much exactly the (pseudo)code I wrote above; perhaps you can come up with a better example than I tried? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
