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...