> Hi, > > [I'll also fold in your other email] > > > Not calling hw_config could affect drivers like ath9k_htc where the rate control runs in the firmware. > > Those drivers will update the rate control based on CHANGED_HT flag. > > Yeah that's actually an interesting point -- but we have it wrong right > now I think. Did you see Paul's recent patch? We really shouldn't be > reconfiguring the channel if all we want is to stop transmitting 40 MHz, > we should just update rate control only. Now for in-device rate control > that isn't really possible today since they can't get rate_update(), but > that means we should add a separate callback, I think? Yes. I missed that. I am not sure about the new callback alone is sufficient. We have to issue a WMI command to reconfigure the rc in firmware. If so, it needs firmware changes also. May be Sujith is the right person to answer about ath9k_htc. > > > If we do that, is it still necessary to stop the queues for it? It seems > > > like it shouldn't. > > > > Actually the queue stop was added to avoid mismatches b/w hw and rate control. But If you dont stop the queues > > before the rate control change, the station might send the frames in different ht mode (for example ht40) wrt AP's ht mode (ht20). > > Yes, but that's probably OK. It's going to do that anyway since there > are still frames in the hardware queues, and those will go out without > updated rate information. There can be no guarantee (without having some > form of hardware assist) that from the point we receive a 20/40 > notification we'll send the right bandwidth. Yes. Sounds fine. -Rajkumar-- 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
