> > > > * could other drivers (next to ath9k) work with this API? > > > > > > Probably not easily. Any TI folks reading this? > > > > I was thinking about adding another callback function or option for that for drivers > > who do the channel switch internally. Then we would only need mac80211 to adapt. > > > > Would that help, or what would be problematic? > > I don't really know. If you look at what we do in managed mode now, some > drivers will do the switching and report back when done. > OK, maybe we should leave that open to people who implement that feature for their respective drivers. > > Yeah, that would be an alternative. I've been inspired by IEEE 802.11-2012/6.3.17 > > (MLME-CHANNELSWITCH) originally. :) > > I think your suggestion is good for AP where we control the beacon. For IBSS it > > would be a little different: when a channel switch is triggered, userspace does > > not know the beacon (and will not set it). Therefore, we could only accept the > > change IEs and skip the "after-switch-beacon" IEs (these would be re-generated > > internally) in IBSS mode. I guess it would be similar for mesh. > > Yeah, agree, IBSS/mesh modes are somewhat different here, userspace > doesn't really know the channel is switching at all, does it? IBSS/Mesh does not process CSA so far. When we do, we should switch the channel and inform userspace by using an event (the same way it is done for station, I think). What I'm concered about is to initiate a channel switch from userspace. This will be required for IBSS-DFS: when a radar is detected and this event is sent to userspace, it must react by initiating a channel switch. My plan was to use the same "channel switch" command, just without the CSA-IE and after-change IEs (see the new PATCH series). The rest would be pretty similar to the AP-operation: add CSA IEs, switch channel, create a new beacon for the new channel and set it. Only that this would be done in kernel space instead of userspace. Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
