✓ CI.checkpatch: success for drm/xe/gsc: do not flush the GSC worker from the reset path (rev2)

[Patchwork]

== Series Details ==

Series: drm/xe/gsc: do not flush the GSC worker from the reset path (rev2)
URL   : https://patchwork.freedesktop.org/series/147944/
State : success

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
202708c00696422fd217223bb679a353a5936e23
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit c8ee58bdd8415e41d211783d80a4ef7e0146e6c5
Author: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
Date:   Fri May 2 08:51:04 2025 -0700

    drm/xe/gsc: do not flush the GSC worker from the reset path
    
    The workqueue used for the reset worker is marked as WQ_MEM_RECLAIM,
    while the GSC one isn't (and can't be as we need to do memory
    allocations in the gsc worker). Therefore, we can't flush the latter
    from the former.
    
    The reason why we had such a flush was to avoid interrupting either
    the GSC FW load or in progress GSC proxy operations. GSC proxy
    operations fall into 2 categories:
    
    1) GSC proxy init: this only happens once immediately after GSC FW load
       and does not support being interrupted. The only way to recover from
       an interruption of the proxy init is to do an FLR and re-load the GSC.
    
    2) GSC proxy request: this can happen in response to a request that
       the driver sends to the GSC. If this is interrupted, the GSC FW will
       timeout and the driver request will be failed, but overall the GSC
       will keep working fine.
    
    Flushing the work allowed us to avoid interruption in both cases (unless
    the hang came from the GSC engine itself, in which case we're toast
    anyway). However, a failure on a proxy request is tolerable if we're in
    a scenario where we're triggering a GT reset (i.e., something is already
    gone pretty wrong), so what we really need to avoid is interrupting
    the init flow, which we can do by polling on the register that reports
    when the proxy init is complete (as that ensure us that all the load and
    init operations have been completed).
    
    Note that during suspend we still want to do a flush of the worker to
    make sure it completes any operations involving the HW before the power
    is cut.
    
    v2: fix spelling in commit msg, rename waiter function (Julia)
    
    Fixes: dd0e89e5edc2 ("drm/xe/gsc: GSC FW load")
    Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
    Cc: John Harrison <John.C.Harrison at Intel.com>
    Cc: Alan Previn <alan.previn.teres.alexis at intel.com>
    Cc: <stable at vger.kernel.org> # v6.8+
    Reviewed-by: Julia Filipchuk <julia.filipchuk at intel.com>
+ /mt/dim checkpatch 0135b020716c4986b53b735e41753ebb8ed43c3e drm-intel
c8ee58bdd841 drm/xe/gsc: do not flush the GSC worker from the reset path