On Thu, May 10, 2012 at 11:12 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > Hi Thomas, > > >> > I don't think this patch is correct -- mac80211 will get updated even if >> > the device isn't even started which will likely cause trouble. Even if >> > not though, this all doesn't match any kind of multi-channel concept. We >> > treat the channel as part of the temporary setup, e.g. part of the >> > association. AP and mesh are the only ones that are different today I >> > think. >> > >> > Overall, I don't think setting the channel & doing mesh setup separately >> > is really a good API. >> > >> > From mac80211's (and other drivers if they existed) POV the channel >> > should be given with the mesh_join command, like for IBSS. >> > >> > Now, obviously, requiring userspace to do that would be an API change. >> > We probably don't want that, so I would suggest to change cfg80211 to >> > track the channel and then pass it to join_mesh as one of the mesh >> > parameters. This could be made work even when somebody attempts to set >> > the channel before the interface is up, but we'd have to be careful >> > about interface type changes. >> >> Unfortunately, when __nl80211_set_channel() is called we may or may >> not have a wdev, so there is nowhere to store the interface-specific >> channel and type. > > Well, but if you don't have a wdev, is the setting relevant at all? Or > does it take effect later? This all isn't very well-defined I guess. > >> We could shove these into a cfg80211_registered_device, but now just >> "last channel for this wiphy" is tracked, and that doesn't seem to >> help your multi-channel operation. > > So you'd want to allow setting the channel on the phy, and have it take > effect for mesh? Is that really something we need to support? I'd think > almost everyone would set the channel on the netdev? No :) Thanks for clearing that up. >> If the above is correct, how about we leave the existing API as-is and >> simply extend join_mesh to take a channel attribute? > > We could, but that'd mean that it can be NULL if the user doesn't set > it, which seems a bit odd to me too and then the driver again would have > to sort it out. I'd prefer if we could sort it out in cfg80211 so the > driver (mac80211) is simpler. For this, we can store a default channel and type in the default mesh config. >> Also, with IBSS the desired channel is pushed to the driver along with >> the setup parameters. What do you think about calling >> __nl80211_set_channel() directly instead of relying on the cfg80211 >> driver to handle this? > > No, that's certainly not possible. In IBSS the channel is just the > default channel if we don't find an IBSS. And in any case I'd rather > call set_channel less than more. So cfg80211_set_freq() from cfg80211_join_mesh() is out, too? -- 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
