Re: [PATCH 3/6] ASoC: pcm3168a: Fix the DAC zero flag polarity bit

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 10/8/2026 3:09 PM, HyeongJun An wrote:
> The DAC Zero Flag Polarity enum uses PCM3168A_DAC_ATSPDA_SHIFT, which
> is bit 6 of register 70. That bit is ATSPDA, the attenuation speed,
> which the DAC Volume Rate Multiplier enum already owns. The datasheet
> puts ZREV, the zero flag polarity, at bit 0. The header defines
> PCM3168A_DAC_ZREV_SHIFT for it, but nothing uses it.
> 
> So changing the zero flag polarity changes the attenuation speed, and
> ZREV cannot be set.
> 
> Use PCM3168A_DAC_ZREV_SHIFT.

The entire message could be summarized with:

Field DAC Zero flag polarity select (ZREV) is found at offset 0 in
register DAC Control 3 (0x46), not at offset 6 - DAC Attenuation speed
(ATSPDA).


In regard to the commit title, you're not fixing the bit. Your change
actually makes pcm3168a_dac_zf_pol kctl useful and working.

ASoC: codecs: pcm3168a: Fix definition of DAC Zero polarity control

> 
> Fixes: a9b17a638af5 ("ASoC: pcm3168a: Add driver for pcm3168a codec")
> Link: https://www.ti.com/lit/ds/symlink/pcm3168a.pdf
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
> ---
>  sound/soc/codecs/pcm3168a.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/pcm3168a.c b/sound/soc/codecs/pcm3168a.c
> index cb6a6f08f2f8..6f45ea4869a7 100644
> --- a/sound/soc/codecs/pcm3168a.c
> +++ b/sound/soc/codecs/pcm3168a.c
> @@ -103,7 +103,7 @@ static SOC_ENUM_SINGLE_DECL(pcm3168a_dac_zf_func, PCM3168A_DAC_ATT_DEMP_ZF,
>  static const char *const pcm3168a_pol[] = { "Active High", "Active Low" };
>  
>  static SOC_ENUM_SINGLE_DECL(pcm3168a_dac_zf_pol, PCM3168A_DAC_ATT_DEMP_ZF,
> -		PCM3168A_DAC_ATSPDA_SHIFT, pcm3168a_pol);
> +		PCM3168A_DAC_ZREV_SHIFT, pcm3168a_pol);
Good catch. Not using the kctl with Intel's DSP + pcm3168a configuration
but won't hurt to say that no regression occurred.

I'd prefer to see a better message and commit title though the code
looks good:

Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>