[U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions

[Timur Tabi]

ksi at koi8.net wrote:

> That looks similar. But why do you want to remove i2c_set_bus_num()? I think
> it would be less work to keep it. 

Perhaps, but it would be even better to get rid of it.  IMHO, it's a kludge.  It
was a hack added to allow existing I2C routines to function while adding minimal
support for multiple buses on those platforms that needed it.

> This way you can leave 90% or so of
> existing I2C code unchanged by setting bus number to 0 at init. 

I only intend on exporting the multiple-bus versions of the I2C function if
CONFIG_I2C_MULTI_BUS is defined.

> My idea is to have global bus number variable in a single place and a single
> i2c_set_bus_num() that can be excluded for most boards with a single bus
> with #ifdef...

We already have something like that.  A global variable is inconvenient because
every time you want to access the bus, you need to do something like this:

	bus = i2c_get_bus_num();
	i2c_set_bus_num(x);
	i2c_write(...)
	i2c_set_bus_num(bus);

We need to save/restore the current bus number, because the I2C command-line has
the concept of a

> Then, we could use some kind of array of I2C structures each containing
> pointers to appropriate i2c-{read,write,probe,init}() functions with generic
> i2c functions just calling those pointers using bus number as index into
> that array.

Sounds complicated.

> That would allow for unlimited number of different adapters for any board.

Ah, now this is something else entirely.  I don't think U-boot supports this at
all.  I think you're being too ambitious.  It's a noble idea, and I think U-boot
should support it, but I think we need to simplify the support for multiple
buses first.

> Initial code for initializing such an array would have to go into each and
> every $(BOARD).c board specific file.

Ugh.

-- 
Timur Tabi
Linux kernel developer at Freescale