[U-Boot-Users] PATCH: Add command support for multiple I2C controllers

[Wolfgang Denk]

Dear Ben,

in message <1147960283.16780.263.camel at saruman.qstreams.net> you wrote:
> 
> Thanks for the feedback.  Comments below.

Can you please  stop  top-posting  and  delete  irrelevant  parts  of
previous messages? Thanks.

> > No. Please read my posting again. I want to see this as compatible as
> > possible with other commands that operate  on  devices  connected  to
> > busses. We use "ide dev ...", so I want to see "i2c dev" here, too.
> > 
> > As mentioned before, in the long term all i2c related commands should
> > become sub-commands to the new "i2c" command.
> > 
> I understand and agree with your reasoning for moving all I2C commands
> to a separate tree.  On the other hand, I'm very focused on your goal of
> keeping the interface small and ALWAYS maintaining backwards
> compatibility.  If you'd like me to move all I2C commands to a separate

Yes, me too. But I don't see how adding a new "i2c dev" would disturb
backward compatibility?

> tree, it should be trivial, but makes for a bigger package.  Please
> advise.  

I'm not convinced that the new sheme will  be  significantly  bigger.
Yes,  for the transition period (when we support both the old and the
new sytax) code  will  be  bigger.  But  me  might  even  #ifdef  the
compatibility calls out....

> I agree that at first glance this is unreadable.  However, it is quite
> efficient and works well with macros.  I played around with lots of

Macros may be evil.

> #define I2C_DELIM  /* or something like that */
> #define CFG_I2C_MULTI_NOPROBES {0x11, 0x22, I2C_DELIM, 0x33, 0x44 ...}

That doesn't make it more readable. Also, how often are you going  to
use that macro in your code?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To the systems programmer,  users  and  applications  serve  only  to
provide a test load.