✗ CI.checkpatch: warning for drm/gpuvm: merge adjacent gpuva range during a map operation

[Patchwork]

== Series Details ==

Series: drm/gpuvm: merge adjacent gpuva range during a map operation
URL   : https://patchwork.freedesktop.org/series/138835/
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
c62d7e164862503a3662a095da1c6c9014248cb2
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit e16e525dc01d223c682126d84e9cac4daaca27c9
Author: Oak Zeng <oak.zeng at intel.com>
Date:   Wed Sep 18 12:47:40 2024 -0400

    drm/gpuvm: merge adjacent gpuva range during a map operation
    
    Considder this example. Before a map operation, the gpuva ranges
    in a vm looks like below:
    
     VAs | start              | range              | end                | object             | object offset
    -------------------------------------------------------------------------------------------------------------
         | 0x0000000000000000 | 0x00007ffff5cd0000 | 0x00007ffff5cd0000 | 0x0000000000000000 | 0x0000000000000000
         | 0x00007ffff5cf0000 | 0x00000000000c7000 | 0x00007ffff5db7000 | 0x0000000000000000 | 0x0000000000000000
    
    Now user want to map range [0x00007ffff5cd0000 - 0x00007ffff5cf0000).
    With existing codes, the range walking in __drm_gpuvm_sm_map won't
    find any range, so we end up a single map operation for range
    [0x00007ffff5cd0000 - 0x00007ffff5cf0000). This result in:
    
     VAs | start              | range              | end                | object             | object offset
    -------------------------------------------------------------------------------------------------------------
         | 0x0000000000000000 | 0x00007ffff5cd0000 | 0x00007ffff5cd0000 | 0x0000000000000000 | 0x0000000000000000
         | 0x00007ffff5cd0000 | 0x0000000000020000 | 0x00007ffff5cf0000 | 0x0000000000000000 | 0x0000000000000000
         | 0x00007ffff5cf0000 | 0x00000000000c7000 | 0x00007ffff5db7000 | 0x0000000000000000 | 0x0000000000000000
    
    The correct behavior is to merge those 3 ranges. So __drm_gpuvm_sm_map
    is slightly modified to handle this corner case. The walker is changed
    to find the range just before or after the mapping request, and merge
    adjacent ranges using unmap and map operations. with this change, the
    end result of above example is as below:
    
     VAs | start              | range              | end                | object             | object offset
    -------------------------------------------------------------------------------------------------------------
         | 0x0000000000000000 | 0x00007ffff5db7000 | 0x00007ffff5db7000 | 0x0000000000000000 | 0x0000000000000000
    
    Even though this fixes a real problem, the codes looks a little ugly.
    So I welcome any better fix or suggestion.
    
    Signed-off-by: Oak Zeng <oak.zeng at intel.com>
+ /mt/dim checkpatch 15aeb2cced25e1bfa15f1aa538247d79cf8b0a05 drm-intel
e16e525dc01d drm/gpuvm: merge adjacent gpuva range during a map operation
-:9: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#9: 
 VAs | start              | range              | end                | object             | object offset

-:106: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#106: FILE: drivers/gpu/drm/drm_gpuvm.c:2185:
+						if (ret)

-:151: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#151: FILE: drivers/gpu/drm/drm_gpuvm.c:2247:
+						if (ret)

total: 0 errors, 3 warnings, 0 checks, 124 lines checked