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. 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. 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
