Jason Thorpe <[email protected]> writes: [snip]
> NOW. i2c_scan defaults to doing a “quick write”, HOWEVER, that code has the > comment about the “quick write” method corrupting the EEPROM on Thinkpads. > But it also has a comment about the “receive byte” method possibly causing > problems with write-only devices? > > So, I’m a little perplexed about what to do… perhaps the “receive byte” > method is the best for now? > > [snip] Unfortunate behavior. Looking back over the sensor driver I worked on, it appears that I always read something to determine if the device was actually there. I note that the gpioow, a onewire bus, may have simular ghost issues as i2c: [ 7.496848] gpioow1 at gpio0 pins 25: can't map pins [ 7.516852] gpioow2 at gpio0 pins 25: can't map pins [ 7.536858] gpioow3 at gpio0 pins 25: can't map pins There is only one device present, and it is wired down in the config file to a particular gpio parent and pin, but it manages to ghost 3 times anyway. [Unrelated topic, gpioow is a module, onewire is a module, but owtemp isn't, so you really end up not being able to modload the them into place with the "generic" RPI kernel, hence a config file] I wonder if the i2c bus attachments should have the option of being treated like gpio attachements with a new command... probably a lot of work: iicctl iic2 attach dstrc 0x68 3231 > -- thorpej -- Brad Spencer - [email protected] - KC8VKS - http://anduin.eldar.org
