[PATCH] Release the mutex hold before backtracing for not supported mxgpu.

[Christian König]

Am 20.12.2017 um 03:44 schrieb Yu, Xiangliang:
>> This patch releases the mutex held soon before entering the initialization
>> function in case the device doesn't support mxgpu.
>>
>> Signed-off-by: José Pekkarinen <koalinux at gmail.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
>> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
>> index c25a831f94ec..cac1d8b003e6 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
>> @@ -307,6 +307,7 @@ void xgpu_vi_init_golden_registers(struct
>> amdgpu_device *adev)
>>
>> xgpu_tonga_golden_common_all));
>>   		break;
>>   	default:
>> +		mutex_unlock(&adev->grbm_idx_mutex);
>>   		BUG_ON("Doesn't support chip type.\n");
>>   		break;
>>   	}
> The release mutex in here has no meaning as kernel will hang later.

A BUG_ON() results in killing the current process/thread. That usually 
results in a kernel hang *BECAUSE* you usually don't cleanly unlock all 
the taken locks.

So this patch is actually the first step on cleaning up the code.

BTW: Also please use BUG() + comment instead of BUG_ON() with a fixed text.

Thanks,
Christian.

> And Alex has submitted patch to check ASIC IP during detecting SRIOV, so we can't see the case anymore. Please drop the patch.
>
> Thanks!
>
>> --
>> 2.13.6
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx