ASoC: snd_soc_info_volsw and platfrom_max

[Srinivas Kandagatla]

On 16/08/2022 16:56, Mark Brown wrote:
> 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

Ah,

Do you think we should remove setting platform_max from these macros.

Am hoping that this should also fix the issues that am seeing.

--srini

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