IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We don't want to support the obsolete 'alarms' attribute for new
chips supported by this driver. Add flag to indicate 'alarms' attribute
support and use it for existing chips. This flag will not be set for
additional chips supported by this driver in the future.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When support for G781 was added, chips with ID 0x01 were found at I2C
addresses 0x4c and 0x4d. The G781 datasheet (version 1.3 from October 2003)
says that the device ID for G781-1 is 0x03, not 0x01. Also, the datasheet
states that the chip at I2C address is G781 and the chip at I2C address
0x4d is G781-1.
A G781-1 at I2C address 0x4d was now found to have a chip ID of 0x03
as suggested by the datasheet. Accept both 0x01 and 0x03 chip IDs at both
addresses to ensure that all variants of G781 are detected properly.
While at it, improve chip detection accuracy by reading two additional
registers and ensuring that only expected bits are set in those registers.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The NCT1008 datasheet, Revision 3, states that its chip revision is
0x57. This matches the ADT7461A chip revision, and NCT1008 is therefore
detected as ADT7461A. In revision 6 of the datasheet, the chip revision
register is no longer documented. Multiple samples of NCT1008 were found
to report a chip revision of 0x54. As it turns out, one of the patches
submitted to add NCT1008 support to the lm90 driver already included a
check for chip revision 0x54. Unfortunately, that patch never made it into
the kernel. Remedy the situation and explicitly detect chips with revision
0x54 as NCT1008.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The detect function is getting larger and larger and difficult to
understand or review. Split it into per-manufacturer detect functions
to improve readability.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since temperature conversion functions are now unified, there is no need
to keep "the chip supports a configurable extended temperature range" and
"the chip has extended temperature range enabled" flags separate.
Use a single flag instead to reflect both.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
While most LM90 compatible chips support a temperature sensor resolution
of 11 bit, this is not the case for all chips. ADT7461 only supports a
resolution of 10 bit, and TMP451/TMP461 support a resolution of 12 bit.
Add support for various temperature sensor resolutions. To do this,
model all temperature sensors as 16 bit sensors, and use unified
temperature conversion functions which take the sensor resolution
as parameter.
While enhancing functionality, this has the positive side effect of
reducing code size by about 5%.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When reading 16-bit volatile registers, the code uses a trick to
determine if a temperature is consistent: It reads the high part
of the register twice. If the values are the same, the code assumes
that the reading is consistent. If the value differs, the code
re-reads the second register as well and assumes that it now has
correct values.
This is only necessary for volatile registers. Add a parameter to
lm90_read16() to indicate if the register is volatile to avoid the
extra overhead for non-volatile registers.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ADT7461 and TMP451 temperature sensors support extended temperature ranges.
If standard temperature range is selected, the temperature range is
unsigned and limited to 0 .. 127 degrees C. For TMP461, the standard
temperature range is -128000 ... 127000 degrees C. Distinguish between
the two chips by introducing a feature flag indicating if the standard
temperature range is signed or unsigned. Use the same flag for MAX6646/
MAX6647 as well since those chips also support unsigned temperatures.
Note that while the datasheet for ADT7461 suggests that the default
temperature range is unsigned, tests with a real chip suggest that this
is not the case: If the temperature offset is set to a value << 0,
the temperature register does report negative values.
Tests with real chips show that MAX6680/MAX6681 and SA56004 report
temperatures of 128 degrees C and higher as negative temperatures.
Add respective comments to the code.
Also use clamp_val() and DIV_ROUND_CLOSEST where appropriate in
calculations.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Experiments show that ADT7461A and NCT1008 support PEC, even though it is
not documented. Enable support for it in the driver. Since ADT7461 only
supports partial PEC, this means that the configuration for ADT7461A
needs to be separated from ADT7461.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Revision 0 of the ADT7461 datasheet suggests that the chip supports PEC
(packet error checking). This information is gone in later versions of the
datasheet. Experiments show that PEC support on ADT7461 is similar to PEC
support in ADM1032, ie it is only supported for read operations. Add
support for it to the driver.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
PEC (packet error checking) support for ADM1032 is currently only enabled
if the chip was auto-detected, but not if a chip is instantiated
explicitly. Always enable PEC support by introducing a chip feature flag
indicating partial PEC support. Also, for consistency, disable PEC support
by default to match existing functionality if the chip was not auto-
detected.
At the same time, introduce generic support for PEC with a separate feature
flag. This will be used when support for chips with full PEC functionality
is added.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The register write address either matches the read address, or it is the
read address plus 6. Simplify the code and resolve the write address
programmatically instead of having two defines for each register.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Handling bit shifts necessary to extract status bits during compile time
reduces code and data size by almost 5% when building for x86_64.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reorder chip enumeration in alphabetical order to make it easier to
see which chips are supported, and to clarify where to add support
new chip types. No functional change.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reorder include files in alphabetical order to reduce the chance of
duplicates and to make it clear where new include files should be
added. Drop the unnecessary include of linux/sysfs.h. Include
linux/device.h instead because that is what is actually used.
No functional change.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Many chips supported by this driver clear status registers after it
is read and update it in the next measurement cycle. Normally this falls
under the radar because all registers are only read once per measurement
cycle. However, there is an exception: Status registers are always read
during interrupt and laert handling. This can result in invalid status
reports if userspace reads an alarm attribute immediately afterwards.
Rework alarm/status handling by keeping a shadow register with 'current'
alarms, and by ensuring that the register is either only updated once per
measurement cycle or not cleared.
A second problem is related to alert handling: Alert handling is disabled
for chips with broken alert after an alert was reported, but only
re-enabled if attributes are read by the user. This means that alert
conditions may appear and disappear unnoticed. Remedy the situation
by introducing a worker to periodically read the status register(s) while
alert handling is disabled, and re-enable alerts after the alert condition
clears.
Yet another problem is that sysfs and udev events are currently only
reported to userspace if an alarm is raised, but not if an alarm condition
clears. Use the new worker to detect that situation and also generate
sysfs and udev events in that case.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
So far the driver only generated sysfs and udev events for minimum and
maximum alarms. Also generate events for critical and emergency alarms.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some lm90 compatible devices can operate in an extended temperature mode.
This feature is now enabled if the property is set in the corresponding
device tree node.
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220517135614.8185-2-holger.brunck@hitachienergy.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
sysfs and udev notifications need to be sent to the _alarm
attributes, not to the value attributes.
Fixes: 94dbd23ed88c ("hwmon: (lm90) Use hwmon_notify_event()")
Cc: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Experiments with MAX6646 and MAX6648 show that the alert function of those
chips is broken, similar to other chips supported by the lm90 driver.
Mark it accordingly.
Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Experiments with MAX6680 and MAX6681 show that the alert function of those
chips is broken, similar to other chips supported by the lm90 driver.
Mark it accordingly.
Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Experiments with MAX6654 show that its alert function is broken,
similar to other chips supported by the lm90 driver. Mark it accordingly.
Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver")
Cc: Josh Lehan <krellan@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If alert handling is broken, interrupts are disabled after an alert and
re-enabled after the alert clears. However, if there is an interrupt
handler, this does not apply if alerts were originally disabled and enabled
when the driver was loaded. In that case, interrupts will stay disabled
after an alert was handled though the alert handler even after the alert
condition clears. Address the situation by always re-enabling interrupts
after the alert condition clears if there is an interrupt handler.
Fixes: 2abdc357c55d9 ("hwmon: (lm90) Unmask hardware interrupt")
Cc: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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: ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781")
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>
Tests with a real chip and a closer look into the datasheet show that
MAX6654 does not support CRIT/THERM/OVERTEMP limits, so drop support
of the respective attributes for this chip.
Introduce LM90_HAVE_CRIT flag and use it to instantiate critical limit
attributes to solve the problem.
Cc: Josh Lehan <krellan@google.com>
Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of
temperature calculations") addressed a number of underflow situations
when writing temperature limits. However, it missed one situation, seen
when an attempt is made to set the hysteresis value to MAX_LONG and the
critical temperature limit is negative.
Use clamp_val() when setting the hysteresis temperature to ensure that
the provided value can never overflow or underflow.
Fixes: b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of temperature calculations")
Cc: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The detect function had a comment "Make compiler happy" when id did not
read the second configuration register. As it turns out, the code was
checking the contents of this register for manufacturer ID 0xA1 (NXP
Semiconductor/Philips), but never actually read the register. So it
wasn't surprising that the compiler complained, and it indeed had a point.
Fix the code to read the register contents for manufacturer ID 0xa1.
At the same time, the code was reading the register for manufacturer ID
0x41 (Analog Devices), but it was not using the results. In effect it was
just checking if reading the register returned an error. That doesn't
really add much if any value, so stop doing that.
Fixes: f90be42fb383 ("hwmon: (lm90) Refactor reading of config2 register")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
TMP461 is almost identical to TMP451 and was actually detected as TMP451
with the existing lm90 driver if its I2C address is 0x4c. Add support
for it to the lm90 driver. At the same time, improve the chip detection
function to at least try to distinguish between TMP451 and TMP461.
As a side effect, this fixes commit 24333ac26d01 ("hwmon: (tmp401) use
smb word operations instead of 2 smb byte operations"). TMP461 does not
support word operations on temperature registers, which causes bad
temperature readings with the tmp401 driver. The lm90 driver does not
perform word operations on temperature registers and thus does not have
this problem.
Support is listed as basic because TMP461 supports a sensor resolution
of 0.0625 degrees C, while the lm90 driver assumes a resolution of 0.125
degrees C. Also, the TMP461 supports negative temperatures with its
default temperature range, which is not the case for similar chips
supported by the lm90 and the tmp401 drivers. Those limitations will be
addressed with follow-up patches.
Fixes: 24333ac26d01 ("hwmon: (tmp401) use smb word operations instead of 2 smb byte operations")
Reported-by: David T. Wilson <david.wilson@nasa.gov>
Cc: David T. Wilson <david.wilson@nasa.gov>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
A flag indicating extended temperature support makes it easier
to add support for additional chips with this functionality.
Cc: David T. Wilson <david.wilson@nasa.gov>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The min/max/crit and all other temperature values that are passed to
the driver are unlimited and value that is close to INT_MIN results in
integer underflow of the temperature calculations made by the driver
for LM99 sensor. Temperature hysteresis is among those values that need
to be limited, but limiting of hysteresis is independent from the sensor
version. Add the missing limits.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210623042231.16008-2-digetx@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
I2C accesses are prohibited and will error out after suspending of the
I2C controller, hence we need to ensure that interrupt won't fire on
suspend when it's too late. Disable interrupt across suspend/resume.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ALERT interrupt is enabled by default after power-on, but it could
be masked by bootloader. For example this is the case on Acer A500 tablet
device. Unmask the hardware interrupt if interrupt is provided.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use hwmon_notify_event() to notify userspace and thermal core about
temperature changes.
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The lm90 driver sets interrupt trigger type to level-low. This type is
not suitable for sensors like NCT1008 that don't deassert interrupt line
until temperature is back to normal, resulting in interrupt storm. The
appropriate trigger type should come from OF device description and
currently it's overridden by the driver's trigger type. Don't specify
the trigger type in the driver code, letting interrupt core to use the
device-specific trigger type.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Many hwmon drivers don't use the id information provided by the old
i2c probe function, and the remainder can easily be adapted to the new
form ("probe_new") by calling i2c_match_id explicitly.
This avoids scanning the identifier tables during probes.
Drivers which didn't use the id are converted as-is; drivers which did
are modified as follows:
* if the information in i2c_client is sufficient, that's used instead
(client->name);
* anything else is handled by calling i2c_match_id() with the same
level of error-handling (if any) as before.
A few drivers aren't included in this patch because they have a
different set of maintainers. They will be covered by other patches.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200813160222.1503401-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the Maxim MAX6654 to the lm90 driver.
The MAX6654 is a temperature sensor, similar to the others,
but with some differences regarding the configuration
register, and the sampling rate at which extended resolution
becomes possible.
Signed-off-by: Josh Lehan <krellan@google.com>
Link: https://lore.kernel.org/r/20200513184248.145765-1-krellan@google.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The code to update the configuration register is repeated several times.
Move it into a separate function. At the same time, un-inline
lm90_select_remote_channel() and leave it up to the compiler to decide
what to do with it. Also remove the 'client' argument from
lm90_select_remote_channel() and from lm90_write_convrate() and take
it from struct lm90_data instead where needed.
This patch reduces code size by more than 800 bytes on x86_64.
Cc: Boyang Yu <byu@arista.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The configuration register does not change on its own. Yet, it is read
in various locations, modified, and written back. Simplify and optimize
the code by caching its value and by only writing it back when needed.
Cc: Boyang Yu <byu@arista.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
max6658 may report unrealistically high temperature during
the driver initialization, for which, its overtemp alarm pin
also gets asserted. For certain devices implementing overtemp
protection based on that pin, it may further trigger a reset to
the device. By reproducing the problem, the wrong reading is
found to be coincident with changing the conversion rate.
To mitigate this issue, set the stop bit before changing the
conversion rate and unset it thereafter. After such change, the
wrong reading is not reproduced. Apply this change only to the
max6657 kind for now, controlled by flag LM90_PAUSE_ON_CONFIG.
Signed-off-by: Boyang Yu <byu@arista.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.
Reported-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
675 mass ave cambridge ma 02139 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 441 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520071858.739733335@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If CONFIG_OF is not enabled, the following build warning is observed.
drivers/hwmon/lm90.c:239:34: warning:
‘lm90_of_match’ defined but not used
Mark lm90_of_match as __maybe_unused to fix the problem.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The HWMON_CHANNEL_INFO macro simplifies the code, reduces the likelihood
of errors, and makes the code easier to read.
The conversion was done automatically with coccinelle. The semantic patch
used to make this change is as follows.
@r@
initializer list elements;
identifier i;
@@
-u32 i[] = {
- elements,
- 0
-};
@s@
identifier r.i,j,ty;
@@
-struct hwmon_channel_info j = {
- .type = ty,
- .config = i,
-};
@script:ocaml t@
ty << s.ty;
elements << r.elements;
shorter;
elems;
@@
shorter :=
make_ident (List.hd(List.rev (Str.split (Str.regexp "_") ty)));
elems :=
make_ident
(String.concat ","
(List.map (fun x -> Printf.sprintf "\n\t\t\t %s" x)
(Str.split (Str.regexp " , ") elements)))
@@
identifier s.j,t.shorter;
identifier t.elems;
@@
- &j
+ HWMON_CHANNEL_INFO(shorter,elems)
This patch does not introduce functional changes. Many thanks to
Julia Lawall for providing the semantic patch.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace S_<PERMS> with octal values.
The conversion was done automatically with coccinelle. The semantic patches
and the scripts used to generate this commit log are available at
https://github.com/groeck/coccinelle-patches/hwmon/.
This patch does not introduce functional changes. It was verified by
compiling the old and new files and comparing text and data sizes.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use DEVICE_ATTR_RW for read/write attributes. This simplifies the source
code, improves readbility, and reduces the chance of inconsistencies.
The conversion was done automatically using coccinelle. It was validated
by compiling both the old and the new source code and comparing its text,
data, and bss size.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[groeck: Updated description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since commit commit eb1c8f4325d5 ("hwmon: (lm90) Convert to use new hwmon
registration API") the temp1_max_alarm and temp1_crit_alarm attributes are
mapped to the same alarm bit. Fix the typo.
Fixes: eb1c8f4325d5 ("hwmon: (lm90) Convert to use new hwmon registration API")
Signed-off-by: Micehael Walle <michael@walle.cc>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
