On Wed, 2008-09-24 at 17:55 +0200, Helmut Schaa wrote: > > What I meant to say is that it'll give problems with drivers that don't > > do status reporting properly, and what are you going to do when one of > > them fails anyway? retry it? how long? assume the connection was lost if > > it isn't acked? I see little point in it to start with. > > The main reason why I'd like to know when the frame was acked is that it might > happen (and it did happen in my tests already) that the frame notifying the > AP about entering power save state wasn't send before switching to another > channel. Hence the AP won't buffer any frames for us. We should make these frames able to "skip the queue" so to speak, that would be smarter either way. > > > > > + netif_tx_wake_all_queues(sdata->dev); > > > > > > > > This is worsening a problem we already have -- you can enable queues > > > > that the driver asked to be disabled. Until we fix that, I don't think > > > > we should tempt our luck even more. > > > > > > I see! That's really problematic. > > > Do you have already an idea on how to fix it? > > > > Not really; introduce bits somewhere to keep track of who wants to > > enable/disable queues I guess. > > A first trivial solution would be to just store which queues are active > when the scan is started and restarting only these queues after the scan > completed. Actually, well, you have to deal with drivers like adm8211 that stop/start the queues for each packet... johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
