On 7/31/09, Michael Buesch <mb@xxxxxxxxx> wrote: > On Friday 31 July 2009 23:04:17 gregor kowski wrote: >> Hi Michael, >> >> > It's mapped to 4, because you removed the old API support. >> > (I'm not sure whether we want to remove that support, yet. Gimme some >> > time >> > on it...) >> > >> Does the old API still useful ? > > Well, I'm not sure. Why do we remove it at all? It just avoids one single > if condition in your tkip patch, doesn't it? > because you ask it : "We should probably remove that new_kidx_api crap alltogether." [1] :) There is really bugs in the current code. You could see it by enabling B43_DBG_KEYS. With the current code and new API, you will see that 54 pairwise keys are dumped, not only 50. [1] > >> + /* FIXME : for b43_new_kidx_api, there can be 54 key > >> + * instead of 50 in RCMTA and TKIPTSCTTAK. > >> + */ > > > > I don't understand this comment. > if b43_new_kidx_api is true : > - we set max_nr_keys to 58 > - we program B43_MMIO_RCMTA_COUNT to 50 > - in b43_key_write we can allocate key up to index 58 (4 for default, > 54 for sta) > > But there is only 50 entries for TKIPTSCTTAK, and a comment on bcm-v4 > suggest there is 50 entries for RCMTA. So if there more than 50 > station we will overflow RCMTA and TKIPTSCTTAK. Yeah well. The key handling is pretty weird. There are 50 pairwise keys available. max_nr_keys includes pairwise keys, group keys (4) and another copy of the group keys (4) used with older firmware. So we end up at 58. To summarize it, in practice we have 50 pairwise keys and 4 group keys. You can ignore the additional 4 "rx keys" as they are not used in recent fw and are just a copy of the group keys. > So the fix will be do to something like > dev->max_nr_keys = (dev->dev->id.revision >= 5) ? 58 : 20; > if (b43_new_kidx_api()) > dev->max_nr_keys -= 4; Hm, I don't think this is correct. There are lots of weird assumptions all over the code. We should probably remove that new_kidx_api crap alltogether. -- 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