[PATCH] drm/amdkfd: Fix type of 'dbg_flags' in 'struct kfd_process'

SRINIVASAN SHANMUGAM srinivasan.shanmugam at amd.com
Fri Dec 29 09:52:33 UTC 2023


On 12/21/2023 11:30 PM, Felix Kuehling wrote:
> On 2023-12-21 12:39, Srinivasan Shanmugam wrote:
>> dbg_flags looks to be defined with incorrect data type; to process
>> multiple debug flag options, and hence defined dbg_flags as u32.
>>
>> Fixes the below:
>>
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_packet_manager_v9.c:117 
>> pm_map_process_aldebaran() warn: maybe use && instead of &
>
> Please add a Fixes-tag:
>
> Fixes: 0de4ec9a0353 ("drm/amdgpu: prepare map process for 
> multi-process debug devices")
>
>
>>
>> Suggested-by: Lijo Lazar <lijo.lazar at amd.com>
>> Cc: Felix Kuehling <Felix.Kuehling at amd.com>
>> Cc: Christian König <christian.koenig at amd.com>
>> Cc: Alex Deucher <alexander.deucher at amd.com>
>> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam at amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> index 45366b4ca976..745024b31340 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> @@ -970,7 +970,7 @@ struct kfd_process {
>>       struct work_struct debug_event_workarea;
>>         /* Tracks debug per-vmid request for debug flags */
>> -    bool dbg_flags;
>> +    u32 dbg_flags;
>
> For consistency with the rest of this header file, I'd prefer we use 
> uint32_t here. Other than that, the patch is

Thanks for reviews & feedbacks Felix! I have proposed an another patch 
"[PATCH] drm/amdkfd: Prefer kernel data types u8, u16, u32, u64 in 
amdkfd/kfd_priv.h", where I have changed to u8, u16, u32, u64, for 
consistency, which is the preferred way as per kernel coding style.

Regards,

Srini

>
> Reviewed-by: Felix Kuehling <Felix.Kuehling at amd.com>
>
>
>>         atomic_t poison;
>>       /* Queues are in paused stated because we are in the process of 
>> doing a CRIU checkpoint */


More information about the amd-gfx mailing list