According to its datasheet, G781 supports a maximum conversion rate value
of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only
support a maximum conversion rate value of 7 (125 ms). On the other side,
chips labeled G781-1 and G784 were found to support a conversion rate value
of 8. There is no known means to distinguish G780 from G781 or G784; all
chips report the same manufacturer ID and chip revision.
Setting the conversion rate register value to 8 on chips not supporting
it causes unexpected behavior since the real conversion rate is set to 0
(16 seconds) if a value of 8 is written into the conversion rate register.
Limit the conversion rate register value to 7 for all G78x chips to avoid
the problem.
Fixes: ae544f64cc ("hwmon: (lm90) Add support for GMT G781")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-----BEGIN PGP SIGNATURE-----
iQHJBAABCgAzFiEEi8GdvG6xMhdgpu/4sUSA/TofvsgFAmHi+xgVHHl1cnkubm9y
b3ZAZ21haWwuY29tAAoJELFEgP06H77IxdoMAMf3E+L51Ys/4iAiyJQNVoT3aIBC
A8ZVOB9he1OA3o3wBNIRKmICHk+ovnfCWcXTr9fG/Ade2wJz88NAsGPQ1Phywb+s
iGlpySllFN72RT9ZqtJhLEzgoHHOL0CzTW07TN9GJy4gQA2h2G9CTP+OmsQdnVqE
m9Fn3PSlJ5lhzePlKfnln8rGZFgrriJakfEFPC79n/7an4+2Hvkb5rWigo7KQc4Z
9YNqYUcHWZFUgq80adxEb9LlbMXdD+Z/8fCjOrAatuwVkD4RDt6iKD0mFGjHXGL7
MZ9KRS8AfZXawmetk3jjtsV+/QkeS+Deuu7k0FoO0Th2QV7BGSDhsLXAS5By/MOC
nfSyHhnXHzCsBMyVNrJHmNhEZoN29+tRwI84JX9lWcf/OLANcCofnP6f2UIX7tZY
CAZAgVELp+0YQXdybrfzTQ8BT3TinjS/aZtCrYijRendI1GwUXcyl69vdOKqAHuk
5jy8k/xHyp+ZWu6v+PyAAAEGowY++qhL0fmszA==
=RKW4
-----END PGP SIGNATURE-----
Merge tag 'bitmap-5.17-rc1' of git://github.com/norov/linux
Pull bitmap updates from Yury Norov:
- introduce for_each_set_bitrange()
- use find_first_*_bit() instead of find_next_*_bit() where possible
- unify for_each_bit() macros
* tag 'bitmap-5.17-rc1' of git://github.com/norov/linux:
vsprintf: rework bitmap_list_string
lib: bitmap: add performance test for bitmap_print_to_pagebuf
bitmap: unify find_bit operations
mm/percpu: micro-optimize pcpu_is_populated()
Replace for_each_*_bit_from() with for_each_*_bit() where appropriate
find: micro-optimize for_each_{set,clear}_bit()
include/linux: move for_each_bit() macros from bitops.h to find.h
cpumask: replace cpumask_next_* with cpumask_first_* where appropriate
tools: sync tools/bitmap with mother linux
all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate
cpumask: use find_first_and_bit()
lib: add find_first_and_bit()
arch: remove GENERIC_FIND_FIRST_BIT entirely
include: move find.h from asm_generic to linux
bitops: move find_bit_*_le functions from le.h to find.h
bitops: protect find_first_{,zero}_bit properly
Remove PDE_DATA() completely and replace it with pde_data().
[akpm@linux-foundation.org: fix naming clash in drivers/nubus/proc.c]
[akpm@linux-foundation.org: now fix it properly]
Link: https://lkml.kernel.org/r/20211124081956.87711-2-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Alexey Gladkov <gladkov.alexey@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A couple of kernel functions call for_each_*_bit_from() with start
bit equal to 0. Replace them with for_each_*_bit().
No functional changes, but might improve on readability.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Don't populate the read-only array detect_fans_report on the stack but
instead it static const. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20220109194558.45811-1-colin.i.king@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fix warning when building with CONFIG_PM=n (and CONFIG_WERROR=y):
drivers/hwmon/nzxt-smart2.c:707:12: error: ‘nzxt_smart2_hid_reset_resume’
defined but not used [-Werror=unused-function]
707 | static int nzxt_smart2_hid_reset_resume(struct hid_device *hdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>
Link: https://lore.kernel.org/r/20211228014813.832491-1-mezin.alexander@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When desiring the whole struct to be packed, __packed
should be applied to the whole struct, not just
every struct member except the first one.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20211221162805.104202-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
WMI monitoring methods can be changed or removed in new ASUS boards
BIOS versions. Such versions return zero instead of a real one as
Chip ID.
Commit adds additional validation for the result of Chip ID call
before enabling access by ASUS WMI methods.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Link: https://lore.kernel.org/r/20211218205206.615865-1-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In the file mr75203.c we have a macro named POWER_DELAY_CYCLE_256,
the correct value should be 0x100. The register ip_tmr is expressed
in units of IP clk cycles, in accordance with the datasheet.
Typical power-up delays for Temperature Sensor are 256 cycles i.e. 0x100.
Fixes: 9d823351a3 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller")
Signed-off-by: Arseny Demidov <a.demidov@yadro.com>
Link: https://lore.kernel.org/r/20211219102239.1112-1-a.demidov@yadro.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The chip series supported by this driver are voltage regulators, so expose
them to the regulator subsystem.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20211213142814.264802-4-arthur.heymans@9elements.com
[groeck: Added brief patch description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The IR38060, IR38164 and IR38263 can be supported using this driver.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Arthur Heymans <arthur.heymans@9elements.com>
Link: https://lore.kernel.org/r/20211213142814.264802-2-arthur.heymans@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This driver implements monitoring and control of fans plugged into the
device. Besides typical speed monitoring and PWM duty cycle control,
voltage and current are reported for every fan.
The device also has 2 connectors for RGB LEDs, support for them isn't
implemented (mainly because there is no standardized sysfs interface).
Also, the device has a noise sensor, but the sensor seems to be completely
useless (and very imprecise), so support for it isn't implemented too.
The driver coexists with userspace tools that access the device through
hidraw interface with no known issues.
The driver has been tested on x86_64, built in and as a module.
Some changes/improvements were suggested by Jonas Malaco.
Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>
Link: https://lore.kernel.org/r/20211031033058.151014-1-mezin.alexander@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ASUS ROG STRIX B550-A/X570-I GAMING boards have got an nct6775 chip, but
by default there's no use of it because of resource conflict with WMI
method.
This commit adds "ROG STRIX B550-A GAMING" and "ROG STRIX X570-I GAMING" to
the list of boards that can be monitored using ASUS WMI.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Daniel Gibson <metalcaedes@gmail.com>
Tested-by: Michael Altizer <michael@theoddone.net>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Link: https://lore.kernel.org/r/20211211180037.367062-1-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This device is an integrated module of the Delta AHE-50DC Open19 power
shelf. I haven't been able to procure any proper documentation for
it, but it seems to be a (somewhat minimally) PMBus-compliant device.
It provides four fan speeds, four temperatures (three standard and one
manufacturer-specific via a virtual second page), and a vin reading.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20211208213703.2577-2-zev@bewilderbeest.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This adds the Samsung 1404-001221 NTC thermistor to the
NTC thermistor driver. As far as I can tell it is electrically
compatible with the Murata 47K NTC thermistor.
This thermistor is mounted in a variety of Samsung products.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211215174241.1496169-1-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver has been augmented to just use device properties
so the OF dependency can be dropped.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211215142933.1409324-1-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The only purpose of i8k_ioctl() is to call i8k_ioctl_unlocked()
with i8k_mutex held. Judging from the hwmon code, this mutex
only needs to be held when setting the fan speed/mode, so
the operation of I8K_SET_FAN is guaranteed to be atomic.
Unify both functions and reduce the locking of i8k_mutex
to I8K_SET_FAN.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20211211155422.16830-3-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The second switch-case has no real purpose:
- for I8K_BIOS_VERSION, val does not represent a return value,
making the check for error values unnecessary.
- for I8K_MACHINE_ID, val remains zero, so the error check is
unnecessary too.
Remove the switch-case and move the calls to copy_to_user()
into the first switch-case for I8K_BIOS_VERSION/_MACHINE_ID.
Omit buff[] since data->bios_machineid already contains the string
with the necessary zero padding through devm_kzalloc().
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20211211155422.16830-2-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Exit immediately if devm_hwmon_device_register_with_info()
fails since registering a delayed work whould be useless
in such a case anyway.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20211211184449.18211-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This code can fit on one line. No need to break it up.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211215114050.GB14967@kili
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This moves the device tree match data toward the end of the
driver which is the convention, here we can also add ACPI
and similar match data in a conforming manner.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211205235948.4167075-3-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This switches to retrieveing the configuration of the NTC
from generic firmware properties so that we get neutral from
device tree: now ACPI or, more importantly, software nodes
can be used to spawn NTC devices provided they have the
required properties.
This was inspired by the similar changes made to the IIO
drivers.
This was tested on the Ux500 HREF with the NTC devices
probing from device tree just as fine after this as before.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211206020423.62402-2-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Move the parsing of the DT config right above probe().
Allocate the state container for the driver in probe()
instead of inside the DT config parsing function: as a
result return an int instead of a pointer.
Drop the check for !np: we can only probe from DT right
now so no risk of ending up here.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211206020423.62402-1-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Variable range is being initialized with a value that is never read, it
is being re-assigned in the next statement. The assignment is redundant,
remove it and initialize range using the second assigned value. Clean up
the formatting too by adding missing spaces.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20211204233155.55454-1-colin.i.king@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Smatch detects this array overflow:
drivers/hwmon/asus_wmi_sensors.c:569 asus_wmi_configure_sensor_setup()
error: buffer overflow 'hwmon_attributes' 8 <= 9
The hwmon_attributes[] array should have "hwmon_max" so that it gets
larger when more attributes are added.
Fixes: 9d07e54a25b8 ("hwmon: (asus_wmi_sensors) Support X370 Asus WMI.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211130105117.GH5827@kili
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Smatch detected an array out of bounds error:
drivers/hwmon/asus_wmi_ec_sensors.c:562 asus_wmi_ec_configure_sensor_setup()
error: buffer overflow 'hwmon_attributes' 8 <= 9
The hwmon_attributes[] array needs to be declared with "hwmon_max"
elements.
Fixes: c04c7f7bfcbe ("hwmon: (asus_wmi_ec_sensors) Support B550 Asus WMI.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211130105034.GG5827@kili
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Allocate one state container for the device: struct ntc_data.
Move all items from struct ntc_thermistor_platform_data into
this struct and simplify.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-5-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The only possible assignment of a function to get a voltage to
convert to a resistance is to use the internal function
ntc_adc_iio_read() which is only available when using IIO
and OF.
Bite the bullet and mandate OF and IIO, drop the read_uv()
callback abstraction and some ifdefs.
As no board is using the platform data, all users are using
OF and IIO anyway.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-4-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Nothing in the kernel (this driver) is using the callback to
read ohms directly. We always read a voltage and convert it
to a resistance. Drop this callback.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-3-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Platform data is supposed to be used with "board files",
device descriptions in C. Since the introduction of the
NTC driver in 2011, no such platforms have been submitted
to the Linux kernel, and their use is strongly discouraged
in favor of Device Tree, ACPI or as last resort software
firmware nodes.
Drop the external header and copy the platform data into
the driver file.
Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-2-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The current driver can read the temperatures from upto 8 CCDs
(Core-Complex Die).
The newer AMD Family 19h Models 10h-1Fh and A0h-AFh can support up to
12 CCDs. Update the driver to read up to 12 CCDs.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163776976762.904164.5618896687524494215.stgit@bmoger-ubuntu
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Linux HWMON sensors driver for ASUS motherboards to read
sensors from the embedded controller.
Many ASUS motherboards do not publish all the available
sensors via the Super I/O chip but the missing ones are
available through the embedded controller (EC) registers.
This driver implements reading those sensor data via the
WMI method BREC, which is known to be present in all ASUS
motherboards based on the AMD 500 series chipsets (and
probably is available in other models too). The driver
needs to know exact register addresses for the sensors and
thus support for each motherboard has to be added explicitly.
The EC registers do not provide critical values for the
sensors and as such they are not published to the HWMON.
Supported motherboards:
* PRIME X570-PRO
* Pro WS X570-ACE
* ROG CROSSHAIR VIII HERO
* ROG CROSSHAIR VIII DARK HERO
* ROG CROSSHAIR VIII FORMULA
* ROG STRIX X570-E GAMING
* ROG STRIX B550-I GAMING
* ROG STRIX B550-E GAMING
Co-developed-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Tor Vic <torvic9@mailbox.org>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This adds hardware monitor support the Fintek F81966 Super I/O chip.
Testing was done on the Aaeon SSE-IPTI
Signed-off-by: Menghui Wu <Menghui_Wu@aaeon.com.tw>
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Link: https://lore.kernel.org/r/20211117024320.2428144-1-acelan.kao@canonical.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The adm1021 driver is quite generous with its automatic chip detection
and easily misdetects several chips. Strengthen detection of MAX1617,
MAX1617A, and LM84 to make the driver less vulnerable to false matches.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since we are using regmap access functions to write into chip registers,
we can hide the difference in register write addresses within regmap
code. By doing this we do not need to clear the regmap cache on register
writes, and the high level code does not need to bother about different
read/write register addresses.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use regmap for register accesses to be able to utilize its caching
functionality. This also lets us hide register access differences
in regmap code.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The new API is cleaner and reduces code size significantly.
All chip accesses are 'hidden' in chip access to prepare for using
regmap. Local caching code is removed, to be replaced by regmap based
caching in a follow-up patch.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The difference between TMP431 and other chips of this series is that the
TMP431 has an additional sensor. The register addresses for other sensors
are the same for all chips. It is therefore unnecessary to maintain two
different arrays for TMP431 and the other chips. Just use the same array
for all chips and add the TMP431 register addresses as third column.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The INA238 is a I2C power monitor similar to other INA2xx devices,
providing shunt voltage, bus voltage, current, power and temperature
measurements.
Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Link: https://lore.kernel.org/r/20211102052754.817220-3-nathan@nathanrossi.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Bit 7 of the status register indicates that the chip is busy
doing a conversion. It does not indicate an alarm status.
Stop reporting it as alarm status bit.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tests with a real chip and a closer look into the datasheet reveals
that the local and remote critical alarm status bits are swapped for
MAX6680/MAX6681.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
