From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: ath10k <ath10k@lists.infradead.org>
Subject: Re: Why is peer->peer_ids a bitmap?
Date: Wed, 30 Mar 2016 08:42:07 -0700 [thread overview]
Message-ID: <56FBF3CF.5090009@candelatech.com> (raw)
In-Reply-To: <CA+BoTQkfYwCfH2iWyzWbugCK50whafctRtfy928tzHpo7oq7ZQ@mail.gmail.com>
On 03/30/2016 03:07 AM, Michal Kazior wrote:
> On 29 March 2016 at 23:30, Ben Greear <greearb@candelatech.com> wrote:
>> Can a single peer object really have more than one ID?
>
> When you install keys you typically get more ids via htt-peer-map
> event. I think there were some other cases as well..
>
>
>> Is this trying to deal with shared peer objects, perhaps?
>
> This was developed very long ago when peer-id mapping wasn't really
> well understood. Perhaps we could make do without peer id map now?
> i.e. only care about the first htt-peer-map per peer address?
The 10.4.3 firmware can probably still do shared peers, though not sure if it actually
happens in practice, and I'm not sure it that would cause this bitmap to
ever have more than one bit set anyway.
It just struck me as strange, mainly, and since the radio struct has
a peer array indexed by the peer-id, then it would seem that we should never
have duplicate bits set in any of the peer objects. And, if that is correct,
then the bitmap or similar should probably be in the radio struct instead of
in peer objects.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2016-03-30 15:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 21:30 Why is peer->peer_ids a bitmap? Ben Greear
2016-03-30 10:07 ` Michal Kazior
2016-03-30 15:42 ` Ben Greear [this message]
2016-03-31 6:37 ` Michal Kazior
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=56FBF3CF.5090009@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=michal.kazior@tieto.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.