Hi Jean, On Fri, Mar 18, 2011 at 07:04:24AM -0400, Jean Delvare wrote: > On Fri, 18 Mar 2011 03:28:51 -0700, Guenter Roeck wrote: > > On Fri, Mar 18, 2011 at 03:57:58AM -0400, Jean Delvare wrote: > > > If memory serves, at least the DS1631 supports better resolution than > > > the ds1621 driver currently offers. So claiming that it is supported > > > isn't completely exact. What the driver supports is really the DS1621 > > > and the other chips happen to emulate it. > > > > > > It should really not be difficult to add proper support for all chips, > > > I just could never find the time to look into it. The chips I have here > > > are: one DS1621, two DS1631+ and two DS1624+. > > > > > Sure, can do that. What would you suggest ? Pick the best available resolution ? > > By default, sure, why not? If anybody needs specific configuration, > they can add platform data. > > > Also, if we do that, I would use i2c_device_id to select the part, and not try > > to auto-detect it. Another option would be to play with the configuration register > > and try detecting chip types this way (ie set bit 3,4 and observe the result). > > You aren't allowed to write to the device in the detect function. > > > Not sure if that is a good idea, though. Any thoughts on this ? > > As I said before, I would blast detection code completely, and rely on > explicit instantiation for all devices (i.e. trust i2c_device_id). > Ok, sounds like a plan. Thanks, Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
