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: <20241126091610.05e2d7c7@booty>
Date: Tue, 26 Nov 2024 09:16:10 +0100
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.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>
Subject: Re: [PATCH v2 2/3] i2c: atr: Allow unmapped addresses from nested
 ATRs

Hello Tomi,

On Fri, 22 Nov 2024 14:26:19 +0200
Tomi Valkeinen <tomi.valkeinen@...asonboard.com> wrote:

> From: Cosmin Tanislav <demonsingur@...il.com>
> 
> i2c-atr translates the i2c transactions and forwards them to its parent
> i2c bus. Any transaction to an i2c address that has not been mapped on
> the i2c-atr will be rejected with an error.
> 
> However, if the parent i2c bus is another i2c-atr, the parent i2c-atr
> gets a transaction to an i2c address that is not mapped in the parent
> i2c-atr, and thus fails.

Nested ATRs are "interesting", to say the least! :-)

I must say I don't understand the problem here. If this is the picture:

  adapter ---->     ATR1     ---->     ATR2     ----> leaf device
                    map:               map:              addr:
                 alias addr         alias addr           0x10
                 0x30  0x20         0x20  0x10

Then I'd expect this:

 1. the leaf device asks ATR2 for a transaction to 0x10
 2. 0x10 is in ATR2 map, ATR2 translates address 0x10 to 0x20
 3. ATR2 asks ATR1 for a transaction to 0x20
 4. 0x20 is in ATR1 map, ATR1 translates address 0x20 to 0x30
 5. ATR1 asks adapter for transaction on 0x30

So ATR1 is never asked for 0x10.

However I'm very likely missing something. Can you elaborate with a
practical example?

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ