[PATCH] ASoC: ops: Don't modify the driver's plaform_max when reading state

[Mark Brown]

On Fri, Aug 19, 2022 at 06:17:25PM +0200, Martin Povišer wrote:
> > On 3. 6. 2022, at 13:25, Mark Brown <broonie at kernel.org> wrote:

> > This means that platform_max is no longer treated as a direct register
> > value for controls were min is non-zero. The put() callbacks already
> > validate on this basis, and there do not appear to be any in tree users
> > that would be affected.

> At least ‘put_volsw' seem to validate on the other conflicting interpretation
> of platform_max [as was introduced in commit 9bdd10d57a88 (“ASoC: ops:
> Shift tested values in snd_soc_put_volsw() by +min”)].

Ugh, so it does.  The patchwork of reuse and differing interpretations
of these controls is causing all sorts of confusion :/

> Also, the soc.h definitions of SOC_SINGLE_*/SOC_DOUBLE_* set platform_max
> to the register maximum, again interpreting platform_max the other way.

That use of platform_max has been removed since it was just obviously
not sensible anyway, the whole purpose of platform_max is to override
what was set in the control so having both max and platform_max set is
just redundant and causing confusion.

> > Signed-off-by: Mark Brown <broonie at kernel.org>

> This commit breaks controls with non-zero minimum.

Could you specify more exactly how it does that, and indeed where we
have non-zero minimums - all the info callbacks report 0 as a minimum as
far as I can see?  Life would be a lot simpler if the controls had all
been defined to just be the register values, I've never been able to
figure out why they're anything else since the ABI for controls supports
negative values just fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20220819/7a2af839/attachment.sig>