Re: [PATCH 2/3] ASoC: core: Inline resume work back to resume function

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

On Fri, Nov 04, 2022 at 09:58:46AM -0400, Pierre-Louis Bossart wrote:
> On 11/4/22 09:12, Cezary Rojewski wrote:

> > Commit 6ed2597883b1 ("ALSA: ASoC: Don't block system resume") introduced
> > deferred_resume_work for ASoC subsystem. While this allows for potential
> > speed up during boot on some slow devices, it doesn't allow to properly
> > propagate return values in case something failed during system resume.

> Are you suggesting to remove this workqueue that's been there since
> 2008, which would impact negatively slow devices?

Indeed, and the definition of fast and slow is a bit of a moving target
- the faster the rest of the system can resume the less desirable it is
to block on for example an I2C register map resync even if the hundreds
of miliseconds of ramp time that were an issue originally.

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]