At Thu, 15 Aug 2013 09:16:57 +0200, Knut Petersen wrote:
On 15.08.2013 08:22, Takashi Iwai wrote:
At Thu, 15 Aug 2013 08:01:05 +0200, Knut Petersen wrote:
On 14.08.2013 17:06, Takashi Iwai wrote:
Please resubmit only the second patch with the fixes.
Ah, yes. That should have been obvious.
After a 2nd thought I believe that it is an even better idea not to abort but to handle that error condition graciously.
Why? It's a serious error.
The probability that two 64k vmallocs will fail is pretty low, and the probability that after that failure there is enough memory for an audio application to be executed successfully is even lower.
Yes, then why you must continue the driver probing even though it's not fully functional in such an extremely bad situation? If the driver is critically important for the further operation, it'd make sense. But it's not the case.
Nevertheless, in that unlikely case I would prefer max 0.37 seconds of silence (=skipped audio) during resume to a failed start of a recording caused by an unloaded module. Limited functionality is better than complete failure.
Even if so, your patch is still missing the handling of failure case. Without the backup buffers, the driver cannot provide the full resume functionality, but it still advertises as if it can. It'd make the suspend code conditional, setting the RESUME info flag dynamically, etc.
It'd be much simpler to just let the driver aborting the problem in the error of memory allocations.
Takashi