lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 1 Dec 2015 13:06:24 -0800 From: Guenter Roeck <linux@...ck-us.net> To: Nishanth Menon <nm@...com> Cc: Jean Delvare <jdelvare@...e.com>, linux-kernel@...r.kernel.org, lm-sensors@...sensors.org, linux-omap@...r.kernel.org, beagleboard-x15@...glegroups.com, Eduardo Valentin <edubezval@...il.com> Subject: Re: [PATCH V2] hwmon: (tmp102) Force wait for conversion time for the first valid data On Tue, Dec 01, 2015 at 10:10:21AM -0600, Nishanth Menon wrote: > TMP102 works based on conversions done periodically. However, as per > the TMP102 data sheet[1] the first conversion is triggered immediately > after we program the configuration register. The temperature data > registers do not reflect proper data until the first conversion is > complete (in our case HZ/4). > > The driver currently sets the last_update to be jiffies - HZ, just > after the configuration is complete. When TMP102 driver registers > with the thermal framework, it immediately tries to read the sensor > temperature data. This takes place even before the conversion on the > TMP102 is complete and results in an invalid temperature read. > > Depending on the value read, this may cause thermal framework to > assume that a critical temperature event has occurred and attempts to > shutdown the system. > > Instead of causing an invalid mid-conversion value to be read > erroneously, we mark the last_update to be in-line with the current > jiffies. This allows the tmp102_update_device function to skip update > until the required conversion time is complete. Further, we ensure to > return -EAGAIN result instead of returning spurious temperature (such > as 0C) values to the caller to prevent any wrong decisions made with > such values. NOTE: this allows the read functions not to be blocking > and allows the callers to make the decision if they would like to > block or try again later. At least the current user(thermal) seems to > handle this by retrying later. > > A simpler alternative approach could be to sleep in the probe for the > duration required, but that will result in latency that is undesirable > and delay boot sequence un-necessarily. > > [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf > > Cc: Eduardo Valentin <edubezval@...il.com> > Reported-by: Aparna Balasubramanian <aparnab@...com> > Reported-by: Elvita Lobo <elvita@...com> > Reported-by: Yan Liu <yan-liu@...com> > Signed-off-by: Nishanth Menon <nm@...com> Applied. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists