Hi Guennadi,

On Wed, 3 Dec 2008 13:37:13 +0100 (CET), Guennadi Liakhovetski wrote:
> on an i.MX31-based system I observe a strange effect:
> 
> cat /sys/class/i2c-adapter/.../eeprom > /tmp/e1
> rmmod <adapter-driver>
> modprobe <adapter-driver>
> cat /sys/class/i2c-adapter/.../eeprom > /tmp/e2
> 
> after which the first 0x40 bytes in e2 are zero. The rest is correct - as 
> in e1. To recover I have to
> 
> rmmod eeprom
> i2cdetect ... # incluging eeprom addresses
> modprobe eeprom

How repeatable is this? I do not observe this behavior with i2c-I801 +
eeprom here.

Anything in the kernel logs?

To recover, isn't it enough to wait for 5 minutes (giving the eeprom
driver's cache the time to expire)? If so, I would suspect an
initialization error in your adapter driver (maybe it takes some time
to the hardware to fully initialize, or there's an initialization step
missing in the driver.)

Note that the eeprom driver can use both I2C block read transactions
and SMBus word read transactions. The former is used if available
because it is faster. You may force the eeprom driver to switch to
SMBus word reads by removing I2C_FUNC_SMBUS_READ_I2C_BLOCK from the bus
driver's functionality bitfield. It might help you pinpoint the exact
problem.

Maybe an even easier way would be to use i2c-dev + i2cdump instead of
the eeprom driver. With i2cdump you will have full control on the
transaction type that is used to read the EEPROM data.

> I would suspect a software bug, but I get this with two alternative 
> adapter drivers (mxc and imx - see my recent post to the list), and on a 
> laptop with 2.6.26 I don't get this. The kernel on i.MX31 is a pretty 
> fresh linux-next. Does this look like a hardware "feature"? Or do we have 
> a regression?

Does this happen as root, or as a regular user, or both? FWIW, the
eeprom driver handles EEPROMs by blocks of 32 bytes, and for some
EEPROM types, some fields are zeroed for non-root users, for privacy
purposes. I doubt this is related to your problem, but let's still keep
it in mind.

Do you use both the at24 and eeprom drivers on your system?

If you think this is a regression then please figure out the last
kernel which behaved properly and the first kernel which started
failing.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to