On 19 January 2016 at 15:11, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > >> /** >> * rfkill_resume_polling(struct rfkill *rfkill) >> * >> - * Pause polling -- say transmitter is off for other reasons. >> + * Resume polling previously paused with rfkill_pause_polling. >> * NOTE: not necessary for suspend/resume -- in that case the >> - * core stops polling anyway >> + * core restarts polling anyway, even if was explicitly paused >> + * before suspending. >> */ > > If this is true, that's a bug, no? Drivers would call pause/resume when > their status changes, and shouldn't be required to check status at > resume time? > I did not dive too much into the logic here, but rfkill_resume_polling() is called unconditionally on rfkill_resume(), so it seems that if a driver call rfkill_pause_polling() before suspend, on resume polling will be "un-paused". That indeed looks strange. -- João Paulo Rechi Vita http://about.me/jprvita -- 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
