On Fri, 2022-04-08 at 15:52 +0300, Stanislav Lisovskiy wrote: > If ret isn't zero, it is almost for sure ETIMEDOUT, because > we use it in wait_for macro which does continuous retries > until timeout is reached. If we still ran out of time and > retries, we most likely would be interested in getting status, > to understand what was the actual error propagated from PCode, > rather than to find out that we had a time out, which is anyway > quite obvious, if the function fails. > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@xxxxxxxxx> > --- > drivers/gpu/drm/i915/intel_pcode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pcode.c b/drivers/gpu/drm/i915/intel_pcode.c > index fb6c43e8a02f..a68eaf510784 100644 > --- a/drivers/gpu/drm/i915/intel_pcode.c > +++ b/drivers/gpu/drm/i915/intel_pcode.c > @@ -202,7 +202,7 @@ int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request, > > out: > mutex_unlock(&i915->sb_lock); > - return ret ? ret : status; > + return ret ? status : ret; Isnt this equivalent to "return status" When we were discussing this, I felt this is good. But on further check with the functions gen7_check_mailbox_status(), is there a possibility that status = 0 but "request & reply_mask) != reply" for the "default" case handling? In that cast _wait_for() will be timedout with ret = ETimedOut but "status" = 0 Is that real scenario? > #undef COND > } >
