On Mon, 2011-03-21 at 09:59 +0200, ext Juuso Oikarinen wrote: > On Mon, 2011-03-21 at 09:54 +0200, ext Eliad Peller wrote: > > On Thu, Mar 17, 2011 at 7:38 AM, Juuso Oikarinen > > <juuso.oikarinen@xxxxxxxxx> wrote: > > > On Wed, 2011-03-16 at 23:03 +0200, ext Eliad Peller wrote: > > >> When passing a tx frame, the driver incorrectly set desc->tid > > >> with the ac instead of the actual tid. > > >> > > >> It has some serious implications when using 802.11n + QoS, > > >> as the fw starts a BlockAck with the wrong tid (which finally > > >> cause beacon loss and disconnection / some fw crash) > > >> > > >> Fix it by using the actual tid stored in skb->priority. > > > > > > How will the firmware handle the TIDs larger than 3, as currently to the > > > firmware it appears only TID's 0-3 are configured, and the rest are > > > whatever values happen to be there default? > > > > > that's a good question. > > according to the fw guys, the fw auto-maps the tid to the correct ac. > > the confusing thing is that ACX_TID_CFG actually gets AC as its input > > (in the queue_id param) rather than TID. > > thus, only 0-3 (ACs, not TIDs) are configured. > > > > Yes, so the TID's are most likely not configured in a way that the > firmware will be able to "auto-map". I think the at minimum the > ACX_TID_CFG must be revisited before this change can work. > As discussed on IRC. So there is no dependency between the index of the ACX_TID_CFG configurations and the tid passed to the TX descriptor. Instead the FW independently maps the tids to corresponding AC's, regardless of the tsid's configured in ACX_TID_CFG. My confusion here was that I assumed the indexes given to ACX_TID_CFG must match the actual priority values. Based on this and the IRC chat (which was enlightening): Reviewed-by: Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx> -Juuso -- 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
