ASoC: snd_soc_info_volsw and platfrom_max

[Mark Brown]

On Tue, Aug 16, 2022 at 02:44:47PM +0100, Srinivas Kandagatla wrote:
> On 16/08/2022 14:11, Mark Brown wrote:
> > On Mon, Aug 15, 2022 at 10:22:37AM +0100, Srinivas Kandagatla wrote:

> > The issue is that it's not clear if the platform_max value should be a
> > value for the register or a value for the control.  For some reason
> > (which frankly is the source of a lot of the problems here) the controls
> > adjust the user visible range to be zero based even though the ABI would
> > be totally fine with any range.  There were out of tree patches that
> > changed things for some of the control types too.

> Only Instances where platform_max is set are via kcontrol builder macros,
> which then always sets this to xmax.

Those macros just shouldn't be setting platform_max at all, the whole
goal with platform_max is that it overrides what the driver is doing for
platform specific reasons.  This is supposed to be overridable by the
machine integration, but looking now it looks like it's got lost in the
shuffle, I can't see any mechanism to configure it via DT or machine
drivers right now though I think there might be some out of tree drivers
that do it or perhaps I'm doing the wrong greps.

> And none of these macros have provision to pass platform_max these are
> always assumed to be xmax. Which am not sure is always correct.

That's entirely correct in that if it's not been overridden by the
platform then we should just use whatever the driver provided.

> -	max = uinfo->value.integer.max = mc->max - mc->min;
> +	max = uinfo->value.integer.max = mc->max;

Don't do double assignments like this, they're confusing.
-------------- 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/20220816/3be9f071/attachment.sig>