lkml.org 
[lkml]   [2019]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support
From
Date
Hi Wolfram,

On 02/09/19 22:42, Wolfram Sang wrote:
> Hi Luca,
>
>> + * Topology:
>> + *
>> + * Slave X @ 0x10
>> + * .-----. |
>> + * .-----. | |---+---- B
>> + * | CPU |--A--| ATR |
>> + * `-----' | |---+---- C
>> + * `-----' |
>> + * Slave Y @ 0x10
>> + *
>> + * Alias table:
>> + *
>> + * Client Alias
>> + * -------------
>> + * X 0x20
>> + * Y 0x30
>
> Great that you already provided docs for this driver!
>
> One huge drawback for me is the attach/detach callbacks. One year ago, I
> removed a similar callback from the I2C core ("[PATCH 0/2] i2c: remove
> deprecated attach_adapter callback") because some drivers did a lot of
> crazy things there. It took years to remove all that.

Oh dear, I was completely unaware, apologies! :-)

> What I could imagine here: the adapter (B and C each in the picture
> above) gets a flag like NEEDS_ATR before registering to the core. The
> flag means all clients on that bus will have their address translated.
> The core will figure out a free alias when a device is registered. We
> can then have an ATR specific callback with the original and translated
> address as arguments, so one can setup the HW as needed.

Do you mean moving the alias selection code from i2c-atr.c to the i2c
core? And the rest of the ATR core too?

> Do you think that would work?

Yes.

--
Luca

\
 
 \ /
  Last update: 2019-09-03 10:49    [W:0.112 / U:7.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site