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

> > 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! :-)

Oh, no need to apologize. You don't have to research the whole I2C history
before implementing something. Keeping the big picture is what I happily
provide.

> > 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?

I hope for something like this in the I2C core (simplified, naming needs
to be improved etc.) in i2c_new_device:

if (client->adapter->flag & NEEDS_ATR) {
i2c_atr_get_alias_address();
/* probably a wrapper around a callback */
i2c_atr_setup_hw();
}

with all the i2c_atr_* functions in a seperate file. It would be great
if that file could be a completely independent module, but if it turns
out that we need some simple helpers in the core, I am probably OK with
that, too.

> > Do you think that would work?
>
> Yes.

Cool!

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-09-03 11:07    [W:0.045 / U:1.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site