Hi, > The rebase seems good. We will conduct a full channel-switch test, > including hwsim tests in hostap. If there are any problems, we will > send another patch to fix them. OK, thanks for checking. The tests from hostap are passing, I make sure of that anyway, but ... who knows what they miss :) > > Shouldn't that have (had!) an 80 MHz handling case? Or maybe a loop a > > la > > the one in ieee80211_config_bw(): > > > > /* > > * Downgrade the new channel if we associated with restricted > > * bandwidth capabilities. For example, if we associated as a > > * 20 MHz STA to a 40 MHz AP (due to regulatory, capabilities > > * or config reasons) then switching to a 40 MHz channel now > > * won't do us any good -- we couldn't use it with the AP. > > */ > > while (link->u.mgd.conn.bw_limit < > > ieee80211_min_bw_limit_from_chandef(&chanreq. > > oper)) > > ieee80211_chandef_downgrade(&chanreq.oper, NULL); > > > > > > Feels like this should be the same here. > > Yes, a loop to validate the operating bandwidth is necessary. We'll > send another patch that makes this change. Sounds good, thanks! > > Also note how this uses ieee80211_chandef_downgrade() - we really > > need > > to track the "chanreq.oper" vs. "chanreq.ap" in this code as well for > > puncturing - can I ask you to take a brief look at that? I'll anyway > > probably have to look at that soon though. > > Of course. > In fact, we have plans to study and implement puncturing on our MT76 > driver. We're currently working on the AP side, and we expect to start > the STA side maybe three months later. OK, let's see. I probably have plans earlier than 3 months from now for this, but not sure yet. Let me know when/if you start working on it so we can sync up again then? johannes
