radeon VS amdgpu: _afmt_init() behavior if kzalloc fails

[StDenis, Tom]

Hi,


I wrote those changes back in March as part of a cleanup sweep.  The idea being was that if some had failed the state of the driver would be unknown so it was cleaner to simply abort allocating any memory and set all of the pointers to NULL.


Generally speaking if you fail to kmalloc a few bytes you've got bigger problems to worry about than your audio not working ideally.


Tom


________________________________
From: amd-gfx <amd-gfx-bounces at lists.freedesktop.org> on behalf of Alexandre Demers <alexandre.f.demers at gmail.com>
Sent: Friday, August 12, 2016 11:43
To: Freedesktop - AMD-gfx
Cc: Alexander Deucher
Subject: radeon VS amdgpu: _afmt_init() behavior if kzalloc fails

Hi,

While comparing radeon's radeon_afmt_init() to dce_vX_0_afmt_init() on the amdgpu's side, I saw that on the latter:
1- when kzalloc fails to allocate mem for all afmt, an ENOMEM is returned
2- all previously allocated afmt are freed

So on the amdgpu's side, it is an "all or none allocated" situation, while on the radeon's side, some afmt may be allocated and initialized.

Moreover, returning an ENOMEM prevents any other function calls in dce_vX_0_sw_init() on the amdgpu's side, while it continues on the radeon's side.

What is the expected behavior here? Should we rewind the memory allocation as it is done under amdgpu when we can't allocate memory for all afmt or is it OK to do as it is done on radeon? Should we stop any remaining steps in radeon_modeset_init() if it fails (thus, returning a ENOMEM from radeon_afmt_init())?

The patch is already ready if needed, I could send it later from home if the amdgpu's behavior is the one that we are looking for.

Cheers,
Alexandre Demers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20160812/a98dd1b0/attachment.html>