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: <53ba5ea7-ab5f-41dd-853e-2e39efac1321@opensource.cirrus.com>
Date: Wed, 8 Oct 2025 17:27:12 +0100
From: Richard Fitzgerald <rf@...nsource.cirrus.com>
To: Brian Sune <briansune@...il.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc: linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] ASoC: wm8978: add missing BCLK divider setup

On 08/10/2025 5:04 pm, Brian Sune wrote:
> In previous WM8978 codec driver versions, wm8978_set_dai_clkdiv
> might not have been called for BCLK, leaving the bit clock
> divider unconfigured. This could cause incorrect or unstable audio
> clocks depending on sample rate and word length.
> 
> This patch adds a check in wm8978_hw_params: if the BCLK divider
> has not been set via wm8978_set_dai_clkdiv, it is dynamically
> calculated and configured at runtime.
> This ensures that BCLK is always correctly set, whether the
> machine driver configures it explicitly or not.
> 
> Apart from this core patch, due to request from Mark Brown and
> Charles Keepax. Overclock BCLK setup is applied, and dropped the
> possible lowest error BCLK result.

Selecting a lowest-error rate is not valid I2S.
You must have enough BCLK cycles to send all the data. If number
of BCLK cycles < number of sample bits you cannot send all the
sample bits. So that would be an incorrect setup.

> On top of the overclocking,

Using a higher BCLK is valid I2S. In fact, it is exactly defined in the
I2S specification that there can be more BCLK cycles than data bits
and the RX end should ignore extra cycles.

> warning message is given to user as a reminding.

Warning the user that you selected the correct BCLK is strange.

> This patch author do not agree with this design nor
> concept from first place!

For example if you are sending stereo 16-bit samples at 48 kHz you must
have a BCLK at least 48000 * 16 * 2 = 1536000 Hz.

If the _nearest_ BCLK is < 1536000 you don't have enough clock
cycles to send all the sample bits.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ