kernel/linux.git/drivers/hwmon/tmp102.c, branch v4.11.5

hwmon: (tmp102) Convert to use new hwmon registration API

2016-09-09T04:34:17+00:00

Simplify code and reduce code size by using the new hwmon registration API. Signed-off-by: Guenter Roeck

hwmon: (tmp102) Improve error handling

2016-07-31T22:02:51+00:00

Use devm_add_action_or_reset() instead of devm_add_action(), and check its return code. Signed-off-by: Guenter Roeck

hwmon: (tmp102) Convert to use regmap, and drop local cache

2016-07-12T21:24:14+00:00

By converting the driver to regmap, we can use regmap to cache non-volatile registers. Stop caching the temperature register; while potentially reading it more often can result in reading it more often than necessary, this is offset by the gain due to not re-reading the limit registers. A positive side effect of this change is that limit registers can now be read and updated before the first temperature conversion is complete. Acked-by: Nishanth Menon Signed-off-by: Guenter Roeck

hwmon: (tmp102) Rework chip configuration

2016-07-12T21:24:09+00:00

So far the chip was forced into polarity 0, even if it was preconfigured differently. Do not touch the polarity when configuring the chip. Also, the configuration register was read beack to check if the configuration 'sticks'. Ultimately, that is similar to checking if the chip is a tmp102 in the first place. Checking if a write into the configuration register was successful is really not the way to do it, and quite risky if the chip is not a tmp102, so drop that check. Instead, verify if the configuration register has unexpected bits set before writing into it. Acked-by: Nishanth Menon Signed-off-by: Guenter Roeck

hwmon: (tmp102) Improve handling of initial read delay

2016-07-12T21:23:57+00:00

If the chip was in shutdown mode when the driver was loaded, the first conversion is ready no more than 35 milli-seconds after the chip was taken out of shutdown. The driver delay was so far set to 333 ms (HZ / 3), which is much higher than the maximum time needed by the chip. Reduce the time to 35 milli-seconds. Introduce a 'valid' flag to ensure that sensor data is actually read even if requested less than 333 ms after the driver was loaded. Acked-by: Nishanth Menon Signed-off-by: Guenter Roeck

hwmon: (tmp102) Drop FSF address

2016-06-28T01:58:31+00:00

The FSF address can change, so drop it from the driver. Acked-by: Nishanth Menon Signed-off-by: Guenter Roeck

hwmon: (tmp102) Use devm_add_action to register cleanup function

2016-06-28T01:58:31+00:00

By registering a cleanup function with devm_add_action(), we can simplify the error path in the probe function and drop the remove function entirely. Acked-by: Nishanth Menon Signed-off-by: Guenter Roeck

hwmon: convert tmp102 to use devm_thermal_zone_of_sensor_register

2016-05-17T14:28:25+00:00

This changes the driver to use the devm_ version of thermal_zone_of_sensor_register and cleans up the local points and unregister calls. Cc: Jean Delvare Cc: Guenter Roeck Cc: lm-sensors@lm-sensors.org Cc: linux-kernel@vger.kernel.org Acked-by: Guenter Roeck Signed-off-by: Eduardo Valentin

hwmon: (tmp102) Force wait for conversion time for the first valid data

2015-12-10T16:14:22+00:00

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 Reported-by: Aparna Balasubramanian Reported-by: Elvita Lobo Reported-by: Yan Liu Signed-off-by: Nishanth Menon Signed-off-by: Guenter Roeck

thermal: consistently use int for temperatures

2015-08-03T15:15:50+00:00

The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer Acked-by: Geert Uytterhoeven Reviewed-by: Jean Delvare Reviewed-by: Lukasz Majewski Reviewed-by: Darren Hart Reviewed-by: Heiko Stuebner Reviewed-by: Peter Feuerer Cc: Punit Agrawal Cc: Zhang Rui Cc: Eduardo Valentin Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Jean Delvare Cc: Peter Feuerer Cc: Heiko Stuebner Cc: Lukasz Majewski Cc: Stephen Warren Cc: Thierry Reding Cc: linux-acpi@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: Guenter Roeck Cc: Rafael J. Wysocki Cc: Maxime Ripard Cc: Darren Hart Cc: lm-sensors@lm-sensors.org Signed-off-by: Zhang Rui