k...@koi8.net wrote: > That looks messy... Why would we use two different versions if we can make > everything uniform?
Because we already have something that makes it uniform, and it's broken. The idea of having a "current i2c bus" that needs to be set before read/write operations can be performed is the broken part! > Eh, you can just set bus number every time you're gonna do i2c read/write... Not with the current i2c command line. We would need another global variable in the i2c command line code to store what IT thinks is the current bus. > That i2c_get_bus_num() doesn't make any sence at all. Just set bus number > every time you access i2c device. That's risky. Sooner or later, you will want to know what the current bus number is, at least for debugging or status purposes. > U-boot is single-task so there is no other > process that can change it from under you and you do not save anything with > checking that bus number. Sounds to me like you haven't really looked at the U-Boot code. There are plenty of places where one function does I2C operations, then calls another function that does its own. I think all this boils down to one core disagreement we have: I think the idea of a "current" i2c bus is a bad one. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
