linux-kernel - Re: [PATCH] ASoC: fsl_sai: Fix sync error in consumer mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA+D8ANhErMaJWAOvjMWc=2xq+bsYBJ5eLeN+jg8B4=K+aQsnQ@mail.gmail.com>
Date: Mon, 27 Oct 2025 13:39:07 +0800
From: Shengjiu Wang <shengjiu.wang@...il.com>
To: Maarten Zanders <maarten@...ders.be>
Cc: Xiubo Li <Xiubo.Lee@...il.com>, Fabio Estevam <festevam@...il.com>, 
	Nicolin Chen <nicoleotsuka@...il.com>, Liam Girdwood <lgirdwood@...il.com>, 
	Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, 
	Zidan Wang <zidan.wang@...escale.com>, linux-sound@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: fsl_sai: Fix sync error in consumer mode

On Fri, Oct 24, 2025 at 9:58 PM Maarten Zanders <maarten@...ders.be> wrote:
>
> When configured for default synchronisation (Rx syncs to Tx) and the
> SAI operates in consumer mode (clocks provided externally to Tx), a
> synchronisation error occurs on Tx on the first attempt after device
> initialisation when the playback stream is started while a capture
> stream is already active. This results in channel shift/swap on the
> playback stream.
> Subsequent streams (ie after that first failing one) always work
> correctly, no matter the order, with or without the other stream active.
>
> This issue was observed (and fix tested) on an i.MX6UL board connected
> to an ADAU1761 codec, where the codec provides both frame and bit clock
> (connected to TX pins).
>
> To fix this, always initialize the 'other' xCR4 and xCR5 registers when
> we're starting a stream which is synced to the opposite one, irregardless
> of the producer/consumer status.
>
> Fixes: 51659ca069ce ("ASoC: fsl-sai: set xCR4/xCR5/xMR for SAI master mode")
>
> Signed-off-by: Maarten Zanders <maarten@...ders.be>

Reviewed-by: Shengjiu Wang <shengjiu.wang@...il.com>

Best regards
Shengjiu wang
> ---
>  sound/soc/fsl/fsl_sai.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 757e7868e322..178a6e8fbe2c 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -653,12 +653,12 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
>                 val_cr4 |= FSL_SAI_CR4_CHMOD;
>
>         /*
> -        * For SAI provider mode, when Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will
> -        * generate bclk and frame clock for Tx(Rx), we should set RCR4(TCR4),
> -        * RCR5(TCR5) for playback(capture), or there will be sync error.
> +        * When Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will provide bclk and
> +        * frame clock for Tx(Rx). We should set RCR4(TCR4), RCR5(TCR5)
> +        * for playback(capture), or there will be sync error.
>          */
>
> -       if (!sai->is_consumer_mode[tx] && fsl_sai_dir_is_synced(sai, adir)) {
> +       if (fsl_sai_dir_is_synced(sai, adir)) {
>                 regmap_update_bits(sai->regmap, FSL_SAI_xCR4(!tx, ofs),
>                                    FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK |
>                                    FSL_SAI_CR4_CHMOD_MASK,
> --
> 2.51.0
>