linux-kernel - Re: [PATCH v4] ASoC: wm8978: add missing BCLK divider setup

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: <CAN7C2SDzMS=uk7Qvrw4M6UP5MHgYnvSSZGuMs6OAHTWxBjqUUQ@mail.gmail.com>
Date: Thu, 9 Oct 2025 00:37:21 +0800
From: Sune Brian <briansune@...il.com>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>, Liam Girdwood <lgirdwood@...il.com>, 
	Mark Brown <broonie@...nel.org>, Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>, 
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] ASoC: wm8978: add missing BCLK divider setup

Richard Fitzgerald <rf@...nsource.cirrus.com> 於 2025年10月9日 週四 上午12:27寫道：

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

You had completely misunderstood my inherent idea.
What Mark is arguing is about the same as you proposing.
The idea from my side is that if you target 44.1K then the lowest error rate
can only do 44k then both LRCLK and BCLK are follows.
Both bit and clock are divided accordingly

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

Again, this idea is completely incorrect from first place.
There are codec allow to do so doesn't mean this is IIS standard.
Again if this idea holds then why not simply use a faster clock at anytime?
Then this patch also make no sense from beginning.
BCLK faster will always be okay, why setup the register then?

> > warning message is given to user as a reminding.
>
> Warning the user that you selected the correct BCLK is strange.

Warning message is based on what you are trying to setup on the codec.
if the background is based on mclk is fixed and bclk and lrclk is
divided from mclk.
Where bclk is follows lrclk to commit  the final closest audio S.R.
I.E. 44k1 48k etc. other than that if the setup can only make closest result.
BCLK is fasted and LRCLK = BCLK/32/2 then the result of cause is not fit.

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

Again from the very beginning comment BCLK / channel / data_bits
result in a slower
S.R. aka LRCLK then of cause it is not fit.

Brian