Commit Graph

3273 Commits

Author SHA1 Message Date
Linus Torvalds
71219b3494 hwmon updates for v4.17
- Added chip support: new centaur CPUs, ADM1272, NCT6796D
 - ucd9000: added debugfs attributes, gpio support
 - Cleanup and minor bug fixes
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJay6EdAAoJEMsfJm/On5mBFtAP/jNsoEEjfibtIl7UN0cZm1Ec
 f5awcKr0WM4BTYxiBDJkM4KrugODOsOVlfQQakulmarsF4gKBpH8I5XKRGc2Wny/
 DMD/nPsu6laLoFwaIhIiOlwerc7ppQHOe9OlwbBvVRptG8t710479JC68O1XDpqu
 tP/C5+QlmIOs+HXgDXBE96xjPxfi1emYxvgzIH/Q2nf0Sd1GKQVYlbIF94xeZBDg
 cp1Sv7XeoWxsb4QwUWL3YbwCc8kABgVHmjogZsyFd6fyIRM8bi+RJGIheawhT7xr
 iaQ2iihW1nvdPHLAssqEG5KaJGpHobcrRm1Wy/lCWfiiLI+ortl5Xn4b9fZCmM+W
 zKK1QhAKoe26QdsrHBdgjprldpmlfUz+wnkFILu3dQfvDugo75t3B9W62faoqsvh
 CqRxLwolFf+2yOepmB9uXXuv+9vf41P2HP1axhlkJkcQVRby+f52va9btgi5z64a
 56OWzCqY5ESWnC+8Tm/w7rf5w28iWXAKmi0+GqIBDJn0jsTw+MfERa2ruR5omeTh
 Eo0FkwzcgGmshhkk/q+ffNooqEvV5Ry4CSq7dgxNTB8Ri65zxW7Hnhp8yb9WN+MP
 LMC0WSjZ/y6CPi2lNU96bakdT+LPB/HFEYTTEEsDSFGbrDkcHQn6cVgwGbDZYlgw
 DPDhuJAgyQJCvce7TFCu
 =M6YK
 -----END PGP SIGNATURE-----

Merge tag 'hwmon-for-linus-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

Pull hwmon updates from Guenter Roeck:

 - added chip support: new Centaur CPUs, ADM1272, NCT6796D

 - ucd9000: added debugfs attributes, gpio support

 - cleanup and minor bug fixes

* tag 'hwmon-for-linus-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (via-cputemp) support new centaur CPUs
  hwmon: (nct6775) Fix writing pwmX_mode
  hwmon: (lm92) Add max6635 to lm92_id[]
  hwmon: (pmbus/adm1275) Add support for ADM1272
  hwmon: (lm92) Do not try to detect MAX6635
  hwmon: (ucd9000) Add debugfs attributes to provide mfr_status
  hwmon: (ucd9000) Add gpio chip interface
  hwmon: (nct6775) Add support for NCT6796D
  hwmon: (nct6775) Initialize boolean variables with declaration
  hwmon: (nct6775) Improve fan6/pwm6 support
  hwmon: (nct6775) Use NUM_FAN consistently
  hwmon: (g762) handle cleanup with devm_add_action
  hwmon: (sht3x) Update data sheet URL
  hwmon: (sht21) Update data sheet URLs
  hwmon: (pmbus/adm1275) Accept negative page register values
  hwmon: (pmbus/max8688) Accept negative page register values
2018-04-09 19:59:54 -07:00
davidwang
e3a2d2be51 hwmon: (via-cputemp) support new centaur CPUs
New centaur CPUs (Familiy == 7) also support this cpu temperature sensor.

Signed-off-by: David Wang <davidwang@zhaoxin.com>
[groeck: Dropped changelog, updated subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-30 07:53:57 -07:00
Guenter Roeck
415eb2a1aa hwmon: (nct6775) Fix writing pwmX_mode
pwmX_mode is defined in the ABI as 0=DC mode, 1=pwm mode. The chip
register bit is set to 1 for DC mode. This got mixed up, and writing
1 into pwmX_mode resulted in DC mode enabled. Fix it up by using
the ABI definition throughout the driver for consistency.

Fixes: 77eb5b3703 ("hwmon: (nct6775) Add support for pwm, pwm_mode, ... ")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-27 08:49:24 -07:00
Arnd Bergmann
f8d6dc78b8 ARM SCMI fixes/cleanups for v4.17
Couple of fixes for build warning due to uninitialised variable
 and static checker warning for passing NULL pointer to PTR_ERR.
 It also contains cleanup suggested by Stephen Boyd in SCMI clock
 driver using the new devm_of_clk_add_hw_provider() API.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABCAAGBQJasTqmAAoJEABBurwxfuKYoJEP/Reu05gZud5fcIwGId0GK3a+
 AuIqTNXmDSVTU8fOv78Pv7OgYGBmAYTuBIJ/ji3ox/wFpjhb1JrZDA/o6WLJuPsN
 EEt562TMNUN0bfZx4E+heUpqXpOdFchgjP6+OsOeLWk1JXK3AvTTY2z/hbwgaw5H
 gey4+oayxof47OH5UNOlbdbjzOLuGZGPlnEWlbxppm28+QHENRITdzogYDkkHJiQ
 IGa+fLMErXcmeNKYsorKH+OejEfVoe+K8lvo1s1YDAMYCAkHibu7d62ryf/cFW7H
 uj6yKLWXa92TEwqcSNIV0IM+xlX8e2kpeNuVbpTxXU1yYWLaEIVV5022VFCv7Z0G
 jR53V98sYfThmKVM/vJjr2AkSWhM6DmlUx15WvrnthRtHOcW3uUxnrMk84EDCntg
 eUX9Z7xevmdDz5k8uq6DYAvoImPrKU+yscJiAVBA0CZg8fi5cqAms7XGgY9dPzTD
 B4VIm8a4cmGMXpShZI2T/qKpJbPahKi4U9Yf134FAEuBufQ7oIFERwzzu039PQ5e
 0ZqLyFx7ZOnxr+cfpQKRTHFJBPRLSRAW5yI2Qh8szmZAcMzgcbsho9tvSsUer8GQ
 qYnXiX7IPJb9wcc0/dyku0oHEz8vIx/t2YqJzOfBKfYZSv2L8EdFkD1jRUU3B8K/
 BX0TAFjb7/6Y/CvUZIE4
 =Gvhw
 -----END PGP SIGNATURE-----

Merge tag 'scmi-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers

Pull "ARM SCMI fixes/cleanups for v4.17" from Sudeep Holla:

Couple of fixes for build warning due to uninitialised variable
and static checker warning for passing NULL pointer to PTR_ERR.
It also contains cleanup suggested by Stephen Boyd in SCMI clock
driver using the new devm_of_clk_add_hw_provider() API.

* tag 'scmi-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  clk: scmi: use devm_of_clk_add_hw_provider() API and drop scmi_clocks_remove
  firmware: arm_scmi: prevent accessing rate_discrete uninitialized
  hwmon: (scmi) return -EINVAL when sensor information is unavailable
2018-03-27 15:57:19 +02:00
Alvaro G. M
10ecacd794 hwmon: (lm92) Add max6635 to lm92_id[]
Since autodetection of this chip was removed, it makes sense to add prefix
max6635 so that the device can be instantiated by its actual name.

Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-22 09:33:24 -07:00
Guenter Roeck
4ff0ce227a hwmon: (pmbus/adm1275) Add support for ADM1272
The chip is quite similar to other chips in the series,
but as usual it comes with its own quirks.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-22 09:32:17 -07:00
Alvaro G. M
05993e226a hwmon: (lm92) Do not try to detect MAX6635
Maxim MAX663x family are mostly compatible with LM92, but they lack any
identification register. Weakening the detect function would make it prone
to false positives, and current one doesn't detect all chips.  Therefore,
the detect function for max6635 devices is removed in favor of explicit
device instatiation.

Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-22 09:32:05 -07:00
Sudeep Holla
c09880cef7 hwmon: (scmi) return -EINVAL when sensor information is unavailable
Passing NULL pointer to PTR_ERR will result in return value of 0
indicating success which is clearly not what it is intended here.

This patch returns -EINVAL instead when the sensor information is not
available.

Fixes: b23688aefb ("hwmon: add support for sensors exported via ARM SCMI")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-03-20 12:13:48 +00:00
Christopher Bostic
72816cb06e hwmon: (ucd9000) Add debugfs attributes to provide mfr_status
Expose the gpiN_fault fields of mfr_status as individual debugfs
attributes. This provides a way for users to be easily notified of gpi
faults. Also provide the whole mfr_status register in debugfs.

Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-16 18:52:35 -07:00
Christopher Bostic
ca781fb7fd hwmon: (ucd9000) Add gpio chip interface
Add a struct gpio_chip and define some methods so that this device's
I/O can be accessed via /sys/class/gpio.

Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-16 18:52:04 -07:00
Guenter Roeck
81820059a4 hwmon: (nct6775) Add support for NCT6796D
NCT6796D is mostly compatible to NCT6795D. It supports an additional
pwm control and fan speed channel.

While we are at it, update documentation for NCT6795D.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 19:00:14 -08:00
Guenter Roeck
1b20624090 hwmon: (nct6775) Initialize boolean variables with declaration
Initialize boolean flags in nct6775_check_fan_inputs() while
declaring them instead of several times throughout the code.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 19:00:14 -08:00
Guenter Roeck
00fd4cfe5b hwmon: (nct6775) Improve fan6/pwm6 support
Improve fan6/pwm6 detection on NCT6795D. Add support for fan pulses
for fans 4..6 and fan min limits for fan6.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 19:00:14 -08:00
Guenter Roeck
e2617262f1 hwmon: (nct6775) Use NUM_FAN consistently
The size of some of the arrays using the number of fans is hardcoded.
Use NUM_FAN consistently throughout the driver.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 19:00:14 -08:00
Hao Peng
47591baa71 hwmon: (g762) handle cleanup with devm_add_action
Simplify code and use devm_add_action() to handle cleanup.

Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
[groeck: Dropped unnecessary dummy function and NULL check]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 19:00:14 -08:00
Danilo Bargen
8e1d6fe961 hwmon: (sht21) Update data sheet URLs
The previously used URLs are dead.

Sensirion provides permalinks for their product datasheets at
https://www.sensirion.com/en/about-us/links/.

Signed-off-by: Danilo Bargen <mail@dbrgn.ch>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 19:00:14 -08:00
Guenter Roeck
ecb29abd4c hwmon: (pmbus/adm1275) Accept negative page register values
A negative page register value means that no page needs to be
selected. This is used by status register read operations and needs
to be accepted. The failure to do so so results in missed status
and limit registers.

Fixes: da8e48ab48 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 18:59:56 -08:00
Guenter Roeck
a46f8cd696 hwmon: (pmbus/max8688) Accept negative page register values
A negative page register value means that no page needs to be
selected. This is used by status register evaluations and needs
to be accepted.

Fixes: da8e48ab48 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-10 18:59:47 -08:00
Arnd Bergmann
f46f11dc1e ARM SCMI support for v4.17
ARM System Control and Management Interface(SCMI)[1] is more flexible and
 easily extensible than any of the existing interfaces.
 
 Few existing as well as future ARM platforms provide micro-controllers
 to abstract various power and other system management tasks which have
 similar interfaces, both in terms of the functions that are provided by
 them, and in terms of how requests are communicated to them.
 
 There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra
 BPMP, and so on already. This specification is to standardize and avoid any
 further fragmentation in the design of such interface by various vendors.
 
 The current SCMI driver implementation is very basic and initial support.
 It lacks support for notifications, asynchronous/delayed response, perf/power
 statistics region and sensor register region.
 
 Mailbox is the only form of transport supported currently in the driver.
 SCMI supports interrupt based mailbox communication, where, on completion
 of the processing of a message, the caller receives an interrupt as well as
 polling for completion.
 
 SCMI is designed to minimize the dependency on the mailbox/transport
 hardware. So in terms of SCMI, each channel in the mailbox includes
 memory area, doorbell and completion interrupt.
 
 However the doorbell and completion interrupt is highly mailbox dependent
 which was bit of controversial as part of SCMI/mailbox discussions.
 
 Arnd and me discussed about the few aspects of SCMI and the mailbox framework:
 
 1. Use of mailbox framework for doorbell type mailbox controller:
    - Such hardware may not require any data to be sent to signal the remote
      about the presence of a message. The channel will have in-built
      information on how to trigger the signal to the remote.
      There are few mailbox controller drivers which are purely doorbell based.
      e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc
 
 2. Supporting other mailbox controller:
    - SCMI just needs a mechanism to signal the remote firmware. Such
      controller may need fixed message to be sent to trigger a doorbell.
      In such case we may need to get that data from DT and pass the same
      to the controller. It's not covered in the current DT binding, but
      can be extended as optional property in future.
 
      However handling notifications may be interesting on such mailbox, but
      again there is no way to interpret what the data field(remote message)
      means, it could be a bit mask or a number or don't-care.
 
 Arnd mentioned that he doesn't like the way the mailbox binding deals
 with doorbell-type hardware, but we do have quite a few precedent drivers
 already and changing the binding to add a data field would not make it any
 better, but could cause other problems. So he is happy with the status quo
 of SCMI implementation.
 
 [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABCAAGBQJalvXJAAoJEABBurwxfuKYUHoQANi5gm0vGgRhb8/Cc6BHF9ij
 WVge3E2O+Ygg2qTKJJxWvwG3w09Pu9Pugwoa7vuisDNz4ihF+3WEYCZiwrbQhMOQ
 8ZyxXwdBu4Kp0fnNAGGq0MWllwspVgdC2Be5jviDTMw7H8ZIQEiKjxPkdSFY1xFj
 YAtTzuUeDcuztUb3IliOpLscxNUqGEQr4p/xj0VFu+1XSwtYo/9bDU7haiYNj0MD
 zbNv9WhyjUHTTsdQjDW4YGywQpFPu/oI8oSR5q+Q3mudccaZYbvvTwKDRACLVkr4
 rpeymFdGSEU8OI23pKql4eEZ2DC1VKuVnG9peTr9UhhuRL8jQKqFLeCYH0fGcY89
 VGWDIFBjyUg1NK7giCriqCq4m68UM49ChITXY6zRrIvyONgUZj6p6kTmCHC3TULH
 LWfu9lf7XqI5/AqZaXhHsDPL2Arf0u5K7rP6yaU0BgdQ2HRKV8rIT3KadjsOioAw
 bIDfpi4eInmq41CUy1gsWP6nIRg4qR4sZiWC2CW8ap0gbHq8a7PVuuRi4VDCZIkN
 CfntuDAnE+FMq/cMpgLRGteNbl0MVAeAeJfEGNyk5ahhYZtvnAy142zDpBmvWZth
 ZuZvb7mwiNPiZTC65B/DFDdSCKZtD+LVCodzcm2Pkx6zgW0SC6pje+mX0+zpDxZ9
 A9Eguiun1hInKX3URD1D
 =qOck
 -----END PGP SIGNATURE-----

Merge tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers

Pull "ARM SCMI support for v4.17" from Sudeep Holla:

ARM System Control and Management Interface(SCMI)[1] is more flexible and
easily extensible than any of the existing interfaces.

Few existing as well as future ARM platforms provide micro-controllers
to abstract various power and other system management tasks which have
similar interfaces, both in terms of the functions that are provided by
them, and in terms of how requests are communicated to them.

There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra
BPMP, and so on already. This specification is to standardize and avoid any
further fragmentation in the design of such interface by various vendors.

The current SCMI driver implementation is very basic and initial support.
It lacks support for notifications, asynchronous/delayed response, perf/power
statistics region and sensor register region.

Mailbox is the only form of transport supported currently in the driver.
SCMI supports interrupt based mailbox communication, where, on completion
of the processing of a message, the caller receives an interrupt as well as
polling for completion.

SCMI is designed to minimize the dependency on the mailbox/transport
hardware. So in terms of SCMI, each channel in the mailbox includes
memory area, doorbell and completion interrupt.

However the doorbell and completion interrupt is highly mailbox dependent
which was bit of controversial as part of SCMI/mailbox discussions.

Arnd and me discussed about the few aspects of SCMI and the mailbox framework:

1. Use of mailbox framework for doorbell type mailbox controller:
   - Such hardware may not require any data to be sent to signal the remote
     about the presence of a message. The channel will have in-built
     information on how to trigger the signal to the remote.
     There are few mailbox controller drivers which are purely doorbell based.
     e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc

2. Supporting other mailbox controller:
   - SCMI just needs a mechanism to signal the remote firmware. Such
     controller may need fixed message to be sent to trigger a doorbell.
     In such case we may need to get that data from DT and pass the same
     to the controller. It's not covered in the current DT binding, but
     can be extended as optional property in future.

     However handling notifications may be interesting on such mailbox, but
     again there is no way to interpret what the data field(remote message)
     means, it could be a bit mask or a number or don't-care.

Arnd mentioned that he doesn't like the way the mailbox binding deals
with doorbell-type hardware, but we do have quite a few precedent drivers
already and changing the binding to add a data field would not make it any
better, but could cause other problems. So he is happy with the status quo
of SCMI implementation.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html

* tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  cpufreq: scmi: add support for fast frequency switching
  cpufreq: add support for CPU DVFS based on SCMI message protocol
  hwmon: add support for sensors exported via ARM SCMI
  hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration
  clk: add support for clocks provided by SCMI
  firmware: arm_scmi: add device power domain support using genpd
  firmware: arm_scmi: add per-protocol channels support using idr objects
  firmware: arm_scmi: refactor in preparation to support per-protocol channels
  firmware: arm_scmi: add option for polling based performance domain operations
  firmware: arm_scmi: add support for polling based SCMI transfers
  firmware: arm_scmi: probe and initialise all the supported protocols
  firmware: arm_scmi: add initial support for sensor protocol
  firmware: arm_scmi: add initial support for power protocol
  firmware: arm_scmi: add initial support for clock protocol
  firmware: arm_scmi: add initial support for performance protocol
  firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices
  firmware: arm_scmi: add common infrastructure and support for base protocol
  firmware: arm_scmi: add basic driver infrastructure for SCMI
  dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol
  dt-bindings: mailbox: add support for mailbox client shared memory
2018-03-07 16:45:07 +01:00
Sudeep Holla
b23688aefb hwmon: add support for sensors exported via ARM SCMI
Create a driver to add support for SoC sensors exported by the System
Control Processor (SCP) via the System Control and Management Interface
(SCMI). The supported sensor types is one of voltage, temperature,
current, and power.

The sensor labels and values provided by the SCP are exported via the
hwmon sysfs interface.

Cc: linux-hwmon@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28 16:37:57 +00:00
Linus Torvalds
3e9f4df0ea Fix bad temperature display on Ryzen/Threadripper
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJahgQ1AAoJEMsfJm/On5mBNfgQAJgCjg4gatr0U2pqd40IPtwS
 V/KrAfLtt9+zv6HSdW1zc1vUKb3mAvi9roVIX6i4nuSjS9eitPRyvcSN+UW9X01t
 r8jqwtStssaXEKLzRkEGBoACy7/A0fNCcjHMOj1EPftKIOZdfGnZ6r4cI+/wGyLR
 ybBjcvfMNkLGgJbRKy/2Acib/Jp9OoJpjLMVyIFnhRGgRmvYKSDu7rK6ecmW2KSG
 mgKyzxL29PLfWu8jVwnkXfZcdG97akEv90BfUUa16KXA3+hgvscM5+7jQmap4N3p
 nh3yLc7MyTXvfOhKauer4czTwbr3JoDZ+BZ38a1qoD+cPX6e5GkGJnFR1E0NBG/p
 7m2w1u7LVhab5t7NFA8JgKB8J8PfyGVCiHfF0szil6lA0LiRVN/rgMcAEIavIO7K
 7C5OBjVYWk0PeJULU66r81kILvZMtc6xh6XC2gc8Z+t6uu4Ld4FSUsIWL6Muu0l6
 i2h8WX5HSMjSqCylPBTRD0a/hvPuQjWE0fkLoAtgPCt112Je6xitJzZM+RPDKonV
 8+zG1NM9eePnSNt3TsdMeF6HOR9fR9n7E3D0xsM2cbHXa1BOwlVCkPYYqNA6QkaM
 ZKTRKysZn3fYfMT0fVfdZ7E0ODZPpY/gwdqE4bduH9pMksqO0E2/g9PX/JQV13bN
 IwpMFO9aHMqVc+U8Xwhu
 =kHhI
 -----END PGP SIGNATURE-----

Merge tag 'hwmon-for-linus-v4.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

Pull hwmon fix from Guenter Roeck:
 "Fix bad temperature display on Ryzen/Threadripper"

* tag 'hwmon-for-linus-v4.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (k10temp) Only apply temperature offset if result is positive
2018-02-15 14:31:28 -08:00
Linus Torvalds
d4667ca142 Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 PTI and Spectre related fixes and updates from Ingo Molnar:
 "Here's the latest set of Spectre and PTI related fixes and updates:

  Spectre:
   - Add entry code register clearing to reduce the Spectre attack
     surface
   - Update the Spectre microcode blacklist
   - Inline the KVM Spectre helpers to get close to v4.14 performance
     again.
   - Fix indirect_branch_prediction_barrier()
   - Fix/improve Spectre related kernel messages
   - Fix array_index_nospec_mask() asm constraint
   - KVM: fix two MSR handling bugs

  PTI:
   - Fix a paranoid entry PTI CR3 handling bug
   - Fix comments

  objtool:
   - Fix paranoid_entry() frame pointer warning
   - Annotate WARN()-related UD2 as reachable
   - Various fixes
   - Add Add Peter Zijlstra as objtool co-maintainer

  Misc:
   - Various x86 entry code self-test fixes
   - Improve/simplify entry code stack frame generation and handling
     after recent heavy-handed PTI and Spectre changes. (There's two
     more WIP improvements expected here.)
   - Type fix for cache entries

  There's also some low risk non-fix changes I've included in this
  branch to reduce backporting conflicts:

   - rename a confusing x86_cpu field name
   - de-obfuscate the naming of single-TLB flushing primitives"

* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (41 commits)
  x86/entry/64: Fix CR3 restore in paranoid_exit()
  x86/cpu: Change type of x86_cache_size variable to unsigned int
  x86/spectre: Fix an error message
  x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping
  selftests/x86/mpx: Fix incorrect bounds with old _sigfault
  x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]()
  x86/speculation: Add <asm/msr-index.h> dependency
  nospec: Move array_index_nospec() parameter checking into separate macro
  x86/speculation: Fix up array_index_nospec_mask() asm constraint
  x86/debug: Use UD2 for WARN()
  x86/debug, objtool: Annotate WARN()-related UD2 as reachable
  objtool: Fix segfault in ignore_unreachable_insn()
  selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems
  selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c
  selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c
  selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory
  selftests/x86/pkeys: Remove unused functions
  selftests/x86: Clean up and document sscanf() usage
  selftests/x86: Fix vDSO selftest segfault for vsyscall=none
  x86/entry/64: Remove the unused 'icebp' macro
  ...
2018-02-14 17:02:15 -08:00
Jia Zhang
b399151cb4 x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping
x86_mask is a confusing name which is hard to associate with the
processor's stepping.

Additionally, correct an indent issue in lib/cpu.c.

Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com>
[ Updated it to more recent kernels. ]
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@alien8.de
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-15 01:15:52 +01:00
Guenter Roeck
aef17ca127 hwmon: (k10temp) Only apply temperature offset if result is positive
A user reports a really bad temperature on Ryzen 1950X.

k10temp-pci-00cb
Adapter: PCI adapter
temp1: +4294948.3°C (high = +70.0°C)

This will happen if the temperature reported by the chip is lower than
the offset temperature. This has been seen in the field if "Sense MI Skew"
and/or "Sense MI Offset" BIOS parameters were set to unexpected values.
Let's report a temperature of 0 degrees C in that case.

Fixes: 1b50b77635 ("hwmon: (k10temp) Add support for temperature offsets")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-02-12 14:23:29 -08:00
Oleksandr Natalenko
6fbc4232a5 hwmon: (dell-smm) Disable fan support for Dell Vostro 3360
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell
Vostro 3360 freeze kernel for about 500ms.

Unfortunately, it is unlikely for Dell to fix this since the machine
is pretty old, so this commit just disables fan support to make the
system usable again.

Via "force" module param fan support can be enabled.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751
Link: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/06083.html
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27 09:34:22 -08:00
Pali Rohár
f480ea90b9 hwmon: (dell-smm) Disable fan support for Dell Inspiron 7720
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell
Inspiron 7720 freeze kernel for about 500ms. Until Dell fixes it we need to
disable fan support for Dell Inspiron 7720 as it makes system unusable.

Via "force" module param fan support can be enabled.

Reported-by: vova7890@mail.ru
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751
Cc: stable@vger.kernel.org # v4.0+, will need backport
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27 09:34:03 -08:00
Pali Rohár
836ad11235 hwmon: (dell-smm) Enable broken functionality via "force" module param
Some Dell machines are broken and some functionality is disabled. Show
warning into dmesg about this fact and allow user via "force" module param
to override brokenness and enable broken functionality.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27 09:33:38 -08:00
Guenter Roeck
6509614fdd hwmon: (k10temp) Add temperature offset for Ryzen 1900X
Like the other CPUs from the same series, the 1900X has a
temperature offset of 27 degrees C.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-19 06:38:03 -08:00
Luis de Bethencourt
ccffe77670 hwmon: (lm75) Fix trailing semicolon
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.

Signed-off-by: Luis de Bethencourt <luisbg@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-17 14:51:12 -08:00
Marek Szyprowski
0c4c5860e9 hwmon: (ina2xx) Fix access to uninitialized mutex
Initialize data->config_lock mutex before it is used by the driver code.

This fixes following warning on Odroid XU3 boards:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc7-next-20180115-00001-gb75575dee3f2 #107
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0111504>] (unwind_backtrace) from [<c010dbec>] (show_stack+0x10/0x14)
[<c010dbec>] (show_stack) from [<c09b3f74>] (dump_stack+0x90/0xc8)
[<c09b3f74>] (dump_stack) from [<c0179528>] (register_lock_class+0x1c0/0x59c)
[<c0179528>] (register_lock_class) from [<c017bd1c>] (__lock_acquire+0x78/0x1850)
[<c017bd1c>] (__lock_acquire) from [<c017de30>] (lock_acquire+0xc8/0x2b8)
[<c017de30>] (lock_acquire) from [<c09ca59c>] (__mutex_lock+0x60/0xa0c)
[<c09ca59c>] (__mutex_lock) from [<c09cafd0>] (mutex_lock_nested+0x1c/0x24)
[<c09cafd0>] (mutex_lock_nested) from [<c068b0d0>] (ina2xx_set_shunt+0x70/0xb0)
[<c068b0d0>] (ina2xx_set_shunt) from [<c068b218>] (ina2xx_probe+0x88/0x1b0)
[<c068b218>] (ina2xx_probe) from [<c0673d90>] (i2c_device_probe+0x1e0/0x2d0)
[<c0673d90>] (i2c_device_probe) from [<c053a268>] (driver_probe_device+0x2b8/0x4a0)
[<c053a268>] (driver_probe_device) from [<c053a54c>] (__driver_attach+0xfc/0x120)
[<c053a54c>] (__driver_attach) from [<c05384cc>] (bus_for_each_dev+0x58/0x7c)
[<c05384cc>] (bus_for_each_dev) from [<c0539590>] (bus_add_driver+0x174/0x250)
[<c0539590>] (bus_add_driver) from [<c053b5e0>] (driver_register+0x78/0xf4)
[<c053b5e0>] (driver_register) from [<c0675ef0>] (i2c_register_driver+0x38/0xa8)
[<c0675ef0>] (i2c_register_driver) from [<c0102b40>] (do_one_initcall+0x48/0x18c)
[<c0102b40>] (do_one_initcall) from [<c0e00df0>] (kernel_init_freeable+0x110/0x1d4)
[<c0e00df0>] (kernel_init_freeable) from [<c09c8120>] (kernel_init+0x8/0x114)
[<c09c8120>] (kernel_init) from [<c01010b4>] (ret_from_fork+0x14/0x20)

Fixes: 5d389b1251 ("hwmon: (ina2xx) Make calibration register value fixed")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-15 08:01:45 -08:00
Samuel Mendoza-Jonas
08f411bcb5 hwmon: (pmbus/ir35221) Remove unnecessary scaling
The ir35221 datasheet describes specific scaling factors for a number of
commands which the current driver applies when reading.
However now that the ir35221 has been tested on machines with more
easily verifiable readings these descriptions have turned out to be
superfluous and reading each command according to the linear format is
sufficient.

Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-15 04:22:46 -08:00
Emiliano Ingrassia
abe6c3b06f hwmon: (sht3x) wait predefined limits loading complete before access
An sht3x sensor include limits register which contains temperature
and humidity limit values. After a reset, pre-defined values are loaded
into that register. During the probe function, the driver reads the
limits register. However, if the reads are made too early, and the bus
is clocked at high frequencies (e.g. 100 kHz or more), the loading could be
not completed and the sensor returns a NACK which causes the probe to fail.
A delay of at least 500 us before the first read solves this issue.

Signed-off-by: Emiliano Ingrassia <ingrassia@epigenesys.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-12 14:18:39 -08:00
Arnd Bergmann
b007640649 hwmon: (pmbus/ibm-cffps) Add dependency on LEDS_CLASS
Building without CONFIG_LEDS_CLASS causes a link failure:

drivers/hwmon/pmbus/ibm-cffps.o: In function `ibm_cffps_probe':
ibm-cffps.c:(.text+0x4f4): undefined reference to `devm_of_led_classdev_register'

This adds the required dependency.

Fixes: ef9e1cdf41 ("hwmon: (pmbus/cffps) Add led class device ...")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-12 09:24:16 -08:00
eajames@linux.vnet.ibm.com
ef9e1cdf41 hwmon: (pmbus/cffps) Add led class device for power supply fault led
This power supply device doesn't correctly manage it's own fault led.
Add an led class device and register it so that userspace can manage
power supply fault led as necessary.

Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-11 10:28:35 -08:00
Eddie James
4471879acf hwmon: (pmbus) cffps: Add PMBUS_SKIP_STATUS_CHECK
This power supply device regularly fails to read VOUT_MODE due to the
CML bit going high. This results in an incorrect exponent used for the
voltage data, and therefore the power supply reports incorrect voltage.
Work around this by setting the pmbus flag to skip the CML check.

Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Fixes: f69316d62c ("hwmon: (pmbus) Add IBM Common Form Factor (CFF) ...")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-08 13:29:10 -08:00
Joel
18c514cc0e hwmon: (aspeed-pwm-tacho) Deassert reset in probe
The ASPEED SoC must deassert a reset in order to use the PWM/tach
peripheral.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Edward A. James
d6bb645a17 hwmon: (pmbus) cffps: Add debugfs entries
Add debugfs entries for additional power supply data, including part
number, serial number, FRU number, firmware revision, ccin, and the
input history of the power supply. The input history is 10 minutes of
input power data in the form of twenty 30-second packets. Each packet
contains average and maximum power for that 30 second period.

Signed-off-by: Edward A. James <eajames@us.ibm.com>
[groeck: Fixed endianness problem]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Edward A. James
eb6489b696 hwmon: (pmbus) Export pmbus device debugfs directory entry
Pmbus client drivers, if they want to use debugfs, should use the same
root directory as the pmbus debugfs entries are using. Therefore, export
the device dentry for the pmbus client.

Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Guenter Roeck
571e3f3a8e hwmon: (w83773g) Fix fault detection and reporting
Smatch reports:

drivers/hwmon/w83773g.c:105
	get_fault() warn: shift has higher precedence than mask

Code analysis shows that the code is indeed wrong.
Fix it, and while we are at it, drop unnecessary typecast.

Fixes: 86a10c802362 ("hwmon: Add W83773G driver")
Cc: Lei YU <mine260309@gmail.com>
Reviewed-by: Lei YU <mine260309@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Guenter Roeck
a7a9b15a35 hwmon: (hih6130) Fix documentation of struct hih6130
Sparse reports:

drivers/hwmon/hih6130.c:56: warning:
	No description found for parameter 'client'
drivers/hwmon/hih6130.c:56: warning:
	Excess struct member 'hwmon_dev' description in 'hih6130'

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Guenter Roeck
7f6d70cd47 hwmon: (iio_hwmon) Fix documentation of struct iio_hwmon_state
Sparse reports:

drivers/hwmon/iio_hwmon.c:36: warning:
	No description found for parameter 'groups'

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Guenter Roeck
d5324e9095 hwmon: (sht15) Fix parameter documentation of sht15_crc8()
Sparse reports:

drivers/hwmon/sht15.c:188: warning:
		No description found for parameter 'len'

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Guenter Roeck
679f50b8d1 hwmon: (sht21) Fix documentation of struct sht21
Sparse reports:

drivers/hwmon/sht21.c:60: warning:
	No description found for parameter 'client'
drivers/hwmon/sht21.c:60:
	warning: Excess struct member 'hwmon_dev' description in 'sht21'

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Guenter Roeck
3870945aeb hwmon: Fix parameter documentation
sparse reports:

drivers/hwmon/hwmon.c:681: warning:
	No description found for parameter 'chip'
drivers/hwmon/hwmon.c:681: warning:
	Excess function parameter 'info' description in
	'hwmon_device_register_with_info'
drivers/hwmon/hwmon.c:789: warning:
	No description found for parameter 'chip'
drivers/hwmon/hwmon.c:789: warning:
	No description found for parameter 'groups'
drivers/hwmon/hwmon.c:789: warning:
	Excess function parameter 'info' description in
	'devm_hwmon_device_register_with_info'

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Javier Martinez Canillas
98b16a0986 hwmon: (max31785) 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.

Before this patch:

$ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias
alias:          i2c:max31785a
alias:          i2c:max31785

After this patch:

$ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias
alias:          i2c:max31785a
alias:          i2c:max31785
alias:          of:N*T*Cmaxim,max31785aC*
alias:          of:N*T*Cmaxim,max31785a
alias:          of:N*T*Cmaxim,max31785C*
alias:          of:N*T*Cmaxim,max31785

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Maciej Purski
5d389b1251 hwmon: (ina2xx) Make calibration register value fixed
Calibration register is used for calculating current register in
hardware according to datasheet:
current = shunt_volt * calib_register / 2048 (ina 226)
current = shunt_volt * calib_register / 4096 (ina 219)

Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in
order to avoid truncation error and provide best precision allowed
by shunt_voltage measurement. Make current scale value follow changes
of shunt_resistor from sysfs as calib_register value is now fixed.

Power_lsb value should also follow shunt_resistor changes as stated in
datasheet:
power_lsb = 25 * current_lsb (ina 226)
power_lsb = 20 * current_lsb (ina 219)

Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Andrew Jeffery
cf583b4275 hwmon: (pmbus/max31785) Add dual tachometer support
The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of i2c_smbus_xfer_emulated() included in the driver.
Further, to expose the second rotor tachometer value to userspace the
values are exposed through virtual pages. We re-route accesses to
FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on pages 23-28 (not defined by the
hardware) to the same registers on pages 0-5, and with the latter command
we extract the value from the second word of the four-byte response.

* The documentation recommends the slower rotor be associated with
TACHSEL=0, which corresponds to the first word of the response. The
TACHSEL=0 measurement is used by the controller's closed-loop fan
management to judge target fan rate.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Andrew Jeffery
464df6fa37 hwmon: (pmbus) Add virtual page config bit
Some circumstances call for virtual pages, to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. An example of this is the Maxim MAX31785 controller,
which extends the READ_FAN_SPEED_1 PMBus register from two to four bytes
to support tach readings for both rotors of a dual rotor fan. This extended
register contains two word-sized values, one reporting the rate of the
fastest rotor, the other the rate of the slowest. The concept of virtual
pages aids this situation by mapping the page number onto the value to be
selected from the vectored result.

We should not try to set virtual pages on the device as such a page
explicitly doesn't exist; add a flag so we can avoid doing so.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Andrew Jeffery
56ad86b4b1 hwmon: (pmbus/max31785) Add fan control
The implementation makes use of the new fan control virtual registers
exposed by the pmbus core. It mixes use of the default implementations
with some overrides via the read/write handlers to handle FAN_COMMAND_1
on the MAX31785, whose definition breaks the value range into various
control bands dependent on RPM or PWM mode.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00
Andrew Jeffery
d206636e76 hwmon: (pmbus) Add fan control support
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.

Fans in a PMBus device are driven by the configuration of two registers,
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding configuration in FAN_CONFIG_x_y.

The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers to
facilitate the necessary side-effects of each access:

1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x

Some complexity arises with the fanX_target and pwmX attributes both mapping
onto FAN_COMMAND_x: There is no general mapping between PWM percent duty and
RPM, so we can't display values in either attribute in terms of the other
(which in my mind is the intuitive, if impossible, behaviour). This problem
also affects the pwmX_enable attribute which allows userspace to switch between
full speed, manual PWM and a number of automatic control modes, possibly
including a switch to RPM behaviour (e.g. automatically adjusting PWM duty to
reach a RPM target, the behaviour of fanX_target).

The next most intuitive behaviour is for fanX_target and pwmX to simply be
independent, to retain their most recently set value even if that value is not
active on the hardware (due to switching to the alternative control mode). This
property of retaining the value independent of the hardware state has useful
results for both userspace and the kernel: Userspace always sees a sensible
value in the attribute (the last thing it was set to, as opposed to 0 or
receiving an error on read), and the kernel can use the attributes as a value
cache. This latter point eases the implementation of pwmX_enable, which can
look up the associated pmbus_sensor object, take its cached value and apply it
to hardware on changing control mode. This ensures we will not arbitrarily set
a PWM value as an RPM value or vice versa, and we can assume that the RPM or
PWM value set was sensible at least at some point in the past.

Finally, the DIRECT mode coefficients of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to capture the
necessary coefficients. As pmbus core had no PWM support previously PSC_FAN
continues to be used to capture the RPM DIRECT coefficients, but in order to
avoid falsely applying RPM scaling to PWM values I have introduced the
PMBUS_HAVE_PWM12 and PMB_BUS_HAVE_PWM34 feature bits. These feature bits allow
drivers to explicitly declare PWM support in order to have the attributes
exposed.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-02 15:05:34 -08:00