✗ CI.checkpatch: warning for LMTT invalidation (rev4)

[Patchwork]

== Series Details ==

Series: LMTT invalidation (rev4)
URL   : https://patchwork.freedesktop.org/series/151092/
State : warning

== 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
43254c2aa575037fc031c7ac21b0d031c700b2bf
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit f3a82962f5f9ed49af314b6bd76b80e67d76fae2
Author: Michal Wajdeczko <michal.wajdeczko at intel.com>
Date:   Fri Jul 11 21:33:16 2025 +0200

    drm/xe/pf: Invalidate LMTT after completing changes
    
    Once we finish populating all leaf pages in the VF's LMTT we should
    make sure that hardware will not access any stale data. Explicitly
    force LMTT invalidation (as it was already planned in the past).
    
    Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
    Cc: Michał Winiarski <michal.winiarski at intel.com>
    Cc: Piotr Piórkowski <piotr.piorkowski at intel.com>
+ /mt/dim checkpatch 0302628207304d70a0e58f4822758ceddbd5f2f6 drm-intel
e7b49a8ae6ba drm/xe/pf: Prepare to stop SR-IOV support prior GT reset
-:22: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#22: 
 [ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel stopped

total: 0 errors, 1 warnings, 0 checks, 51 lines checked
458f656c645c drm/xe/pf: Resend PF provisioning after GT reset
b28ec97520f0 drm/xe/pf: Move GGTT config KLVs encoding to helper
7796cde2934d drm/xe/pf: Force GuC virtualization mode
-:17: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#17: 
 [ ] xe 0000:4d:00.0: [drm] *ERROR* GT0: FAST_REQ H2G fence 0x804e failed! e=0x30, h=0

total: 0 errors, 1 warnings, 0 checks, 44 lines checked
b1408647aa0d drm/xe/pf: Invalidate LMTT during LMEM unprovisioning
-:26: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#26: FILE: drivers/gpu/drm/xe/xe_device.h:134:
+#define for_each_gt_on_tile(gt__, tile__, id__) \
+	for_each_gt((gt__), (tile__)->xe, (id__)) \
+		for_each_if((gt__)->tile == (tile__))

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

-:26: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt__' - possible side-effects?
#26: FILE: drivers/gpu/drm/xe/xe_device.h:134:
+#define for_each_gt_on_tile(gt__, tile__, id__) \
+	for_each_gt((gt__), (tile__)->xe, (id__)) \
+		for_each_if((gt__)->tile == (tile__))

-:26: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tile__' - possible side-effects?
#26: FILE: drivers/gpu/drm/xe/xe_device.h:134:
+#define for_each_gt_on_tile(gt__, tile__, id__) \
+	for_each_gt((gt__), (tile__)->xe, (id__)) \
+		for_each_if((gt__)->tile == (tile__))

total: 1 errors, 0 warnings, 2 checks, 136 lines checked
f3a82962f5f9 drm/xe/pf: Invalidate LMTT after completing changes