attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
10055 7032 0 17087 42bf drivers/hwmon/adt7475.o
File size After adding 'const':
text data bss dec hex filename
10567 6520 0 17087 42bf drivers/hwmon/adt7475.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
2304 2936 0 5240 1478 drivers/hwmon/adc128d818.o
File size After adding 'const':
text data bss dec hex filename
2344 2872 0 5216 1460 drivers/hwmon/adc128d818.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
6161 9400 0 15561 3cc9 drivers/hwmon/nct7802.o
File size After adding 'const':
text data bss dec hex filename
6465 9080 0 15545 3cb9 drivers/hwmon/nct7802.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
6655 304 0 6959 1b2f drivers/hwmon/hwmon.o
File size After adding 'const':
text data bss dec hex filename
6703 240 0 6943 1b1f drivers/hwmon/hwmon.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If stts751 hw by some reason reports conversion rate bigger then 9:
ret = i2c_smbus_read_byte_data(priv->client, STTS751_REG_RATE);
then dereferencing stts751_intervals[priv->interval] leads to buffer
overrun.
The patch adds sanity check for value stored on chip.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 7f07ec0fa1 ("hwmon: new driver for ST stts751 thermal sensor")
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
sysfs store functions should return the number of bytes written.
Returning zero results in an endless loop.
Fixes: 08426eda58 ("hwmon: Add driver for FTS BMC chip "Teutates"")
Signed-off-by: Thilo Cestonaro <thilo.cestonaro@ts.fujitsu.com>
[groeck: Clean up documentation change and description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
gcc 7.1 complains that the driver uses sprintf() and thus does not validate
the length of output buffers.
drivers/hwmon/applesmc.c: In function 'applesmc_show_fan_position':
drivers/hwmon/applesmc.c:82:21: warning:
'%d' directive writing between 1 and 5 bytes into a region of size 4
Fix the problem by using scnprintf() instead of sprintf() throughout the
driver. Also explicitly limit the number of supported fans to avoid actual
buffer overruns and thus invalid keys.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The reference driver polled but mentioned it was possible to sleep
for a computed period to know when it's ready to read. However, polling
with minimal sleeps is quick and works. This also improves responsiveness
from the driver.
Testing: tested on ast2400 on quanta-q71l
Signed-off-by: Patrick Venture <venture@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reduce the fan_tach period such that the fan controller uses a shorter
period to measure the rpm.
The original period of 0x1000 was chosen as a conversative value from the
reference implementation. Through experimentation on the quanta-q71l
board, I was able to drive the number down which ultimately reduced the
time the controller would use to determine the fan_tach. This value was
recently tested and accepted downstream on the IBM Zaius board which uses
the ast2500.
Future work: It may be worthwhile as this is a tunable parameter to the
system, to allow overriding it through the device tree.
Testing: Tested on an ast2400 sitting on a quanta-q71l and ast2500 on
power9.
Signed-off-by: Patrick Venture <venture@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This patch exports current(A) sensors in inband sensors copied to
main memory by OCC.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Today, the type of a PowerNV sensor system is determined with the
"compatible" property for legacy Firmwares and with the "sensor-type"
for newer ones. The same array of strings is used for both to do the
matching and this raises some issue to introduce new sensor types.
Let's introduce two different arrays (legacy and current) to make
things easier for new sensor types.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The implementation details for SCPI seems to suggest that the sensor
readings must be reported by SCP using a well defined scale
(millidegree Celsius for temperature, millivolts for voltage,
milliamperes for current, microwatts for power and microjoules for
energy).
This is also important for the interaction with other subsystems: for
example both the thermal sub-system and the hwmon sysfs interface expect
the temperature expressed in millidegree Celsius.
Unfortunately since this behaviour is dependent on the firmware
implementation there are cases where the sensor readings are reported
using a different scale. For example in the Amlogic SoCs the
temperature is reported in degree and not millidegree Celsius.
To take into account this discrepancy and fixup the values reported by
SCP a new compatible 'amlogic,meson-gxbb-scpi-sensors' is introduced and
used in this patch by the scpi-hwmon driver to convert the sensor
readings to the expected scale.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The aspeed-pwm-tacho controller supports measuring the fan tach by using
leading, falling, or both edges. This change allows the driver to
support either of the three configurations and will appropriately modify
the returned tach data.
If the controller is measuring with both edges it can return a value more
quickly to the requestor. This version of the driver should still take ~1s
to return with an RPM value per fan, however, it can be tuned faster with
double edge counting enabled than without.
I tested this and found the number returned matched what I expected.
Signed-off-by: Patrick Venture <venture@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
OCC provides historical minimum and maximum value for the sensor
readings. This patch exports them as highest and lowest attributes
for the inband sensors copied by OCC to main memory.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When enabled temperature smoothing allows ramping the fan speed over a
configurable period of time instead of jumping to the new speed
instantaneously.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Systems using 4-wire fans usually require high frequency (22.5kHz)
output on the pwm. Add 22500 as a valid option in the pwmfreq_table. In
high frequency mode the low-order bit are ignored so they can safely be
set to 0.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
By default adt7475 will stop the fans (pwm duty cycle 0%) when the
temperature drops past Tmin - hysteresis. Some systems want to keep the
fans moving even when the temperature drops so add new sysfs attributes
that configure the enhanced acoustics min 1-3 which allows the fans to
run at the minimum configure pwm duty cycle.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The adt7475 has had find_nearest() since it's creation in 2009. Since
then find_closest() has been introduced and several drivers have been
updated to use it. Update the adt7475 to use find_closest() and remove
the now unused find_nearest().
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
IR35221 is a Digital DC-DC Multiphase Converter
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
[groeck: Preserve alphabetic order in Kconfig;
add missing break statements (from Dan Carpenter);
add missing error checks]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Recent chips support multiple pins for fan speed inputs and fan control
outputs. Examine all of them to determine supported fan controls.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Instead of checking if a temperature source has a label, use a bit mask
to determine if a temperature source is valid for a given chip.
This simplifies the code and, if necessary, lets us support chips with
unknown or incomplete labels.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Make fan and pwm names in sysfs start with index 1 in accordance to
Documentation/hwmon/sysfs-interface conventions.
Current implementation starts with index 0, making tools such as
sensors(1) skip the first fan.
Signed-off-by: Stefan Schaeckeler <sschaeck@cisco.com>
Fixes: 2d7a548a3e ("drivers: hwmon: Support for ASPEED PWM/Fan tach")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Call of_node_put() on a node claimed with of_node_get() or by any other
means such as for_each_child_of_node().
Signed-off-by: Stefan Schaeckeler <sschaeck@cisco.com>
Fixes: 2d7a548a3e ("drivers: hwmon: Support for ASPEED PWM/Fan tach")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When the controller fails to provide an RPM reading within the alloted
time; the driver returns -ETIMEDOUT and no file contents.
Signed-off-by: Patrick Venture <venture@google.com>
Fixes: 2d7a548a3e ("drivers: hwmon: Support for ASPEED PWM/Fan tach")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver uses regmap and thus has to select it to avoid build
errors such as the following.
drivers/hwmon/aspeed-pwm-tacho.c:337:21: error: variable
'aspeed_pwm_tacho_regmap_config' has initializer but incomplete type
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Acked-by: Joel Stanley <joel@jms.id.au>
Fixes: 2d7a548a3e ("drivers: hwmon: Support for ASPEED PWM/Fan tach")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
We have a device reference, utilize it instead of pr_warn().
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The I2C core always reports a MODALIAS of the form i2c:<foo> even if the
device was registered via OF, this means that exporting the OF device ID
table device aliases in the module is not needed. But in order to change
how the core reports modaliases to user-space, it's better to export it.
Before this patch:
$ modinfo drivers/hwmon/ltc4151.ko | grep alias
alias: i2c:ltc4151
After this patch:
$ modinfo drivers/hwmon/ltc4151.ko | grep alias
alias: i2c:ltc4151
alias: of:N*T*Clltc,ltc4151C*
alias: of:N*T*Clltc,ltc4151
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Preserve chip operation mode if no mode is specified via devicetree. This
enables operation when chip configuration is done by BIOS/ROMMON.
Signed-off-by: Alexander Koch <mail@alexanderkoch.net>
Acked-by: Michael Hornung <mhornung.linux@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for operation modes 1-3 of the ADC128D818 (see datasheet sec.
8.4.1). These differ in the number and type of the available input signals,
requiring the driver to selectively hide sysfs nodes according to the
operation mode configured via devicetree.
Signed-off-by: Alexander Koch <mail@alexanderkoch.net>
Acked-by: Michael Hornung <mhornung.linux@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Implement operation mode selection using the optional 'ti,mode' devicetree
property (see [1]). The ADC128D818 supports four operation modes differing
in the number and type of input readings (see datasheet, sec. 8.4.1), of
which mode 0 is the default.
We only add handling of the 'ti,mode' property here, the driver still
supports nothing else than the default mode 0.
[1] Documentation/devicetree/bindings/hwmon/adc128d818.txt
Signed-off-by: Alexander Koch <mail@alexanderkoch.net>
Acked-by: Michael Hornung <mhornung.linux@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
tmp401 separately read/wrote high and low bytes of temperature values while
the hardware supports reading/writing those values in one operation. Driver
has been modified to use word operations where possible.
Tested with a tmp432 sensor on a mips64 platform.
Signed-off-by: Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very large values are
written and the fan divider is larger than 1.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Writes into limit attributes can overflow due to additions and
multiplications with unchecked parameters.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Writes into voltage limit, temperature limit, temperature hysteresis,
and temperature zone attributes can overflow due to unclamped parameters
to multiplications, additions, and subtractions.
Cc: Juerg Haefliger <juergh@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Expose the per-chip unique identifier so it can be used to identify the
sensor producing the measurements.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RW for read/write attributes. This simplifies the source
code, improves readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RO for read only attributes and DEVICE_ATTR_RW for
read/write attributes. This simplifies the source code, improves
readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RO for read only attributes and DEVICE_ATTR_RW for
read/write attributes. This simplifies the source code, improves
readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RW for read/write attributes. This simplifies the source
code, improves readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RW for read/write attributes. This simplifies the source
code, improves readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RO for read only attributes and DEVICE_ATTR_RW for
read/write attributes. This simplifies the source code, improves
readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck