From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4295 invoked by alias); 21 Jan 2013 17:29:31 -0000 Received: (qmail 4282 invoked by uid 22791); 21 Jan 2013 17:29:29 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from r-finger.com (HELO r-finger.com) (178.79.160.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jan 2013 17:29:23 +0000 Received: from [192.168.0.2] (host86-137-82-188.range86-137.btcentralplus.com [86.137.82.188]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by r-finger.com (Postfix) with ESMTPSA id 5D4CA9BF8 for ; Mon, 21 Jan 2013 17:29:22 +0000 (GMT) Message-ID: <50FD7AF1.2060805@r-finger.com> Date: Mon, 21 Jan 2013 17:29:00 -0000 From: Tomas Frydrych User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: Potential I2C API Enhancement References: <8B8E915D-930A-4929-BD45-4FEC71DC8462@linear.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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/msg00002.txt.bz2 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