Re: [PATCH 1/8] rfkill: Documentation and style fixes

 /**
  * 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?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 19 January 2016 at 15:11, Johannes Berg [off-list ref] wrote:

quoted

 /**
  * 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.