From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11154 invoked by alias); 21 Jan 2013 19:53:45 -0000 Received: (qmail 11146 invoked by uid 22791); 21 Jan 2013 19:53:45 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from p02c11o142.mxlogic.net (HELO p02c11o142.mxlogic.net) (208.65.144.75) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jan 2013 19:53:40 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o142.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 3cc9df05.0.223503.00-278.504533.p02c11o142.mxlogic.net (envelope-from ); Mon, 21 Jan 2013 12:53:40 -0700 (MST) X-MXL-Hash: 50fd9cc46385e55d-48f29a8471feed3c8da20f3db759a25b7de4130b Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id 99381740AF; Mon, 21 Jan 2013 11:53:38 -0800 (PST) Received: from bengl-i7.engineering.linear.com (unknown [10.186.3.67]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 654D874004; Mon, 21 Jan 2013 11:53:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Potential I2C API Enhancement From: Michael Jones In-Reply-To: <50FD7AF1.2060805@r-finger.com> Date: Mon, 21 Jan 2013 19:53:00 -0000 Cc: ecos-devel@ecos.sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B8E915D-930A-4929-BD45-4FEC71DC8462@linear.com> <50FD7AF1.2060805@r-finger.com> To: Tomas Frydrych X-AnalysisOut: [v=2.0 cv=Z+pb6gtA c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=eMW94YfRZxUA:10 a=zn-vtc77AAAA:8 a=CCpqsmhAA] X-AnalysisOut: [AAA:8 a=IItMZiehpj8aCzKtHscA:9 a=CjuIK1q_8ugA:10 a=k803I5w] X-AnalysisOut: [SVZsA:10] X-MAIL-FROM: X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2013-01/txt/msg00003.txt.bz2 >From what I read, I believe the eCos strategy is to return status, not err= or, 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 wou= ld create a dependency between /dev/smb and /dev/i2c. I don't know the eCos architecture well enough to know if this dependency c= an 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 w= rote: > 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: >>=20 >> S | Slave Address | Rd/Wr | A | P >>=20 >> 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. >>=20 >> If the i2c API could return a negative integer, -1 could be used to >> indicate errors like NACK, arbitration loss, timeout, etc. >=20 > 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=3D1001397. >=20 > Tomas