On 2022-11-05 12:54 AM, Mark Brown wrote:
On Fri, Nov 04, 2022 at 09:58:46AM -0400, Pierre-Louis Bossart wrote:
If I follow your logic, we should also remove the workqueue used for probes for HDaudio devices, on the grounds that probe errors are not propagated either.
(save)
Any time we have deferred processing to avoid blocking the rest of the system, we incur the risk of not having errors propagated. It's a compromise between having a system that's usable and a system that's consistent.
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 tend to be cheap and packaged in easier to assemble packaging and hence get used with lower end applications even well after they're no longer competitive at the high end), and if we are going to return some errors in line it'd be good to understand the benefits and tradeoffs. I do see that it is a lot less useful for modern devices where we don't have to have any delays in startup, though like I say register I/O on slower buses like I2C could still be a concern.
I'm not keen on moving the support out of the core since there were originally a bunch of devices trying to open code and it wasn't good, both from a duplication/complexity point of view and from the point of view of integrating well with userspace APIs.
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.
(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.
We could provide some additional flags so that the ASoC core always defers PM-related work for certain components if they choose to.
Regards, Czarek