linux-kernel - Re: [PATCH v3] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAN7C2SATEDK4C-C7NOOvSKsQnfDBMStogkR8vFBAS+tejLbtNw@mail.gmail.com>
Date: Wed, 8 Oct 2025 22:37:03 +0800
From: Sune Brian <briansune@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>, Liam Girdwood <lgirdwood@...il.com>, 
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>, linux-sound@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ASoC: wm8978: add missing BCLK divider setup

Mark Brown <broonie@...nel.org> 於 2025年10月8日 週三 下午10:20寫道：

> Many devices (including all the Wolfson ones of that era IIRC) will
> happily just ignore extra cycles on BCLK, the issue here is handling of
> a f_256fs which is a bit off what it should be for some reason.  You're
> assuming that the device is clocked at an exact and suitable multiple of
> the sample rate like it's supposed to be but in practice these devices
> work well enough for the system's purposes when the clocking is merely
> close, they tend not to be particularly fragile and users perhaps not so
> deeply concerned with audio fidelity.  Note the warning the driver will
> generate about considering using the PLL to fix up such misclocking.

If this concept holds.
Are you telling me a operatable case audio can output just quicker or
slower on such w/o issue?
Are you telling me the left/right channel bits  are able to load
correctly on fixed lrclk while bclk is overclock?
If so why this patch required from first place?
Running bclk quick and just feed in the left/right channel data on
1bit delay on both channel should works on IIS.
Just make bclk /2 or /4 from mclk always works while LRCLK just fixed
to 44.1k 48k or any audio SR?
Datasheet WM8978: Figure 38 I2 S Audio Interface (assuming n-bit word length)

Why we got to argue this things?

What merely close is based on bclk and lrclk is correlated properly?
For example bclk is fasted then bclk/bit_size/channel_num = lrclk
faster then this is still holds.
Do LRCLK is fixed but BCLK is far faster still runs properly?

I think if the patch is not good enough just drop this idea.
I cannot understand what operation scope you are expecting.

Brian