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? > > 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. In the other mail you said almost the same thing: > The queue stop was added to avoid sending frames while the hw > reconfigure is in progress. > So that we can prevent differences b/w hw and rate control ht mode. > But I doubt that hw_reconfig > removal could not affect split drivers where the rc is offloaded. Like above, I think we need a new callback for rc offloaded drivers so that they can update when the bandwidth changes -- I do remove the bandwidth update after all, i.e. we no longer reconfigure the channel when it's desired to no longer TX 40 MHz. I'll think about offloaded rate control a bit more. johannes -- 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
