Dear k...@koi8.net, In message <pine.lnx.4.64ksi.0902142019520.6...@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: w...@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_ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
