On Tue, Aug 30, 2011 at 11:26:05AM -0400, Jean Delvare wrote: > On Tue, 30 Aug 2011 07:26:44 -0700, Guenter Roeck wrote: > > On Tue, Aug 30, 2011 at 03:14:12AM -0400, Jean Delvare wrote: > > > On Mon, 29 Aug 2011 22:57:56 -0700, Guenter Roeck wrote: > > > > The chips supported by the max16065 driver should not be accessed using direct > > > > i2ctools commands. Add warning to driver documentation to alert users. > > > > > > > > Signed-off-by: Guenter Roeck <guenter.roeck@xxxxxxxxxxxx> > > > > --- > > > > RFC: Do we want this kind of warning in driver documentation ? > > > > > > Sure, this can't hurt. Maybe we could add a section in i2c-tools' > > > documentation as well, listing the dangerous chips, starting with this > > > one? i2cdetect already has a note about the AT24RF08 for historical > > > reasons, I wouldn't mind documenting the "dangerous" chips more > > > prominently. Hopefully the list will stay short. > > > > > Hopefully yes. Many of the PMBus chips are potentially affected, though. > > They typically have a means to protect settings from overwrite, but if that > > is not enabled, one can be in hot water. Worst I have seen so far was > > to execute i2cdump on an eval board and it lost its configuration :(. > > You are lucky. Back in 2002, worse a few lm-sensors users saw was their > shiny new Thinkpad laptop tuned into a brick by sensors-detect (not > even i2c-tools) due to what ended up being a state machine bug in the > AT24RF08.) > > Speaking of this... At which I2C addresses to these PMBus devices live? > MAX16065/66 in particular but also other chips with similar problems. MAX16065/66 is not a PMBus device ... by default, it resides at 0x50..0x53 (possibly the worst address space available for such a device). That address can be overwritten by software to any valid address. It does not have an ID register, so it can not be auto-detected. PMBus devices can unfortunately be at any valid address. Many chips use a set of resistors to set the address. Even those not using resistors can often be programmed by SW to any address. > If these are addresses sensors-detect is probing, then it's only a > matter of time before we get a report from a user hitting the problem. > Might well be. Most don't react too badly on reads, though. I had the problem specifically with the Intersil chips. On those, the byte reads done by i2cdump on write-only command registers are accepted as write commands. This causes the chip configuration to be lost unless all writes are disabled/secured. Which was not the case on my eval board. Oops ... Turning PMBus chips into bricks is actually quite simple - I managed to do it with several chips from multiple vendors. Since one has to do that on purpose or by being careless (as in my case ;), so I would not count that against the chips. > Probably it's about time to let the kernel block user-space probing of > specific I2C buses. Sounds like a good idea. This is one reason why we don't set I2C_CLASS_HWMON in our internal I2C adapter drivers. Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
