> > Good point. But let's not overload set_key() for it this way. This way,
> > the driver needs to look up the key etc. and the semantics get quite
> > mangled up. Also, your approach doesn't work for Broadcom hardware that
> > only needs phase 1 keys for both RX and TX.
>
> Can you elaborate why it doesn't cover bcom case?
I don't quite understand the phase 1 key derivation and why it is done
for each DMA queue, but I think this is not too important as
non-matching will just be done in software. However, bcom firmware wants
to have just the phase 1 key, and as far as I can tell the driver can't,
even with your patches, obtain a phase 1 key for TX.
> > How about instead we add a new "update_tkip_key()" callback that takes
> > exactly the required parameters? It should also give the
> > hardware-key-index so that the driver has less work to do.
>
> It's viable but I actually prefer not opening too many interfaces.
> Please give me some more detailed sketch how do you see that and we
> sure get to some acceptable solution.
Yes, I would prefer not having that many interfaces as well, but I don't
think shoehorning it into the set_key() callback is a good idea because
(a) you add fields to the key conf structure that are only used for
the tkip stuff and only valid in some calls
(b) the patch breaks the set_key() interface's symmetry
A new callback update_tkip_key could look like this:
void update_tkip_phase1key(hw, keyconf, iv32, p1key)
The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the
new callback would be invoked right from where the phase1 key is
calculated.
I'm not exactly sure whether one needs a phase1 key for RX and one for
TX right now, but if so a direction flag should be added?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
