On Thu, 2012-06-28 at 20:48 +0200, Johannes Berg wrote: > On Thu, 2012-06-28 at 20:44 +0200, Arend van Spriel wrote: > > > >>> So not taking the drop flag into account? Any plan to change that? > > >>> > > >> yeah, good point... > > >> i guess we'll want to add support for the drop flag as well. > > >> > > >> Luca - you can either drop this patch, or apply it for now and i'll > > >> send another patch later on. > > > > > > Currently we drop all the packets if we can't flush them within a > > > reasonable time. We always do this right now. I think that's good > > > enough? > > > > > > > Hard to say as I am working mostly on your side of this API. However, > > the drop flag is part of the API so there is probably a reason for > > having it. Johannes? > > The drop never actually used today... but we had plans to use it in some > cases I think. I have just grepped the code and I also see that drop is always false as it is. Of course, the API specifies this drop parameter and how it should be handled, so we should treat it too, so nothing breaks if mac80211 changes. But, as defined in the API documentation: * @flush: Flush all pending frames from the hardware queue, making sure * that the hardware queues are empty. If the parameter @drop is set * to %true, pending frames may be dropped. The callback can sleep. Frames *may* be dropped if drop is set to true. We don't *have* to drop them, so it should be fine to ignore it and remain true to the API specification. -- Luca. -- 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
