From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Thu, 12 Jan 2012 15:59:15 -0800 Subject: [ath9k-devel] Question on keycache size. In-Reply-To: References: <4F0E0537.2000509@candelatech.com> <4F0F041F.4020300@candelatech.com> <4F0F3F0B.1010101@candelatech.com> <4F0F43BE.3080108@candelatech.com> <4F0F6885.7010506@candelatech.com> Message-ID: <4F0F73D3.9010805@candelatech.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 01/12/2012 03:53 PM, Adrian Chadd wrote: > Let me go and hit up the MAC guys and find exactly what the heck is > being kept in the keycache. There may be some good reasons it's being > done that I'm not yet aware of. > > At least the (legacy, but not sure for Kite/similar) fast diversity > stuff is kept in the keycache? As well as the filtered frame bits. There is lots being kept there, but the code appears to deal with invalid key caches just fine (and this appears to be the expected code path when nohwcrypt is enabled.) You can see what it pokes into the chip in the ath/key.c file. Grepping for ath_key in the ath/ath9k/ dir shows the calling code..and so forth. Eventually the rx and tx logic has checks for keyix == ATH9K_RXKEYIX_INVALID, and appears to deal with things OK if that is the case. I still look forward to hearing about anything you learn on this topic, however! Thanks, Ben > > > Adrian -- Ben Greear Candela Technologies Inc http://www.candelatech.com