linux-kernel - Re: [PATCH 00/13] Analog Devices Inc. Automotive Audio Bus (A2B) support

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]

Date: Tue, 21 May 2024 07:08:14 +0000
From: Alvin Šipraga <ALSI@...g-olufsen.dk>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Alvin Šipraga <alvin@...s.dk>, Mark Brown
	<broonie@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
	<brgl@...ev.pl>, Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela
	<perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Michael Turquette
	<mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Andi Shyti
	<andi.shyti@...nel.org>, Saravana Kannan <saravanak@...gle.com>, Emil
 Abildgaard Svendsen <EMAS@...g-olufsen.dk>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>, "linux-sound@...r.kernel.org"
	<linux-sound@...r.kernel.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, "linux-i2c@...r.kernel.org"
	<linux-i2c@...r.kernel.org>, Alvin Šipraga
	<ALSI@...g-olufsen.dk>
Subject: Re: [PATCH 00/13] Analog Devices Inc. Automotive Audio Bus (A2B)
 support

On Fri, May 17, 2024 at 04:57:57PM GMT, Wolfram Sang wrote:
> 
> >   On subordinate nodes the I2C interface functions in controller
> >   (master) mode, providing an additional I2C adapter to the host for
> >   each subordinate node connected to the A2B bus.
> 
> I am not sure I got this right? That would mean for an I2C adapter on a
> subordinate node, that there might be targets connected to only that
> subordinate node? How do its messages go to the host machine? Is I2C
> encapsulated over I2C? I probably missed something.
>

Yes, each subordinate node exposes a whole discrete I2C segment, so you
can have two targets with the same address connected to two different
subordinate nodes respectively. Hence a new i2c_adapter for each
subordinate node.

The way it works is that the main node responds on two I2C addresses,
typically 0x68 and 0x69, labelled "BASE" and "BUS" respectively. BASE
always addresses the register map of the main node. BUS is a "proxy" and
addresses either the register map of a subordinate node, or a given
peripheral connected to the targetted subordinate node. This is
configured in some register fields of the main/subordinate nodes.

When addressing a target connected to the I2C controller of a
subordinate node, a register field of the given subordinate node must be
populated with the target's I2C address. The hardware will then proxy
I2C messages towards the main node's BUS address over the A2B bus
through to the selected subordinate node's I2C controller interface, and
will rewrite the address (BUS, 0x69) to whatever target address was
programmed into that subordinate node. The I2C interface of the main
node performs clock stretching so that the transfer is synchronous and
transparent to the host.

You can see the implementation details in the ad24xx-i2c.c "interface
driver":

 (a) main/subordinate node register map access: __ad24xx_i2c_read() and
     __ad24xx_i2c_write()

 (b) subordinate node I2C target access: __ad24xx_i2c_xfer()

A more detailed description of the logic can be found in [1] section 3-1
"I2C Port Programming Concepts":

[1] https://www.analog.com/media/en/technical-documentation/user-guides/ad242x-trm.pdf

Hope that clears it up.