>From what I read, I believe the eCos strategy is to return status, not error, >in APIs.
With respect to SMBus, the following are typically status: - Timeout - Loss of Arbitration - NACK - OK NACK can indicate that a slave is too busy to accept a transaction. These are a bit orthogonal to the need for a probe API. One option would be to add a new device type, say "smb", in addition to i2c. Then map the smb interface over the i2c internal implementation. This would create a dependency between /dev/smb and /dev/i2c. I don't know the eCos architecture well enough to know if this dependency can be managed properly with the CDL/Configuration, etc. But if it could, it would mean the i2c API could be left alone. Can someone comment on whether this could be done? Mike On Jan 21, 2013, at 10:29 AM, Tomas Frydrych <tf+lists.e...@r-finger.com> wrote: > On 21/01/13 17:09, Michael Jones wrote: >> I would also like to point out that SMBus 2.0 Section 5.5.1 documents >> Quick Command, which is composed as: >> >> S | Slave Address | Rd/Wr | A | P >> >> which has no data. If this were performed with i2c_transaction_tx, >> there is no way to know with the current API if the command was error >> free by using the return value. >> >> If the i2c API could return a negative integer, -1 could be used to >> indicate errors like NACK, arbitration loss, timeout, etc. > > I entirely agree that being able to report errors through the i2c API is > desirable, and it's one of the issues I run into when implementing the > Kinetis i2c driver. For example, there is no way to report when the bus > is busy, so the driver ends up just waiting for the bus to become free > -- this is not always desirable behaviour, as discussed in > http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397. > > Tomas
