From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.active-venture.com ([67.228.131.205]:60710 "EHLO mail.active-venture.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933455Ab3BTBWT (ORCPT ); Tue, 19 Feb 2013 20:22:19 -0500 Date: Tue, 19 Feb 2013 17:22:49 -0800 From: Guenter Roeck To: Hartmut Knaack Cc: Lars-Peter Clausen , Jean Delvare , Jonathan Cameron , lm-sensors@lm-sensors.org, linux-iio@vger.kernel.org Subject: Re: [PATCH v2 1/4] hwmon: (adt7410) Don't re-read non-volatile registers Message-ID: <20130220012249.GA15948@roeck-us.net> References: <1361194739-16525-1-git-send-email-lars@metafoo.de> <51228D7A.8030608@gmx.de> <20130219010229.GA25124@roeck-us.net> <5123D4F5.5030001@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <5123D4F5.5030001@gmx.de> Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org On Tue, Feb 19, 2013 at 08:39:33PM +0100, Hartmut Knaack wrote: > Guenter Roeck schrieb: > > On Mon, Feb 18, 2013 at 09:22:18PM +0100, Hartmut Knaack wrote: > >> Lars-Peter Clausen schrieb: > >>> Currently each time the temperature register is read the driver also reads the > >>> threshold and hysteresis registers. This increases the amount of I2C traffic and > >>> time needed to read the temperature by a factor of ~5. Neither the threshold nor > >>> the hysteresis change on their own, so once we've read them, we should be able > >>> to just use the cached value of the registers. This patch modifies the code > >>> accordingly and only reads the threshold and hysteresis registers once during > >>> probe. > >> I have been thinking about this a lot, and I am concerned about data integrity. From what I know about I2C, there is no data integrity verification specified in the protocol. So, what the master sends is not necessarily what the slave receives (not to mention other devices on the bus, which could potentially mess around with the slaves, or even reset of the slave). Reading back just cached values makes it pretty hard to verify, if there are issues. I think it might be better to call a read-temperature function with a parameter that indicates, which temperature register is required. > > I am not concerned about that, unless there is a known issue with the chip > > and it is known to return bad data under some circumstances. I am doing the > > same in the PMBus drivers, since there are simply too many limit registers > > to read on some of the chips (there may literally be more than a hundred). > > That works fine most of the time; if it does not work, it is a chip problem, > > an i2c bus master problem, a hardware signal problem, or a combination of all. > > I actually think it is better if the problem is exposed by cached bad readings. > Could you please outline the last sentence? I'm having trouble to understand your intention with cached bad readings. Someone will actually notice it (hopefully while testing) and provide feedback. This gives a chance to fix the problem instead of having it linger around ... which would likely be the case if the problem is not persistent. Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Date: Wed, 20 Feb 2013 01:22:49 +0000 Subject: Re: [lm-sensors] [PATCH v2 1/4] hwmon: (adt7410) Don't re-read non-volatile registers Message-Id: <20130220012249.GA15948@roeck-us.net> List-Id: References: <1361194739-16525-1-git-send-email-lars@metafoo.de> <51228D7A.8030608@gmx.de> <20130219010229.GA25124@roeck-us.net> <5123D4F5.5030001@gmx.de> In-Reply-To: <5123D4F5.5030001@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hartmut Knaack Cc: Lars-Peter Clausen , Jean Delvare , Jonathan Cameron , lm-sensors@lm-sensors.org, linux-iio@vger.kernel.org On Tue, Feb 19, 2013 at 08:39:33PM +0100, Hartmut Knaack wrote: > Guenter Roeck schrieb: > > On Mon, Feb 18, 2013 at 09:22:18PM +0100, Hartmut Knaack wrote: > >> Lars-Peter Clausen schrieb: > >>> Currently each time the temperature register is read the driver also reads the > >>> threshold and hysteresis registers. This increases the amount of I2C traffic and > >>> time needed to read the temperature by a factor of ~5. Neither the threshold nor > >>> the hysteresis change on their own, so once we've read them, we should be able > >>> to just use the cached value of the registers. This patch modifies the code > >>> accordingly and only reads the threshold and hysteresis registers once during > >>> probe. > >> I have been thinking about this a lot, and I am concerned about data integrity. From what I know about I2C, there is no data integrity verification specified in the protocol. So, what the master sends is not necessarily what the slave receives (not to mention other devices on the bus, which could potentially mess around with the slaves, or even reset of the slave). Reading back just cached values makes it pretty hard to verify, if there are issues. I think it might be better to call a read-temperature function with a parameter that indicates, which temperature register is required. > > I am not concerned about that, unless there is a known issue with the chip > > and it is known to return bad data under some circumstances. I am doing the > > same in the PMBus drivers, since there are simply too many limit registers > > to read on some of the chips (there may literally be more than a hundred). > > That works fine most of the time; if it does not work, it is a chip problem, > > an i2c bus master problem, a hardware signal problem, or a combination of all. > > I actually think it is better if the problem is exposed by cached bad readings. > Could you please outline the last sentence? I'm having trouble to understand your intention with cached bad readings. Someone will actually notice it (hopefully while testing) and provide feedback. This gives a chance to fix the problem instead of having it linger around ... which would likely be the case if the problem is not persistent. Guenter _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors