Commit Graph

3120 Commits

Author SHA1 Message Date
Thomas Gleixner
90b4f30b6d hwmon: (coretemp) Handle frozen hotplug state correctly
The recent conversion to the hotplug state machine missed that the original
hotplug notifiers did not execute in the frozen state, which is used on
suspend on resume.

This does not matter on single socket machines, but on multi socket systems
this breaks when the device for a non-boot socket is removed when the last
CPU of that socket is brought offline. The device removal locks up the
machine hard w/o any debug output.

Prevent executing the hotplug callbacks when cpuhp_tasks_frozen is true.

Thanks to Tommi for providing debug information patiently while I failed to
spot the obvious.

Fixes: e00ca5df37 ("hwmon: (coretemp) Convert to hotplug state machine")
Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Tested-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-05-14 07:49:32 -07:00
Sebastian Reichel
09d9d82745 hwmon: (twl4030-madc) drop driver
This driver is no longer needed:

 * It has no mainline users
 * It has no DT support and OMAP is DT only
 * iio-hwmon can be used for madc, which also works with DT

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-30 11:45:31 -07:00
Rahul Bedarkar
39c382a310 hwmon: (tmp103) Use SIMPLE_DEV_PM_OPS helper macro
Replace ifdefs with SIMPLE_DEV_PM_OPS helper macro.

Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-24 06:30:41 -07:00
Chris Packham
4abdf38d20 hwmon: (adt7475) set start bit in probe
The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any
monitoring activities the STRT bit needs to be set. Logically this needs
to happen before any of the sensors are read so the probe() function
seems the best place for it.

[1] - https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-21 12:33:57 -07:00
Joe Schaack
bdaf9c40b2 hwmon: (ina209) Handled signed registers
The shunt voltage and current registers are signed 16-bit values so
handle them as such.

Signed-off-by: Joe Schaack <jschaack@xes-inc.com>
Reviewed-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-21 12:30:09 -07:00
Javier Martinez Canillas
a02c24a321 hwmon: (lm87) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-13 06:09:26 -07:00
Javier Martinez Canillas
0439bf71c3 hwmon: (lm87) Remove unused I2C devices driver_data
The I2C device ID entries set a .driver_data but this data is never
looked up by the driver. So don't set it and also remove the enum.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-13 06:07:34 -07:00
Jaghathiswari Rankappagounder Natarajan
2d7a548a3e drivers: hwmon: Support for ASPEED PWM/Fan tach
The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective
registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-10 13:12:18 -07:00
Mahoda Ratnayaka
67043d1853 hwmon: (lm87) Allow channel data to be set from dts file
Currently there is no method for setting the channel
value from the DTS file. When, the driver uses a dts
file to initialize the driver platform_data is not set.
As a result channel variable may not be set correctly.

Without the channel variable set correctly, some of the
sensors will not be initialized correctly. For example
temp3 sensor sysfs entries.

This implements the schema agreed with the device tree
binding document.

Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka@alliedtelesis.co.nz>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Sam Povilus
a8ddfea095 hwmon: (ads7828) Accept optional parameters from device tree
Adding the ability for the ads7828 and ads7830 to use device tree to
get optional parameters instead of using platform devices. This allows
people using custom boards to also use the ads7828 in a non-default manner.

Signed-off-by: Sam Povilus <kernel.development@povil.us>
[groeck: Fixed whitespace errors in ads7828.txt]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Pali Rohár
a4811b6cb4 hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list
It was reported that dell-smm-hwmon is working fine on Dell XPS 15 9560.

Link: http://www.spinics.net/lists/platform-driver-x86/msg10751.html
Reported-by: Vasile Dumitrescu <vasile.dumitrescu@undeva.eu>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Jean Delvare
5ba6bcbc33 hwmon: Constify str parameter of hwmon_ops->read_string
The read_string callback is supposed to retrieve a pointer to a
constant string.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
a1253027b7 hwmon: (tmp421) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
72fc64c68d hwmon: (tmp103) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
15390c610f hwmon: (tmp102) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
1c1a7b75bf hwmon: (stts751) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
02331c3a1a hwmon: (ucd9200) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
8881a19187 hwmon: (ucd9000) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
9e427083c3 hwmon: (max6697) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
5ada7055f2 hwmon: (lm95245) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
df8d57bf8a hwmon: (lm90) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
00c0f9d3ae hwmon: (lm85) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
e97a45f1b4 hwmon: (lm75) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
b25f663b91 hwmon: (lm63) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
bd0ddd4d08 hwmon: (ina2xx) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
0b7abe59be hwmon: (ina209) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
4e2496e419 hwmon: (adt7475) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
2d688f1413 hwmon: (ads7828) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
a140986fd0 hwmon: (ads1015) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
d593e665f3 hwmon: (adc128d818) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Javier Martinez Canillas
72edf311ed hwmon: (ad7414) Add OF device ID table
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Katsumi Sato
0d0235301b hwmon: (w83627ehf) Use request_muxed_region
Serialize access to the hardware by using "request_muxed_region".
Call to this macro will hold off the requestor if the resource is
currently busy. "superio_enter" will return an error if call to
"request_muxed_region" fails.

Signed-off-by: Katsumi Sato <sato@toshiba-tops.co.jp>
Signed-off-by: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02 07:01:53 -07:00
Shikhar Dogra
6faecba0b3 driver: (adm1275) set the m,b and R coefficients correctly for power
Seems like coefficient values for m, b and R under power have been
put in the wrong order. Rearranging them properly to get correct
values of coefficients for power.

For specs, please refer to table 7 (page 35) on
http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.pdf

Fixes: 904b296f30 ("hwmon: (adm1275) Introduce configuration data structure for coeffcients")
Signed-off-by: Shikhar Dogra <shidogra@cisco.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-27 19:43:36 -07:00
Arnd Bergmann
a2125d0244 hwmon: (asus_atk0110) fix uninitialized data access
The latest gcc-7 snapshot adds a warning to point out that when
atk_read_value_old or atk_read_value_new fails, we copy
uninitialized data into sensor->cached_value:

drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Adding an error check avoids this. All versions of the driver
are affected.

Fixes: 2c03d07ad5 ("hwmon: Add Asus ATK0110 support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-23 12:01:57 -07:00
Guenter Roeck
8358378b22 hwmon: (it87) Avoid registering the same chip on both SIO addresses
IT8705F is known to respond on both SIO addresses. Registering it twice
may result in system lockups.

Reported-by: Russell King <linux@armlinux.org.uk>
Fixes: e84bd9535e ("hwmon: (it87) Add support for second Super-IO chip")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-22 00:18:21 -07:00
Alex Hemme
dd7406dd33 hwmon: (max31790) Set correct PWM value
Traced fans not spinning to incorrect PWM value being written.
The passed in value was written instead of the calulated value.

Fixes: 54187ff9d7 ("hwmon: (max31790) Convert to use new hwmon registration API")
Signed-off-by: Alex Hemme <ahemme@cisco.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-22 00:18:20 -07:00
Masahiro Yamada
4091fb95b5 scripts/spelling.txt: add "followings" pattern and fix typo instances
Fix typos and add the following to the scripts/spelling.txt:

  followings||following

While we are here, add a missing colon in the boilerplate in DT binding
documents.  The "you SoC" in allwinner,sunxi-pinctrl.txt was fixed as
well.

I reworded "as the followings:" to "as follows:" for
drivers/usb/gadget/udc/renesas_usb3.c.

Link: http://lkml.kernel.org/r/1481573103-11329-32-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-27 18:43:47 -08:00
Marco Franchi
2f1736ff06 hwmon: (sht15) Add device tree support
Allow the driver to work with device tree support.

Based on initial patch submission from Peter Fox.

Tested on a imx7d-sdb board connected to a SHT15 board via Mikro Bus.

Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-16 06:49:05 -08:00
Guenter Roeck
e531ffc0ff hwmon: (it87) Add support for IT8792E
The chip is similar to IT8732E, but supports only three fans
and pwm outputs instead of four (the driver currently does not
support the 4th fan and pwm output of IT8732E).

Note that the chip ID is 0x8733, not 0x8792 as one would expect.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
Guenter Roeck
4c7b8ca1ae hwmon: (it87) Do not overwrite bit 2..6 of pwm control registers
In IT8620E, after setting pwm control to manual, it was observed that
pwm values for fan 4..6 have reversed results (writing 0 results in fans
running at full speed, writing 255 results in fans turned off).

With the new PWM control, pwm polarity for pwm control 4..6 is specified
in its pwm control registers. Those registers are overwritten when setting
the pwm mode or the temperature mapping. Do not touch bit 2..6 of pwm
control registers on register writes to fix the problem.

Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
Guenter Roeck
d66777caa5 hwmon: (it87) Fix pwm4 detection for IT8620 and IT8628
pwm4 is enabled if bit 2 of GPIO control register 4 is disabled,
not when it is enabled. Since the check is for the skip condition,
it is reversed. This applies to both IT8620 and IT8628.

Fixes: 36c4d98a78 ("hwmon: (it87) Add support for all pwm channels ...")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
Guenter Roeck
82dbe987b7 hwmon: (it87) Ensure that pwm control cache is current before updating values
If sensor attributes were never read, the pwm control data has not been
initiialized, which can cause wrong driver behavior. Ensure that cached
data is current before acting on it.

Cc: stable@vger.kernel.org # 4.4+
Reported-by: Kevin Folz <kfolz@evertz.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
Guenter Roeck
638c1c07f9 hwmon: (it87) Improve IT8622 support
Configuration registers on ITE8622 are different to 8620 and 8628 and
require special handling. Also, the chip supports up to 5 pwm controls.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
Guenter Roeck
8af1abae72 hwmon: (it87) Add support for IT8622E
IT8622E is similar to IT8620E, but only supports five pwm controls and
five fan tachometers.

Originally-from: Kevin Folz <kfolz@evertz.com>.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
Guenter Roeck
a9eebd4f28 hwmon: (it87) Add feature flag indicating that VIN3 is connected to 5V
On IT8622E and IT8628E, VIN3 is expected to be connected to +5V.
Add feature flag and reflect in input label.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-10 21:35:08 -08:00
andrea.merello
7f07ec0fa1 hwmon: new driver for ST stts751 thermal sensor
This patch adds a HWMON driver for ST Microelectronics STTS751
temperature sensors.

Thanks-to: LABBE Corentin [for suggestions]
Thanks-to: Guenter Roeck [for suggestion and discussions]
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Cc: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-02-03 05:32:59 -08:00
Guenter Roeck
319fe15988 hwmon: Register thermal zone only if 'dev' parameter was provided
Rgistering a thermal zone uses devm_kzalloc(), which requires
a pointer to the parent device.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-01-31 03:56:08 -08:00
Guenter Roeck
74d3b64197 hwmon: Relax name attribute validation for new APIs
While invalid name attributes are really not desirable and do mess up
libsensors, enforcing valid names has the detrimental effect of driving
users away from using the new hardware monitoring API, especially those
registering name attributes violating the ABI restrictions. Another
undesirable side effect is that this violation and the resulting error
may only be discovered some time after a conversion to the new API,
which in turn may trigger a revert of that conversion.

To solve the problem, relax validation and only issue a warning instead
of returning an error if a name attribute violating the ABI is provided.
This lets callers continue to provide invalid name attributes while
notifying them about it.

Many thanks are due to Dmitry Torokhov for the idea.

Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-01-31 03:52:15 -08:00
Guenter Roeck
8353863a52 hwmon: Make name attribute mandatory for new APIs
It does not make sense to use one of the the new APIs when not
even providing a name attribute. Make it mandatory.

Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-01-25 06:14:26 -08:00
Florian Fainelli
68f0c8c923 hwmon: (lm70) Add support for TI TMP122/124
Add support for Texas Instruments TMP122/124 which are nearly identical to
their TMP121/123 except that they also support programmable temperature
thresholds.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-01-21 12:26:38 -08:00