On Fri, Sep 7, 2012 at 10:21 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2012-09-07 at 08:54 +0200, Vitaly Wool wrote: >> Hi Henrique, >> >> On Fri, Sep 7, 2012 at 12:44 AM, Henrique de Moraes Holschuh >> <hmh@xxxxxxxxxx> wrote: >> > >> > On Thu, 06 Sep 2012, Vitaly Wool wrote: >> > > Prevent unnecessary rfkill event generation when the state has >> > > not actually changed. These events have to be delivered to >> > > relevant userspace processes, causing these processes to wake >> > > up and do something while they could as well have slept. This >> > > obviously results in more CPU usage, longer time-to-sleep-again >> > > and therefore higher power consumption. >> > >> > Could this supress the first event when a switch is registered? Would that >> > be a concern? >> >> I'm not sure I got your question, but just in case, rfkill is >> initialized to all zeroes so rfkill->state is 0 and on each consequent >> _real_ change there (prev != curr) == true and the event will be >> generated. > > But maybe applications were expecting an event for registration? Or do > we get that anyway maybe? We should get them anyway. rfkill_fop_open() basically just pushes all the startup events into the list so the application will see all the _changes_ on registration. And at least wpa_supplicant reads out all these events on rfkill registration. If an application does something else, then I think it's buggy. ~Vitaly -- 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