linux-kernel - Re: [PATCH v2 2/3] i2c: atr: Allow unmapped addresses from nested ATRs

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] [day] [month] [year] [list]

Message-ID: <9bae963f-037a-46e1-abf6-f2ec464c4cf8@ideasonboard.com>
Date: Fri, 29 Nov 2024 15:31:45 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org, Wolfram Sang <wsa@...nel.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Cosmin Tanislav <demonsingur@...il.com>,
 Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>,
 Romain Gantois <romain.gantois@...tlin.com>,
 Matti Vaittinen <Matti.Vaittinen@...rohmeurope.com>
Subject: Re: [PATCH v2 2/3] i2c: atr: Allow unmapped addresses from nested
 ATRs

On 29/11/2024 13:53, Luca Ceresoli wrote:

>> So strictly speaking it's not an ATR, but this achieves the same.
> 
> Thanks for the extensive and very useful explanation. I had completely
> missed the GMSL serder and their different I2C handling, apologies.
> 
> So, the "parent ATR" is the GMSL deser, which is not an ATR but
> implementing it using i2c-atr makes the implementation cleaner. That
> makes sense.

Right.

But, honestly, I can't make my mind if I like the use of ATR here or not =).

So it's not an ATR, but I'm not quite sure what it is. It's not just 
that we need to change the addresses of the serializers, we need to do 
that in particular way, enabling one port at a time to do the change.

If we forget about the init time hurdles, and consider the situation 
after the serializers are been set up and all ports have been enabled, 
we have:

There's the main i2c bus, on which we have the deserializer. The 
deserializer acts as a i2c repeater (for any transaction that's not 
directed to the deser), sending the messages to all serializers. The 
serializers catch transactions directed at the ser, and everything else 
goes through ATR and to the remote bus.

Do we have something that represents such a "i2c repeater"? I guess we 
could just have an i2c bus, created by the deser, and all the sers would 
be on that bus. So we'd somehow do the initial address change first, 
then set up the i2c bus, and the serializer i2c clients would be added 
to that bus.

  Tomi