kernel/linux.git/include/linux/iopoll.h, branch v6.18.21

iopoll: Reorder the timeout handling in poll_timeout_us()

2025-08-28T09:17:39+00:00

Currently poll_timeout_us() evaluates 'op' and 'cond' twice within the loop, once at the start, and a second time after the timeout check. While it's probably not a big deal to do it twice almost back to back, it does make the macro a bit messy. Simplify the implementation to evaluate the timeout at the very start, then follow up with 'op'/'cond', and finally check if the timeout did in fact happen or not. For good measure throw in a compiler barrier between the timeout and 'op'/'cond' evaluations to make sure the compiler can't reoder the operations (which could cause false positive timeouts). The similar i915 __wait_for() macro already has the barrier, though there it is between the 'op' and 'cond' evaluations, which seems like it could still allow 'op' and the timeout evaluations to get reordered incorrectly. I suppose the ktime_get() might itself act as a sufficient barrier here, but better safe than sorry I guess. Cc: Lucas De Marchi Cc: Dibin Moolakadan Subrahmanian Cc: Imre Deak Cc: David Laight Cc: Geert Uytterhoeven Cc: Matt Wagantall Cc: Dejin Zheng Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Jani Nikula Acked-by: Simona Vetter Signed-off-by: Ville Syrjälä Link: https://lore.kernel.org/r/20250826121859.15497-3-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula

iopoll: Avoid evaluating 'cond' twice in poll_timeout_us()

2025-08-28T09:17:32+00:00

Currently poll_timeout_us() evaluates 'cond' twice at the end of the success case. This not desirable in case 'cond' itself is expensive. Avoid the double evaluation by tracking the return value in a variable. Need to use a triple undescore '___ret' name to avoid a conflict with an existing double undescore '__ret' variable in the regmap code. Cc: Lucas De Marchi Cc: Dibin Moolakadan Subrahmanian Cc: Imre Deak Cc: David Laight Cc: Geert Uytterhoeven Cc: Matt Wagantall Cc: Dejin Zheng Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Jani Nikula Acked-by: Simona Vetter Signed-off-by: Ville Syrjälä Link: https://lore.kernel.org/r/20250826121859.15497-2-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula

iopoll: Generalize read_poll_timeout() into poll_timeout_us()

2025-08-28T09:16:36+00:00

While read_poll_timeout() & co. were originally introduced just for simple I/O usage scenarios they have since been generalized to be useful in more cases. However the interface is very cumbersome to use in the general case. Attempt to make it more flexible by combining the 'op', 'var' and 'args' parameter into just a single 'op' that the caller can fully specify. For example i915 has one case where one might currently have to write something like: ret = read_poll_timeout(drm_dp_dpcd_read_byte, err, err || (status & mask), 0 * 1000, 200 * 1000, false, aux, DP_FEC_STATUS, &status); which is practically illegible, but with the adjusted macro we do: ret = poll_timeout_us(err = drm_dp_dpcd_read_byte(aux, DP_FEC_STATUS, &status), err || (status & mask), 0 * 1000, 200 * 1000, false); which much easier to understand. One could even combine the 'op' and 'cond' parameters into one, but that might make the caller a bit too unwieldly with assignments and checks being done on the same statement. This makes poll_timeout_us() closer to the i915 __wait_for() macro, with the main difference being that __wait_for() uses expenential backoff as opposed to the fixed polling interval used by poll_timeout_us(). Eventually we might be able to switch (at least most of) i915 to use poll_timeout_us(). v2: Fix typos (Jani) Fix delay_us docs for poll_timeout_us_atomic() (Jani) Cc: Lucas De Marchi Cc: Dibin Moolakadan Subrahmanian Cc: Imre Deak Cc: David Laight Cc: Geert Uytterhoeven Cc: Matt Wagantall Cc: Dejin Zheng Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Jani Nikula Acked-by: Simona Vetter Signed-off-by: Ville Syrjälä Link: https://lore.kernel.org/r/20250826121859.15497-1-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula

iopoll/regmap/phy/snd: Fix comment referencing outdated timer documentation

2024-10-15T22:36:47+00:00

Function descriptions in iopoll.h, regmap.h, phy.h and sound/soc/sof/ops.h copied all the same outdated documentation about sleep/delay function limitations. In those comments, the generic (and still outdated) timer documentation file is referenced. As proper function descriptions for used delay and sleep functions are in place, simply update the descriptions to reference to them. While at it fix missing colon after "Returns" in function description and move return value description to the end of the function description. Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Reviewed-by: Andrew Lunn # for phy.h Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/all/20241014-devel-anna-maria-b4-timers-flseep-v3-12-dc8b907cb62f@linutronix.de

iopoll: Do not use timekeeping in read_poll_timeout_atomic()

2023-06-05T13:35:27+00:00

read_poll_timeout_atomic() uses ktime_get() to implement the timeout feature, just like its non-atomic counterpart. However, there are several issues with this, due to its use in atomic contexts: 1. When called in the s2ram path (as typically done by clock or PM domain drivers), timekeeping may be suspended, triggering the WARN_ON(timekeeping_suspended) in ktime_get(): WARNING: CPU: 0 PID: 654 at kernel/time/timekeeping.c:843 ktime_get+0x28/0x78 Calling ktime_get_mono_fast_ns() instead of ktime_get() would get rid of that warning. However, that would break timeout handling, as (at least on systems with an ARM architectured timer), the time returned by ktime_get_mono_fast_ns() does not advance while timekeeping is suspended. Interestingly, (on the same ARM systems) the time returned by ktime_get() does advance while timekeeping is suspended, despite the warning. 2. Depending on the actual clock source, and especially before a high-resolution clocksource (e.g. the ARM architectured timer) becomes available, time may not advance in atomic contexts, thus breaking timeout handling. Fix this by abandoning the idea that one can rely on timekeeping to implement timeout handling in all atomic contexts, and switch from a global time-based to a locally-estimated timeout handling. In most (all?) cases the timeout condition is exceptional and an error condition, hence any additional delays due to underestimating wall clock time are irrelevant. Signed-off-by: Geert Uytterhoeven Acked-by: Arnd Bergmann Reviewed-by: Tony Lindgren Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/3d2a2f4e553489392d871108797c3be08f88300b.1685692810.git.geert+renesas@glider.be

iopoll: Call cpu_relax() in busy loops

2023-06-05T13:35:13+00:00

It is considered good practice to call cpu_relax() in busy loops, see Documentation/process/volatile-considered-harmful.rst. This can not only lower CPU power consumption or yield to a hyperthreaded twin processor, but also allows an architecture to mitigate hardware issues (e.g. ARM Erratum 754327 for Cortex-A9 prior to r2p0) in the architecture-specific cpu_relax() implementation. In addition, cpu_relax() is also a compiler barrier. It is not immediately obvious that the @op argument "function" will result in an actual function call (e.g. in case of inlining). Where a function call is a C sequence point, this is lost on inlining. Therefore, with agressive enough optimization it might be possible for the compiler to hoist the: (val) = op(args); "load" out of the loop because it doesn't see the value changing. The addition of cpu_relax() would inhibit this. As the iopoll helpers lack calls to cpu_relax(), people are sometimes reluctant to use them, and may fall back to open-coded polling loops (including cpu_relax() calls) instead. Fix this by adding calls to cpu_relax() to the iopoll helpers: - For the non-atomic case, it is sufficient to call cpu_relax() in case of a zero sleep-between-reads value, as a call to usleep_range() is a safe barrier otherwise. However, it doesn't hurt to add the call regardless, for simplicity, and for similarity with the atomic case below. - For the atomic case, cpu_relax() must be called regardless of the sleep-between-reads value, as there is no guarantee all architecture-specific implementations of udelay() handle this. Signed-off-by: Geert Uytterhoeven Acked-by: Peter Zijlstra (Intel) Acked-by: Arnd Bergmann Reviewed-by: Tony Lindgren Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/45c87bec3397fdd704376807f0eec5cc71be440f.1685692810.git.geert+renesas@glider.be

iopoll: update kerneldoc of read_poll_timeout_atomic()

2020-09-25T14:30:06+00:00

Arguments description of read_poll_timeout_atomic() is out of date, update it. Cc: Alan Stern Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1600668815-12135-11-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman

iopoll: Introduce read_poll_timeout_atomic macro

2020-05-06T08:29:25+00:00

Like read_poll_timeout, an atomic variant for multiple parameter read function can be useful. Will be used by a later patch. Signed-off-by: Kai-Heng Feng Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200424184918.30360-1-kai.heng.feng@canonical.com

iopoll: redefined readx_poll_timeout macro to simplify the code

2020-03-24T05:00:02+00:00

redefined readx_poll_timeout macro by read_poll_timeout to simplify the code. Signed-off-by: Dejin Zheng Signed-off-by: David S. Miller

iopoll: introduce read_poll_timeout macro

2020-03-24T05:00:02+00:00

this macro is an extension of readx_poll_timeout macro. the accessor function op just supports only one parameter in the readx_poll_timeout macro, but this macro can supports multiple variable parameters for it. so functions like phy_read(struct phy_device *phydev, u32 regnum) and phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum) can also use this poll timeout core. and also expand it can sleep some time before read operation. Signed-off-by: Dejin Zheng Signed-off-by: David S. Miller