From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22772 invoked by alias); 21 Jan 2013 17:09:39 -0000 Received: (qmail 22750 invoked by uid 22791); 21 Jan 2013 17:09:37 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from p02c12o148.mxlogic.net (HELO p02c12o148.mxlogic.net) (208.65.145.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jan 2013 17:09:32 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o148.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id b467df05.0.128094.00-380.276266.p02c12o148.mxlogic.net (envelope-from ); Mon, 21 Jan 2013 10:09:32 -0700 (MST) X-MXL-Hash: 50fd764c3a5f5248-b217d233daab2ee308abd0a265c126bbf7e97b58 Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id 2116C740B3 for ; Mon, 21 Jan 2013 09:09:31 -0800 (PST) Received: from [10.186.2.83] (unknown [10.186.2.83]) by smtpauth1.linear.com (Postfix) with ESMTPSA id EFBB6740B1 for ; Mon, 21 Jan 2013 09:09:30 -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: <8B8E915D-930A-4929-BD45-4FEC71DC8462@linear.com> Date: Mon, 21 Jan 2013 17:09:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B8E915D-930A-4929-BD45-4FEC71DC8462@linear.com> To: ecos-devel@ecos.sourceware.org X-AnalysisOut: [v=2.0 cv=PNu4D4WC 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=PRNO-_cfXZjkys2XuNIA:9 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=xLpt9-x9cSEA:10 a=pDFtZQNJeizmDonW:21 a=7] X-AnalysisOut: [dfG7e4UHVzVgiVi:21] 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/msg00001.txt.bz2 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 indicat= e errors like NACK, arbitration loss, timeout, etc. Mike On Jan 21, 2013, at 8:08 AM, Michael Jones wrote: > While working with the I2C interface using Kinetis to write a SMBus/PMBus= layer over it, I could not implement a probe. >=20 > PMBus developers typically probe the bus looking for slaves by sending an= address and using ACK/NACK to determine presence. >=20 > The only way one can probe with the current I2C API is to send at least o= ne data byte, so that the return is an indicator of success or failure. How= ever, this is a dangerous way to probe, because it might have side effects. >=20 > Sometimes people probe with Addr+Read, but most use Addr+Write, because t= hat avoids a potential ARA response. >=20 > I am looking for ideas how best to deal with this problem. Potential solu= tions: >=20 > 1) Use a target specific API > 2) Add to existing API, like i2c_slave_present(... > 3) Add new API/Package >=20 > In my opinion, choice 2 would be the best because it is target independen= t, and least confusing. >=20 > The practical impact is people developing SMBus/PMBus tend to use Cortex = M. There are a small number of targets (5) in the dev tree. So perhaps it i= s still possible to add to the I2C API? >=20 > Thoughts? >=20 > Mike >=20 >=20