On 19 July 2011 16:34, Dan Williams <dcbw@xxxxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
