From: Dan Williams <dcbw@redhat.com>
To: Daniel Drake <dsd@laptop.org>
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
libertas-dev@lists.infradead.org
Subject: Re: [PATCH 4/4] libertas: reimplement mesh channel selection
Date: Wed, 20 Jul 2011 11:07:50 -0500 [thread overview]
Message-ID: <1311178071.21004.4.camel@dcbw.foobar.com> (raw)
In-Reply-To: <CAGq3pz6OP5CNHMvCtxkRKhU-dx097k66d1h0eGJT0Lhs9oM+Cw@mail.gmail.com>
On Tue, 2011-07-19 at 16:40 +0100, Daniel Drake wrote:
> On 19 July 2011 16:34, Dan Williams <dcbw@redhat.com> wrote:
> > On Sun, 2011-07-17 at 18:03 +0100, Daniel Drake wrote:
> >> This reimplements code allowing for mesh channel selection according
> >> to how NetworkManager expects.
> >
> > Originally I was trying to get away from magical functions that used
> > variables of the internal private structure to change state, ie moving
> > most of the actual data for the firmware commands to the function
> > argument list instead of accessing priv->xxxx internally. The idea
> > there was that it would be easier to follow the code flow through the
> > driver if you knew that these functions weren't touching all sorts of
> > internal variables. Any chance we can preserve that? Thoughts? That
> > was my intent at least but it's not set in stone.
>
> I assume you are referring to priv->mesh_channel;
>
> We need to store the selected channel somewhere for 2 reasons.
> 1. For the SIOCGIWFREQ implementation
> 2. for knowing which channel to start the mesh on when the device is brought up.
Storing it is fine; I was just trying to keep the functions that built
firmware commands from poking priv->xxx stuff. Hence why there was a
'chan' parameter to the function, to push the actual decision about what
channel to change to up to the thing that actually decided it was
necessary to change the channel at all. In this case it's not as
relevant as other cases, so in the end I don't really care as much.
Dan
> I'm open to other suggestions for where such information can be kept,
> but I don't see a way to not store it.
>
> Note that this was already done before as priv->channel. I have
> separated that into channel and mesh_channel based on the observation
> that at the hardware/firmware level, the mesh channel is programmed
> and stored separately. You can connect to one channel "normally" and
> program the mesh to run on another channel. Once your "normal"
> connection is brought down, it automatically starts meshing on the
> other channel. etc.
>
> Thanks,
> Daniel
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
next prev parent reply other threads:[~2011-07-20 16:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-17 17:03 [PATCH 4/4] libertas: reimplement mesh channel selection Daniel Drake
2011-07-19 15:34 ` Dan Williams
2011-07-19 15:40 ` Daniel Drake
2011-07-20 16:07 ` Dan Williams [this message]
2011-07-20 16:16 ` Daniel Drake
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=1311178071.21004.4.camel@dcbw.foobar.com \
--to=dcbw@redhat.com \
--cc=dsd@laptop.org \
--cc=libertas-dev@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox