Hi Jonathan, On 2026-07-27 at 22:38:28 +0800, Jonathan Cavitt wrote: > The functions intel_guc_send_busy_loop and ct_send can theoretically > loop forever. In the former case, intel_guc_send_busy_loop can iterate > forever if intel_guc_send_nb repeatedly returns -EBUSY. In the latter > case, ct_send can loop forever if the guc-to-host or host-to-guc buffers > get stuck in a full state. > > Rework the functions to use the poll_timeout_us family of functions > instead of calculating sleep_period_ms repeatedly. In both cases now, > if the loop condition is not met after 10 minutes, the function will > report it as a failure. > > This also resolves a static analysis issue involving sleep_period_ms > overflowing after several shift-left-logical calls. > > v2: > - Reduce default sleep/udelay duration (jcavitt) > > v3: > - Use atomic in ct_send (jcavitt) > > v4: > - Rework ct_send reimplementation to better preserve original logic > (Andi) > - Define 10 minutes to remove magic numbers (Krzysztof) > > v5: > - Use non-atomic poll_timeout_us in ct_send (Andi) > > Suggested-by: Jani Nikula <[email protected]> > Signed-off-by: Jonathan Cavitt <[email protected]> > Cc: Andi Shyti <[email protected]> > Cc: Krzysztof Karas <[email protected]> > ---
The failure from i915.CI.Full seems to be unrelated to your patch. The code looks good to me, so: Reviewed-by: Krzysztof Karas <[email protected]> -- Best Regards, Krzysztof
