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 ...

[Bernd Walter]

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 <phk at phk.freebsd.dk> (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 at bwct.de           info at bwct.de            support at fizon.de