Hi Nathan,
On Tue, May 30, 2023 at 11:24:39AM -0700, Nathan Chancellor wrote:
> When building with clang's -Wincompatible-function-pointer-types-strict,
> the following warnings occur:
>
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible function pointer types assigning to 'void (*)(struct i915_address_space *, dma_addr_t, u64, unsigned int, u32)' (aka 'void (*)(struct i915_address_space *, unsigned int, unsigned long long, unsigned int, unsigned int)') from 'void (struct i915_address_space *, dma_addr_t, u64, enum i915_cache_level, u32)' (aka 'void (struct i915_address_space *, unsigned int, unsigned long long, enum i915_cache_level, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.insert_page = gmch_ggtt_insert_page;
> ^ ~~~~~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:103:26: error: incompatible function pointer types assigning to 'void (*)(struct i915_address_space *, struct i915_vma_resource *, unsigned int, u32)' (aka 'void (*)(struct i915_address_space *, struct i915_vma_resource *, unsigned int, unsigned int)') from 'void (struct i915_address_space *, struct i915_vma_resource *, enum i915_cache_level, u32)' (aka 'void (struct i915_address_space *, struct i915_vma_resource *, enum i915_cache_level, unsigned int)') [-Werror, -Wincompatible-function-pointer-types-strict]
> ggtt->vm.insert_entries = gmch_ggtt_insert_entries;
> ^ ~~~~~~~~~~~~~~~~~~~~~~~~
> 2 errors generated.
>
> The warning is pointing out that while 'enum i915_cache_level' and
> 'unsigned int' are ABI compatible, these indirect calls will fail
> clang's kernel Control Flow Integrity (kCFI) checks, as the callback's
> signature does not exactly match the prototype's signature.
>
> To fix this, replace the cache_level parameter with pat_index, as was
> done in other places within i915 where there is no difference between
> cache_level and pat_index on certain generations.
>
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Signed-off-by: Nathan Chancellor <nathan@xxxxxxxxxx>
same clang issue as before, I'm OK with this patch, from my side:
Reviewed-by: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
Thanks,
Andi
