On Mon, Nov 07, 2022 at 10:26:14AM +0100, Cezary Rojewski wrote:
On 2022-11-05 12:54 AM, Mark Brown wrote:
The other question is what we'd constructively do about a resume failure that we can't defer. It feels like we should at least retain the ability to defer for devices where this is an issue (older components
I believe that framework should be supporting both, the deferred and the instant resume options. 'void' in front of suspend/resume in ASoC hinders developer's options.
It'd be good to at least have some idea of practical usage as well, the functions return void because nothing was making any use of the return values.
(load) The HDAudio driver is actually a good example of how to do it right - we did not modify driver/base/ to have ->probe() return void. It remained as is, instead, a developer opt-ins for a delayed probe through a workqueue. This way, everyone is satisfied. Cohesiveness is not to be forgotten too - keeping behavior and expectations of the standard set of functionalities aligned with the rest of the driver/base makes it easier to hop into ASoC.
There's also an expectation that suspend and resume be fast...