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...
Attachment:
signature.asc
Description: PGP signature
