Thanks for the quick answer Tom. I was thinking mostly as you do, but before sending the patch to the list, I wanted to be sure it was worth it. I'll send the patch later then, unless someone says otherwise. Cheers, Alexandre On Fri, 12 Aug 2016 at 11:50 StDenis, Tom <Tom.StDenis at amd.com> wrote: > 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/e73a28f9/attachment-0001.html>
