On Fri, 2016-04-22 at 14:52 +0000, Kanchanapally, Vidyullatha wrote:

quoted

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]

quoted

 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