[ Upstream commit 3be8c9d103534fadc72b3e174613f37aa19fa423 ]

For NCT6795D and NCT6796D, the DIMM temperature sources are named
"Agent[01] Dimm [01]" per datasheet. Match names in datasheets to
avoid confusion.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 53dfa0088edd2e2793afa21488532b12eb2dae48 ]

BIOS developer guides refer to Family 15h Models 60h-6fh and Family 15h
Models 70h-7fh. So far the driver only checked for Models 60h and 70h.
However, there are now processors with other model numbers in the same
families. Example is A10-9620P family 15h model 65h. Follow the developer
guides and mask the lower 4 bit of the model number to determine the
registers to use for reading temperatures and temperature limits.
Reported-by: NGuglielmo Fanini <g.fanini@gmail.com>
Cc: Guglielmo Fanini <g.fanini@gmail.com>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 6e4d91aa071810deac2cd052161aefb376ecf04e ]

At boot time, the acpi_power_meter driver logs the following error level
message: "Ignoring unsafe software power cap". Having read about it from
a few sources, it seems that the error message can be quite misleading.

While the message can imply that Linux is ignoring the fact that the
system is operating in potentially dangerous conditions, the truth is
the driver found an ACPI_PMC object that supports software power
capping. The driver simply decides not to use it, perhaps because it
doesn't support the object.

The best solution is probably changing the log level from error to warning.
All sources I have found, regarding the error, have downplayed its
significance. There is not much of a reason for it to be on error level,
while causing potential confusions or misinterpretations.
Signed-off-by: NWang Shenran <shenran268@gmail.com>
Link: https://lore.kernel.org/r/20190724080110.6952-1-shenran268@gmail.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

commit 38ada2f406a9b81fb1249c5c9227fa657e7d5671 upstream.

The code to detect if in4 is present is wrong; if in4 is not present,
the in4_input sysfs attribute is still present.

In detail:

- Ihen RTD3_MD=11 (VSEN3 present), everything is as expected (no bug).
- If we have RTD3_MD!=11 (no VSEN3), we unexpectedly have a in4_input
  file under /sys and the "sensors" command displays in4_input.
  But as expected, we have no in4_min, in4_max, in4_alarm, in4_beep.

Fix is_visible function to detect and report in4_input visibility
as expected.
Reported-by: NGilles Buloz <Gilles.Buloz@kontron.com>
Cc: Gilles Buloz <Gilles.Buloz@kontron.com>
Cc: stable@vger.kernel.org
Fixes: 3434f378 ("hwmon: Driver for Nuvoton NCT7802Y")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit f3d43e2e45fd9d44ba52d20debd12cd4ee9c89bf ]

Fixed address of third NCT6106_REG_WEIGHT_DUTY_STEP, and
added missed NCT6106_REG_TOLERANCE_H.

Fixes: 6c009501 ("hwmon: (nct6775) Add support for NCT6102D/6106D")
Signed-off-by: NBjoern Gerhart <gerhart@posteo.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 4a60570dce658e3f8885bbcf852430b99f65aca5 ]

Some chips have attributes which exist on more than one page but the
attribute is not presently marked as paged. This causes the attributes
to be generated with the same label, which makes it impossible for
userspace to tell them apart.

Marking all such attributes as paged would result in the page suffix
being added regardless of whether they were present on more than one
page or not, which might break existing setups. Therefore, we add a
second check which treats the attribute as paged, even if not marked as
such, if it is present on multiple pages.

Fixes: b4ce237b ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers")
Signed-off-by: NRobert Hancock <hancock@sedsystems.ca>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit c41dd48e21fae3e55b3670ccf2eb562fc1f6a67d ]

Drivers may register to hwmon and request for also registering
with the thermal subsystem (HWMON_C_REGISTER_TZ). However,
some of these driver, e.g. marvell phy, may be probed from
Device Tree or being dynamically allocated, and in the later
case, it will not have a dev->of_node entry.

Registering with hwmon without the dev->of_node may result in
different outcomes depending on the device tree, which may
be a bit misleading. If the device tree blob has no 'thermal-zones'
node, the *hwmon_device_register*() family functions are going
to gracefully succeed, because of-thermal,
*thermal_zone_of_sensor_register() return -ENODEV in this case,
and the hwmon error path handles this error code as success to
cover for the case where CONFIG_THERMAL_OF is not set.
However, if the device tree blob has the 'thermal-zones'
entry, the *hwmon_device_register*() will always fail on callers
with no dev->of_node, propagating -EINVAL.

If dev->of_node is not present, calling of-thermal does not
make sense. For this reason, this patch checks first if the
device has a of_node before going over the process of registering
with the thermal subsystem of-thermal interface. And in this case,
when a caller of *hwmon_device_register*() with HWMON_C_REGISTER_TZ
and no dev->of_node will still register with hwmon, but not with
the thermal subsystem. If all the hwmon part bits are in place,
the registration will succeed.

Fixes: d560168b ("hwmon: (core) New hwmon registration API")
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NEduardo Valentin <eduval@amazon.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 73e6ff71a7ea924fb7121d576a2d41e3be3fc6b5 ]

Super-IO accesses may fail on a system with no or unmapped LPC bus.

Unable to handle kernel paging request at virtual address ffffffbffee0002e
pgd = ffffffc1d68d4000
[ffffffbffee0002e] *pgd=0000000000000000, *pud=0000000000000000
Internal error: Oops: 94000046 [#1] PREEMPT SMP
Modules linked in: f71805f(+) hwmon
CPU: 3 PID: 1659 Comm: insmod Not tainted 4.5.0+ #88
Hardware name: linux,dummy-virt (DT)
task: ffffffc1f6665400 ti: ffffffc1d6418000 task.ti: ffffffc1d6418000
PC is at f71805f_find+0x6c/0x358 [f71805f]

Also, other drivers may attempt to access the LPC bus at the same time,
resulting in undefined behavior.

Use request_muxed_region() to ensure that IO access on the requested
address space is supported, and to ensure that access by multiple
drivers is synchronized.

Fixes: e53004e2 ("hwmon: New f71805f driver")
Reported-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reported-by: NJohn Garry <john.garry@huawei.com>
Cc: John Garry <john.garry@huawei.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 755a9b0f8aaa5639ba5671ca50080852babb89ce ]

Super-IO accesses may fail on a system with no or unmapped LPC bus.

Also, other drivers may attempt to access the LPC bus at the same time,
resulting in undefined behavior.

Use request_muxed_region() to ensure that IO access on the requested
address space is supported, and to ensure that access by multiple drivers
is synchronized.

Fixes: ba224e2c ("hwmon: New PC87427 hardware monitoring driver")
Reported-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reported-by: NJohn Garry <john.garry@huawei.com>
Cc: John Garry <john.garry@huawei.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 8c0826756744c0ac1df600a5e4cca1a341b13101 ]

Super-IO accesses may fail on a system with no or unmapped LPC bus.

Also, other drivers may attempt to access the LPC bus at the same time,
resulting in undefined behavior.

Use request_muxed_region() to ensure that IO access on the requested
address space is supported, and to ensure that access by multiple drivers
is synchronized.

Fixes: 8d5d45fb ("I2C: Move hwmon drivers (2/3)")
Reported-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reported-by: NJohn Garry <john.garry@huawei.com>
Cc: John Garry <john.garry@huawei.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit d6410408ad2a798c4cc685252c1baa713be0ad69 ]

Super-IO accesses may fail on a system with no or unmapped LPC bus.

Also, other drivers may attempt to access the LPC bus at the same time,
resulting in undefined behavior.

Use request_muxed_region() to ensure that IO access on the requested
address space is supported, and to ensure that access by multiple drivers
is synchronized.

Fixes: 8d5d45fb ("I2C: Move hwmon drivers (2/3)")
Reported-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reported-by: NJohn Garry <john.garry@huawei.com>
Cc: John Garry <john.garry@huawei.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 14b97ba5c20056102b3dd22696bf17b057e60976 ]

Super-IO accesses may fail on a system with no or unmapped LPC bus.

Also, other drivers may attempt to access the LPC bus at the same time,
resulting in undefined behavior.

Use request_muxed_region() to ensure that IO access on the requested
address space is supported, and to ensure that access by multiple drivers
is synchronized.

Fixes: 2219cd81 ("hwmon/vt1211: Add probing of alternate config index port")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

commit 53f1647da3e8fb3e89066798f0fdc045064d353d upstream.

In case pwm_fan_of_get_cooling_data() fails we should disable the PWM
just like in the other error cases.

Fixes: 2e5219c7 ("hwmon: (pwm-fan) Read PWM FAN configuration from device tree")
Cc: <stable@vger.kernel.org> # 4.14+
Reported-by: NGuenter Rock <linux@roeck-us.net>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a165dcc923ada2ffdee1d4f41f12f81b66d04c55 upstream.

Select REGMAP_I2C to avoid below build error:
ERROR: "__devm_regmap_init_i2c" [drivers/hwmon/w83773g.ko] undefined!

Fixes: ee249f27 ("hwmon: Add W83773G driver")
Cc: stable@vger.kernel.org
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit f422449b58548a41e98fc97b259a283718e527db ]

Correct a typo in OF device ID table
The last one should be 'ti,tmp442'
Signed-off-by: NCheng-Min Ao <tony_ao@wiwynn.com>
Signed-off-by: NYu-Hsiang Chen <matt_chen@wiwynn.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

commit 07bd14ccc3049f9c0147a91a4227a571f981601a upstream.

Add the missing unlock before return from function set_fan_div()
in the error handling case.

Fixes: c9c63915519b ("hwmon: (lm80) fix a missing check of the status of SMBus read")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 9aa3aa15f4c2f74f47afd6c5db4b420fadf3f315 ]

In lm80_probe(), if lm80_read_value() fails, it returns a negative
error number which is stored to data->fan[f_min] and will be further
used. We should avoid using the data if the read fails.

The fix checks if lm80_read_value() fails, and if so, returns with the
error number.
Signed-off-by: NKangjie Lu <kjlu@umn.edu>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit c9c63915519b1def7043b184680f33c24cd49d7b ]

If lm80_read_value() fails, it returns a negative number instead of the
correct read data. Therefore, we should avoid using the data if it
fails.

The fix checks if lm80_read_value() fails, and if so, returns with the
error number.
Signed-off-by: NKangjie Lu <kjlu@umn.edu>
[groeck: One variable for return values is enough]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 09aaf6813cfca4c18034fda7a43e68763f34abb1 ]

Both datasheet and comments of store_temp_mode() tell us that temp1~4_type
is writable, so fix it.
Signed-off-by: NYao Wang <wangyao@lemote.com>
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Fixes: 39deb699 (" hwmon: (w83795) Simplify temperature sensor type handling")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 243cfe3fb8978c7eec24511aba7dac98819ed896 ]

Fix macros for tacometer fault reading.
This fix is relevant for three Mellanox systems MQMB7, MSN37, MSN34,
which are about to be released to the customers.
At the moment, none of them is at customers sites.

Fixes: 65afb4c8 ("hwmon: (mlxreg-fan) Add support for Mellanox FAN driver")
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 38cd989ee38c16388cde89db5b734f9d55b905f9 ]

The current register (04h) has a sign bit at MSB. The comments
for this calculation also mention that it's a signed register.

However, the regval is unsigned type so result of calculation
turns out to be an incorrect value when current is negative.

This patch simply fixes this by adding a casting to s16.

Fixes: 5d389b12 ("hwmon: (ina2xx) Make calibration register value fixed")
Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 35fdc3902179366489a12cae4cb3ccc3b95f0afe ]

In case an under-voltage happens before probing the driver wont
write the critical warning into the kernel log. So don't init
of last_throttled during probe and fix this issue.

Fixes: 74d1e007 ("hwmon: Add support for RPi voltage sensor")
Reported-by: N"Noralf Trønnes" <noralf@tronnes.org>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit 70df9ebbd82c794ddfbb49d45b337f18d5588dc2 ]

When using DT configurations, the id pointer might turn out to
be NULL. Then the driver encounters NULL pointer access:

  Unable to handle kernel read from unreadable memory at vaddr 00000018
  [...]
  PC is at ina2xx_probe+0x114/0x200
  LR is at ina2xx_probe+0x10c/0x200
  [...]
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

The reason is that i2c core returns the id pointer by matching
id_table with client->name, while the client->name is actually
using the name from the first string in the DT compatible list,
not the best one. So i2c core would fail to match the id_table
if the best matched compatible string isn't the first one, and
then would return a NULL id pointer.

This probably should be fixed in i2c core. But it doesn't hurt
to make the driver robust. So this patch fixes it by using the
"chip" that's added to unify both DT and non-DT configurations.

Additionally, since id pointer could be null, so as id->name:
  ina2xx 10-0047: power monitor (null) (Rshunt = 1000 uOhm)
  ina2xx 10-0048: power monitor (null) (Rshunt = 10000 uOhm)

So this patch also fixes NULL name pointer, using client->name
to play safe and to align with hwmon->name.

Fixes: bd0ddd4d ("hwmon: (ina2xx) Add OF device ID table")
Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

[ Upstream commit e3e61f01 ]

If gcc decides not to inline make_sensor_label():

    WARNING: vmlinux.o(.text+0x4df549c): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label()
    The function .create_device_attrs() references
    the function __init .make_sensor_label().
    This is often because .create_device_attrs lacks a __init
    annotation or the annotation of .make_sensor_label is wrong.

As .probe() can be called after freeing of __init memory, all __init
annotiations in the driver are bogus, and should be removed.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>

commit 74e3512731bd5c9673176425a76a7cc5efa8ddb6 upstream.

Fix double-free that happens when thermal zone setup fails, see KASAN log
below.

==================================================================
BUG: KASAN: double-free or invalid-free in __hwmon_device_register+0x5dc/0xa7c

CPU: 0 PID: 132 Comm: kworker/0:2 Tainted: G    B             4.19.0-rc8-next-20181016-00042-gb52cd80401e9-dirty #41
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
Backtrace:
[<c0110540>] (dump_backtrace) from [<c0110944>] (show_stack+0x20/0x24)
[<c0110924>] (show_stack) from [<c105cb08>] (dump_stack+0x9c/0xb0)
[<c105ca6c>] (dump_stack) from [<c02fdaec>] (print_address_description+0x68/0x250)
[<c02fda84>] (print_address_description) from [<c02fd4ac>] (kasan_report_invalid_free+0x68/0x88)
[<c02fd444>] (kasan_report_invalid_free) from [<c02fc85c>] (__kasan_slab_free+0x1f4/0x200)
[<c02fc668>] (__kasan_slab_free) from [<c02fd0c0>] (kasan_slab_free+0x14/0x18)
[<c02fd0ac>] (kasan_slab_free) from [<c02f9c6c>] (kfree+0x90/0x294)
[<c02f9bdc>] (kfree) from [<c0b41bbc>] (__hwmon_device_register+0x5dc/0xa7c)
[<c0b415e0>] (__hwmon_device_register) from [<c0b421e8>] (hwmon_device_register_with_info+0xa0/0xa8)
[<c0b42148>] (hwmon_device_register_with_info) from [<c0b42324>] (devm_hwmon_device_register_with_info+0x74/0xb4)
[<c0b422b0>] (devm_hwmon_device_register_with_info) from [<c0b4481c>] (lm90_probe+0x414/0x578)
[<c0b44408>] (lm90_probe) from [<c0aeeff4>] (i2c_device_probe+0x35c/0x384)
[<c0aeec98>] (i2c_device_probe) from [<c08776cc>] (really_probe+0x290/0x3e4)
[<c087743c>] (really_probe) from [<c0877a2c>] (driver_probe_device+0x80/0x1c4)
[<c08779ac>] (driver_probe_device) from [<c0877da8>] (__device_attach_driver+0x104/0x11c)
[<c0877ca4>] (__device_attach_driver) from [<c0874dd8>] (bus_for_each_drv+0xa4/0xc8)
[<c0874d34>] (bus_for_each_drv) from [<c08773b0>] (__device_attach+0xf0/0x15c)
[<c08772c0>] (__device_attach) from [<c0877e24>] (device_initial_probe+0x1c/0x20)
[<c0877e08>] (device_initial_probe) from [<c08762f4>] (bus_probe_device+0xdc/0xec)
[<c0876218>] (bus_probe_device) from [<c0876a08>] (deferred_probe_work_func+0xa8/0xd4)
[<c0876960>] (deferred_probe_work_func) from [<c01527c4>] (process_one_work+0x3dc/0x96c)
[<c01523e8>] (process_one_work) from [<c01541e0>] (worker_thread+0x4ec/0x8bc)
[<c0153cf4>] (worker_thread) from [<c015b238>] (kthread+0x230/0x240)
[<c015b008>] (kthread) from [<c01010bc>] (ret_from_fork+0x14/0x38)
Exception stack(0xcf743fb0 to 0xcf743ff8)
3fa0:                                     00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000

Allocated by task 132:
 kasan_kmalloc.part.1+0x58/0xf4
 kasan_kmalloc+0x90/0xa4
 kmem_cache_alloc_trace+0x90/0x2a0
 __hwmon_device_register+0xbc/0xa7c
 hwmon_device_register_with_info+0xa0/0xa8
 devm_hwmon_device_register_with_info+0x74/0xb4
 lm90_probe+0x414/0x578
 i2c_device_probe+0x35c/0x384
 really_probe+0x290/0x3e4
 driver_probe_device+0x80/0x1c4
 __device_attach_driver+0x104/0x11c
 bus_for_each_drv+0xa4/0xc8
 __device_attach+0xf0/0x15c
 device_initial_probe+0x1c/0x20
 bus_probe_device+0xdc/0xec
 deferred_probe_work_func+0xa8/0xd4
 process_one_work+0x3dc/0x96c
 worker_thread+0x4ec/0x8bc
 kthread+0x230/0x240
 ret_from_fork+0x14/0x38
   (null)

Freed by task 132:
 __kasan_slab_free+0x12c/0x200
 kasan_slab_free+0x14/0x18
 kfree+0x90/0x294
 hwmon_dev_release+0x1c/0x20
 device_release+0x4c/0xe8
 kobject_put+0xac/0x11c
 device_unregister+0x2c/0x30
 __hwmon_device_register+0xa58/0xa7c
 hwmon_device_register_with_info+0xa0/0xa8
 devm_hwmon_device_register_with_info+0x74/0xb4
 lm90_probe+0x414/0x578
 i2c_device_probe+0x35c/0x384
 really_probe+0x290/0x3e4
 driver_probe_device+0x80/0x1c4
 __device_attach_driver+0x104/0x11c
 bus_for_each_drv+0xa4/0xc8
 __device_attach+0xf0/0x15c
 device_initial_probe+0x1c/0x20
 bus_probe_device+0xdc/0xec
 deferred_probe_work_func+0xa8/0xd4
 process_one_work+0x3dc/0x96c
 worker_thread+0x4ec/0x8bc
 kthread+0x230/0x240
 ret_from_fork+0x14/0x38
   (null)

Cc: <stable@vger.kernel.org> # v4.15+
Fixes: 47c332de ("hwmon: Deal with errors from the thermal subsystem")
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 95dcd64bc5a27080beaa344edfe5bdcca3d2e7dc ]

Technically this is not required because disabling the PWM should be
enough. However, when support for atomic operations was implemented in
the PWM subsystem, only actual changes to the PWM channel are applied
during pwm_config(), which means that during after resume from suspend
the old settings won't be applied.

One possible solution is for the PWM driver to implement its own PM
operations such that settings from before suspend get applied on resume.
This has the disadvantage of completely ignoring any particular ordering
requirements that PWM user drivers might have, so it is best to leave it
up to the user drivers to apply the settings that they want at the
appropriate time.

Another way to solve this would be to read back the current state of the
PWM at the time of resume. That way, in case the configuration was lost
during suspend, applying the old settings in PWM user drivers would
actually get them applied because they differ from the current settings.
However, not all PWM drivers support reading the hardware state, and not
all hardware may support it.

The best workaround at this point seems to be to let PWM user drivers
tell the PWM subsystem that the PWM is turned off by, in addition to
disabling it, also setting the duty cycle to 0. This causes the resume
operation to apply a configuration that is different from the current
configuration, resulting in the proper state from before suspend getting
restored.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7c6a55606b5c46b449d76588968b4d8caae903f upstream.

Devices with compatible="pmbus" field have zero initial page count,
and pmbus_clear_faults() being called before the page count auto-
detection does not actually clear faults because it depends on the
page count. Non-cleared faults in its turn may fail the subsequent
page count auto-detection.

This patch fixes this problem by calling pmbus_clear_fault_page()
for currently set page and calling pmbus_clear_faults() after the
page count was detected.

Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Bazhenov <bazhenov.dn@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As done treewide earlier, this catches several more open-coded
allocation size calculations that were added to the kernel during the
merge window. This performs the following mechanical transformations
using Coccinelle:

	kvmalloc(a * b, ...) -> kvmalloc_array(a, b, ...)
	kvzalloc(a * b, ...) -> kvcalloc(a, b, ...)
	devm_kzalloc(..., a * b, ...) -> devm_kcalloc(..., a, b, ...)
Signed-off-by: NKees Cook <keescook@chromium.org>

The documented register to retrieve the fan RPM for fan7 is found
to be unreliable at least with NCT6796D revision 3. Let's use
register 0x4ce instead. This is undocumented for NCT6796D, but
documented for NCT6797D and NCT6798D and known to be working.
Reported-by: NRobert Kern <ulteq@web.de>
Cc: Robert Kern <ulteq@web.de>
Fixes: 81820059 ("hwmon: (nct6775) Add support for NCT6796D")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

fan7 on NCT6796D does not have a fan count register; it only has an RPM
register. Switch to using RPM registers to read the fan speed for all
chips supporting it to solve the problem for good.
Reported-by: NRobert Kern <ulteq@web.de>
Cc: Robert Kern <ulteq@web.de>
Fixes: 81820059 ("hwmon: (nct6775) Add support for NCT6796D")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The following kernel log message is reported for the nct6775 driver
on ASUS WS X299 SAGE.

nct6775: Found NCT6796D or compatible chip at 0x2e:0x290
nct6775 nct6775.656: Invalid temperature source 11 at index 0,
			source register 0x100, temp register 0x73
nct6775 nct6775.656: Invalid temperature source 11 at index 2,
			source register 0x300, temp register 0x77
nct6775 nct6775.656: Invalid temperature source 11 at index 3,
			source register 0x800, temp register 0x79
nct6775 nct6775.656: Invalid temperature source 11 at index 4,
			source register 0x900, temp register 0x7b

A recent version of the datasheet lists temperature source 11 as reserved.
However, an older version of the datasheet lists temperature sources 10
and 11 as supported virtual temperature sources. Apparently the older
version of the datasheet is correct, so list those temperature sources
as supported.

Virtual temperature sources are different than other temperature sources:
Values are not read from a temperature sensor, but written either from
BIOS or an embedded controller. As such, each virtual temperature has to
be reported. Since there is now more than one temperature source, we have
to keep virtual temperature sources in a chip-specific mask and can no
longer rely on the assumption that there is only one virtual temperature
source with a fixed index. This accounts for most of the complexity of this
patch.
Reported-by: NRobert Kern <ulteq@web.de>
Cc: Robert Kern <ulteq@web.de>
Fixes: 81820059 ("hwmon: (nct6775) Add support for NCT6796D")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Not all fans have a fan pulse register. This can result in reading
beyond the end of REG_FAN_PULSES and FAN_PULSE_SHIFT arrays,
and was reported by smatch as possible error.

1672          for (i = 0; i < ARRAY_SIZE(data->rpm); i++) {
                              ^^^^^^^^^^^^^^^^^^^^^^^^
			      This is a 7 element array.
...
1685                  data->fan_pulses[i] =
1686                    (nct6775_read_value(data, data->REG_FAN_PULSES[i])
1687                          >> data->FAN_PULSE_SHIFT[i]) & 0x03;
                                 ^^^^^^^^^^^^^^^^^^^^^^^^
				 FAN_PULSE_SHIFT is either 5 or 6
				 elements.

To fix the problem, we have to ensure that all REG_FAN_PULSES and
FAN_PULSE_SHIFT have the appropriate length, and that REG_FAN_PULSES
is only read if the register actually exists.

Fixes: 6c009501 ("hwmon: (nct6775) Add support for NCT6102D/6106D")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

This is dead code because j can never be 1 at this point.  We had
intended to just test if the bit was clear.

Fixes: bbd8decd ("hwmon: (nct6775) Add support for weighted fan control")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The raspberrypi-hwmon driver doesn't automatically load, although it does work
when loaded, by adding the alias it auto loads as expected when built as a
module. Tested on RPi2/RPi3 on 32 bit kernel and RPi3B+ on aarch64 with
Fedora 28 and a patched 4.18 RC kernel.

Fixes: 3c493c885cf ("hwmon: Add support for RPi voltage sensor")
Signed-off-by: NPeter Robinson <pbrobinson@gmail.com>
CC: Stefan Wahren <stefan.wahren@i2se.com>
CC: Eric Anholt <eric@anholt.net>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

val can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

vers/hwmon/nct6775.c:2698 store_pwm_weight_temp_sel() warn: potential
spectre issue 'data->temp_src' [r]

Fix this by sanitizing val before using it to index data->temp_src

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The adt7475_read_word() function was meant to return negative error
codes on failure.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NTokunori Ikegami <ikegami@allied-telesis.co.jp>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The adt7475_update_device() function returns error pointers.  The
problem is that in show_pwmfreq() we dereference it before the check.
And then in pwm_use_point2_pwm_at_crit_show() there isn't a check at
all.  I don't know if it's required, but it silences a static checker
warning and it's doesn't hurt anything to check.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NTokunori Ikegami <ikegami@allied-telesis.co.jp>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

fix the sysfs shunt resistor read access: return the shunt resistor
value, not the calibration register contents.

update email address
Signed-off-by: NLothar Felten <lothar.felten@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Change update device function to return an error pointer if needed,
and report the error to user space.
Signed-off-by: NTokunori Ikegami <ikegami@allied-telesis.co.jp>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
[groeck: Clarified/updated description]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

I2C SMBus sometimes returns error codes.
In the error case, measurement values are updated incorrectly.
The sensor application then generates warning log messages and SNMP traps.
To prevent this, add error handling into the update functions.
Signed-off-by: NTokunori Ikegami <ikegami@allied-telesis.co.jp>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
[groeck: Update description]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>