From owner-cvs-all@FreeBSD.ORG Wed Oct 17 16:21:54 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1309C16A478; Wed, 17 Oct 2007 16:21:54 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9E05013C469; Wed, 17 Oct 2007 16:21:53 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l9HFqWZI059252; Wed, 17 Oct 2007 17:52:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l9HFqQCD081701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2007 17:52:26 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l9HFqPcx039004; Wed, 17 Oct 2007 17:52:25 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l9HFqPck039003; Wed, 17 Oct 2007 17:52:25 +0200 (CEST) (envelope-from ticso) Date: Wed, 17 Oct 2007 17:52:25 +0200 From: Bernd Walter To: Poul-Henning Kamp , Alexander Leidinger Message-ID: <20071017155225.GU17048@cicely12.cicely.de> References: <24712.1192384461@critter.freebsd.dk> <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net> <20071014172115.GA24318@freebie.xs4all.nl> <24712.1192384461@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net> <24712.1192384461@critter.freebsd.dk> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.139, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Wilko Bulte , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf files ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 16:21:54 -0000 On Sun, Oct 14, 2007 at 05:54:21PM +0000, Poul-Henning Kamp wrote: > And IFF we add such an amount of code to FreeBSD, we want to have it > properly integrate into our kernel, using our device discovery > and registration (newbus) and not probing random (i2c) busses willy > nilly. If it is really probing i2c busses then I fully agree with Poul and be strictly against this, because you _can't_ probe an i2c bus without risking major side effects. You can almost have a probing effect by doing 0-byte write access, but you still have to guess the device from the i2c address, which is not safe in many situations. For example in the embedded world we can have an i2c system with commonly used addresses reused for different purpose. Another example is that there are i2c switches used on alpha systems, such as the AS4100 - we never supported i2c on alpha, but this doesn't mean that other systems don't use it as well. Yet another example are the famous atmel eeprom chips used in some IBM notebooks which died on such an access. Then we have a bug on some i2c controllers (namely the twi in Atmel ARM9 chips), which makes it impossible to safely get the ack state on addressing. On Mon, Oct 15, 2007 at 08:15:07AM +0200, Alexander Leidinger wrote: > Quoting Poul-Henning Kamp (from Sun, 14 Oct 2007 > 17:54:21 +0000): > Could you please explain how you want to integrate devices with > newbus, which are only accessible via the i2c bus? Feel free to show > us example code for one of those of our drivers which access the i2c > bus, which already existed before this commit. For example the ds1672 driver (sys/dev/iicbus/ds1672.c) writen by sam: at91_twi0 iicbus0 [...] ds16720 at addr=0xd0 [...] The device name is a bit unfortunate - it consists of ds1672 beeing the driver name and 0 beeing the instance, but this is unrelated. The DS1672 is used as an RTC for some ARM boards, but it is written machine independend. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de