[U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4

[Wolfgang Denk]

Dear ksi at koi8.net,

In message <Pine.LNX.4.64ksi.0902142019520.6240 at home-gw.koi8.net> you wrote:
> 
> That means you have to make changes in two places instead of one -- config
> file AND $(BOARD).c. Also you use functions instead of macros and you can
> NOT make them inline because they come from a separate object file. This
> essentially defeats the very purpose of that common soft_i2c.c driver. If
> you want to make functions for bitbanged I2C into the $(BOARD).c there is no
> reason to have them as a base for that driver. It is much more logical to do
> everything in reverse, i.e. instead of having soft_i2c.c as a bona fide
> drivers and those I2C_SDA and friends as its building blocks make those
> i2c_soft_sda() etc. in each and every $(BOARD).c into primary entities and
> build the actual driver in the $(BOARD).c itself. Just convert that
> soft_i2c.c into a header file with macros for real functions (soft_i2c_read
> etc.) and instantiate them in the $(BOARD).c.

Ecept that the code you posted is unreadable and you will need lots of
very good arguments to make me accept it.

> The only problem with that is it breaks uniformity and makes another mess.
> The whole idea was to bring _ALL_ I2C drivers to a single place and make
> them totally transparent and uniform. Something like e.g. Linux VFS.

This is a boot loader with limited resources, not a general purpose
OS.

> And remember, the devil is in details. How are you going to assign
> (initialize) that innocent looking "cur_adap_nr->hwadapnr"? How are you
> going to work on an adapter other that "current" in a situation when you can
> NOT change "current" adapter (e.g. perform all I2C layer initialization
> while still running from flash?) Remember, this is plain C and there is no

What makes you insist that we cannot change a variable if we need to
be able to change one?

> And the million dollar question -- what is the potential gain?

Indeed. The  same  question  goes  to  you  -  where  is  this  added
complexity  really  needed? So far nowhere. Are we just talking about
hypothetical cases, or about a real design? How  many  such  designs?
Just a single one?

> You are adding unnecessary complexity to the code. And you break uniformity.

He. I must have thought the same before about someone else's code ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
They say a little knowledge is a dangerous thing,  but it is not  one
half so bad as a lot of ignorance.   - Terry Pratchett, _Equal Rites_