linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: gregor kowski <gregor.kowski@gmail.com>
Cc: bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org
Subject: Re: [RESEND] [PATCHv2] b43 add harware tkip
Date: Wed, 5 Aug 2009 00:27:29 +0200	[thread overview]
Message-ID: <200908050027.29829.mb@bu3sch.de> (raw)
In-Reply-To: <83a869cd0908041523m7b2be0c9t4ae21dc2e22c537@mail.gmail.com>

On Wednesday 05 August 2009 00:23:23 gregor kowski wrote:
> On 8/5/09, Michael Buesch <mb@bu3sch.de> wrote:
> > On Wednesday 05 August 2009 00:03:11 gregor kowski wrote:
> >> On 8/4/09, Michael Buesch <mb@bu3sch.de> wrote:
> >> > On Tuesday 04 August 2009 23:54:42 gregor kowski wrote:
> >> >
> >> > You always talk about "bugs". What are these "bugs"? Is it just the
> >> > wrong
> >> > max_nr_keys assignment? That's trivial to fix.
> >> >
> >> So [1] is ok ?
> >
> > Could you answer my question?
> That's [1]. But may be my description wasn't good.
> I will try a new one.
> we can have up to 50 pairwise keys (due to RCMTA and tkip stuff).
> 
> In the case of new API :
> - max_nr_keys is set to 58
> - in b43_key_clear we call do_key_write for index in [0 ... 58]
> - in do_key_write we call keymac_write for index in [4 ... 58]
> - in keymac_write write to RCMTA index [0 ... 54]
> We write too much pairwise keys.
> 
> - max_nr_keys is set to 58
> - b43_key_write generate pairwise keys in [sta_keys_start ...
> max_nr_keys] = [0 ... 58] and call do_key_write
> - in do_key_write we call keymac_write for index in [4 ... 58]
> - in keymac_write write to RCMTA index [0 ... 54]
> We write too much pairwise keys.

Yeah, I do understand this bug. My question was if that is the only bug.

> So max_nr_keys seems wrong in case of new API.

It's not that simple, actually.
The max_nr_keys thing was never meant to specify which API we're on.
It was invented to do the RCMTA vs *oldcrappymechanismiforgotthenameof*.
max_nr_keys essentially became obsolete and dead code when b43 did not
support <rev5 anymore. I will submit a patch which removes it and cleans up
the code alltogether.

-- 
Greetings, Michael.

  reply	other threads:[~2009-08-04 22:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-27 20:49 [RESEND] [PATCHv2] b43 add harware tkip gregor kowski
2009-07-28 16:08 ` Michael Buesch
2009-07-31 21:04   ` gregor kowski
2009-07-31 21:08     ` Michael Buesch
2009-08-04 21:54       ` gregor kowski
2009-08-04 21:58         ` Michael Buesch
2009-08-04 22:03           ` gregor kowski
2009-08-04 22:06             ` Michael Buesch
2009-08-04 22:23               ` gregor kowski
2009-08-04 22:27                 ` Michael Buesch [this message]
2009-08-04 22:32                   ` gregor kowski
2009-07-31 21:00 ` [RESEND] [PATCHv3] " gregor kowski
2009-07-31 21:20   ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200908050027.29829.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=gregor.kowski@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).