From owner-cvs-all@FreeBSD.ORG Thu Oct 18 09:36:59 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 49ED416A417; Thu, 18 Oct 2007 09:36:59 +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 E152713C474; Thu, 18 Oct 2007 09:36:58 +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 l9I9aXTJ088590; Thu, 18 Oct 2007 11:36:33 +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 l9I9aRuD090954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 11:36:27 +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 l9I9aQ99041869; Thu, 18 Oct 2007 11:36:26 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l9I9aQPO041868; Thu, 18 Oct 2007 11:36:26 +0200 (CEST) (envelope-from ticso) Date: Thu, 18 Oct 2007 11:36:26 +0200 From: Bernd Walter To: Alexander Leidinger Message-ID: <20071018093625.GA17048@cicely12.cicely.de> References: <24712.1192384461@critter.freebsd.dk> <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net> <20071014172115.GA24318@freebie.xs4all.nl> <24712.1192384461@critter.freebsd.dk> <20071017155225.GU17048@cicely12.cicely.de> <20071018100442.a4i5vidp1c0kg8gg@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071018100442.a4i5vidp1c0kg8gg@webmail.leidinger.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.166, 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: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Bernd Walter , Poul-Henning Kamp , Wilko Bulte , ticso@cicely.de 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: Thu, 18 Oct 2007 09:36:59 -0000 On Thu, Oct 18, 2007 at 10:04:42AM +0200, Alexander Leidinger wrote: > Quoting Bernd Walter (from Wed, 17 Oct 2007 > 17:52:25 +0200): > > >For example in the embedded world we can have an i2c system with > >commonly used addresses reused for different purpose. > > Not talking about the specific part at hand (probing i2c), but > regarding embedded devices: there you craft your kernel by hand anyway > after deciding what you need and what not. Not in every case. I've attached additional i2c components to many boards when they had headers and just used them from userland. > >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. > > Do you know about amd64/i386 systems (where the code you talk about is > used) where this is the case? If not, do you think that with the > vendor mentality of saving every fraction of a cent it is likely, that > they use i2c switches? No - I don't know any, but it is not unlikely that some big systems with lots of hotplugable PCI slots use i2c busses to switch power on them and in that case they either need many busses or switches. We don't support hotplugable PCI beside from cardbus right now, but who knows. Also Digital didn't used switches to spare a few cent, the i2c was integrated into the chipset and adding multiple channel didn't work easily. > >Yet another example are the famous atmel eeprom chips used in some IBM > >notebooks which died on such an access. > > That's bad. Can they be affected with by the code in question? I don't know the code yet, but since zero byte writes are the only way to get something similar to probing I assume yes. > >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. > > Are you talking about embedded stuff, or about stuff which is used on > i386/amd64? No - I'm talking about ARM in this special case. Another fact, which I just remember, is that the controller can't do 0 byte acces anyway, so you can't do probing at all, even without the ack bug. > >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. > > Thanks for this example. Do you know enough about this code that you > can help further if Constantine has questions regarding it and Sam has > no time to answer? I will try to help you with questions, but I just know the driver not the attachment framework. IIRC Warner Losh did the hint based attachment framework, so he will likely be able to help you about this. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de