linux-kernel - Re: [PATCH 0/7] ASoC: basic support for configuring bus keepers

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: <aTjePJuPNegXc9cl@sirena.co.uk>
Date: Wed, 10 Dec 2025 11:43:08 +0900
From: Mark Brown <broonie@...nel.org>
To: James Calligeros <jcalligeros99@...il.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Shengjiu Wang <shengjiu.wang@....com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Shenghao Ding <shenghao-ding@...com>, Kevin Lu <kevin-lu@...com>,
	Baojun Xu <baojun.xu@...com>, linux-sound@...r.kernel.org,
	devicetree@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	asahi@...ts.linux.dev
Subject: Re: [PATCH 0/7] ASoC: basic support for configuring bus keepers

On Tue, Dec 09, 2025 at 07:31:13PM +1000, James Calligeros wrote:

> Consider a device with two codecs that report voice coil voltage and
> current data back to the host via I2S. Codec A is configured to transmit
> its V/ISENSE data on TDM slots 1 and 3, while Codec B is configured to
> do so on slots 2 and 4. The receiving end sums the two together.
> If Codec A transmits anything on slots 2 or 4 (and vice versa), the
> result is a bus conflict.

> Some codecs include configurable bus keepers to ameliorate this issue.

You've not really mentioned an issue here?  The expected behaviour for
TDM is that devices should only drive the the slots they are configured
to drive and should let the bus float otherwise, otherwise no other
device could transmit.

> Notable examples are the TI TAS2764 and TAS2770. By default, these
> codecs keep their SDOUT pin floating during unconfigured TDM slots,
> however this can result in garbage data on the bus. TAS2764 can be
> set up to fill specific TDM slots with zeroes, TAS2770 can hold its
> SDOUT pin to ground.

Right, so AIUI this is the actual thing you're trying to do - you want
to additionally configure a CODEC to drive slots it's not putting data
on to ensure there are no dead slots on the bus?  I guess you might have
some restrictions on clocking which mean you need extra BCLKs (eg,
needing power of 2 clocks).  But I'm having a hard time connecting this
to your description below so I don't think I've followed what you're
saying here.

> This feature is necessary to properly drive the speaker systems found
> on most Apple Silicon laptops. All but three models include six codecs
> in two groups of three driving two woofers and a tweeter on both the left
> and right channels. Each codec group has a single line for SDOUT, to
> which all codecs are connected. The two groups are then summed on to
> one I2S port. Each group must ensure that it is silent on the bus while
> the other is supposed to be active.

So is there one SDOUT or two which are connected... somehow?  I'm
confused.

> In the downstream Asahi Linux kernel[1], we set up one codec in each
> group to zero-fill or pull down its group's side of the bus for the
> opposite group's transmit slots. This is done entirely in the codec
> driver, however this approach is perhaps over-fit for our use case.
> Following previous mailing list discussions[2], I have tried to
> expose the functionality in a more configurable and generic way.

I can't parse what this is describing at all, sorry.  What is a "side"
of a bus, and how is all this different to idle TDM slots?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)