On Thursday 17 April 2008, Johannes Berg wrote: > On Tue, 2008-04-15 at 17:17 +0200, Ivo van Doorn wrote: > > > > In any case, for the problem at hand, I wouldn't mind increasing > > > hw_key_idx to a u16 all the way through, or pass the key_conf pointer > > > instead. > > > > I'll create a patch that changes it to the key_conf pointer then, > > that sounds like the safest option to allow changes to key_conf later. > > That'll also solve your problem of having to know the algorithm, and b43 > might benefit of that too, I think it currently keeps a table for the > algorithms. Exactly :) A follow up patch that I will create later will add a flag to the key_conf structure that marks the key as shared or pairwise. After that adding the final bits for HW encryption to rt61pci and rt73usb should be very easy. :) > One thing to keep in mind that you'll want to document clearly: the > key_conf pointer there will only be valid until ops->tx() returns, so > you must not access it (e.g. via the tx control copy you need to make > for tx status) outside of the tx() routine unless you want to somehow > make sure it isn't removed while in use (which is possible [1] since > set_key() may sleep.) > > Hence, if you defer ops->tx() to some workqueue or something, you need > to copy out all the data you need from the key_conf beforehand. Ok, I'll update my patch with the above warning. > Tomas: was it you who mentioned we should remove tx_control from > tx_status and just require copying the fields we need? If so, did you > ever look into that? > > > Note that this change (either adding the key_conf pointer or the hw_key_idx to u16) > > will cause ieee80211_tx_control to exceed the 48 bytes. So that will make it > > harder to move it into the skb->cb array later. > > I just had a look, we could make the rate pointers index into the rate > array instead which would make them go from 24 bytes (12 on 32-bit) to > 3 bytes (we only need a u8 index.) > > johannes > > [1] using creative bit-locking in hw_key_idx. Ivo -- 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
