On 29 July 2016 at 17:09, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 07/29/2016 07:52 AM, Benjamin Berg wrote: [...] >> Yeah, I am aware of the fact that the firmware may do internal resets >> from time to time. The interesting question (and one for which I do not >> know the answer) is whether we get a wmi or other event under all >> conditions where the register may be rewritten due to a reset. >> >> The current code will re-set the register value after any wmi event >> including debug messages. If this is not enough, then the only solution >> might be to periodically poll the register values instead of relying on >> a received event. > > You will get a dbglog event at least most of the time, so maybe that > will be good enough. But you need to remember you need to enable dbglog first to get these events. I guess when coverage class is set the driver could, internally, override dbglog mask so that these events are guaranteed to be reported for the purpose of properly refreshing registers on channel programming. At that point I guess the update hook could be just placed in dbglog handler alone instead of all over wmi_rx variants. Michał -- 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
