Adding support for G761 included adding support for an internal clock.
Enabling the internal clock requires setting a bit in the FAN_CMD2
register. This is implemented in g762_fan_init(). However, g762_fan_init()
is called before clock support is selected, and the flag indicating that
the internal clock should be used is not yet set.
Initialize the clock before initializing the fan to solve the problem.
While at it, also add "g7621" to the i2c_device_id array.
Cc: Christian Marangi <ansuelsmth@gmail.com>
Fixes: 6ce402327a ("hwmon: g672: add support for g761")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
AMC6821 supports configuring if a fan is DC or PWM controlled.
Add support for the pwm1_mode attribute to make it runtime configurable.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Convert to use with_info API to simplify the code and make it easier
to maintain. This also reduces code size by approximately 20%.
No functional change intended.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use regmap for register accesses and caching.
While at it, use sysfs_emit() instead of sprintf() to write sysfs
attribute data, and remove spurious debug messages which would only
be seen as result of a bug in the code. Also make sure that error
codes are propagated and not replaced with -EIO.
While at it, introduce rounding of written temperature values and for
internal calculations to reduce deviation from written values and as
much as possible.
No functional change intended except for differences introduced by
rounding.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver only supports a single chip, so an enum
to determine the chip type is unnecessary. Drop it.
No functional change intended.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use BIT() and GENMASK() for bit and mask definitions
to help distinguish bit and mask definitions from other
defines and to make the code easier to read.
No functional change intended.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Using tabs for column alignment makes the code easier to read.
No functional change intended.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reorder include files to alphabetic order to simplify maintenance,
and drop the unnecessary kernel.h include.
No functional change intended.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
After setting fan1_target and setting pwm1_enable to 4,
the fan controller tries to achieve the requested fan speed.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The chip does not have a fan divisor. What it does have is a configuration
to set either 2 or 4 pulses per fan rotation. Rename the attribute to
reflect its use. Update documentation accordingly.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The default value of the maximum fan speed limit register is 0,
essentially translating to an unlimited fan speed. When reading
the limit, a value of 0 is reported in this case. However, writing
a value of 0 results in writing a value of 0xffff into the register,
which is inconsistent.
To solve the problem, permit writing a limit of 0 for the maximim fan
speed, effectively translating to "no limit". Write 0 into the register
if a limit value of 0 is written. Otherwise limit the range to
<1..6000000> and write 1..0xffff into the register. This ensures that
reading and writing from and to a limit register return the same value
while at the same time not changing reported values when reading the
speed or limits.
While at it, restrict fan limit writes to non-negative numbers; writing
a negative limit does not make sense and should be reported instead of
being corrected.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The pwm value range is well defined from 0..255. Don't accept any values
outside this range.
This changes the valid range of pwm1_auto_point2_pwm from 0..254 to 0..255,
meaning it can now be equivalent to not only pwm1_auto_point1_pwm (which is
always 0) but also to pwm1_auto_point3_pwm (which is always 255). While
that may not be practical, there seems to be no technical reason for
preventing a user from doing it.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
LTC2991_T_INT_CH_NR is 4. The st->temp_en[] array has LTC2991_MAX_CHANNEL
(4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we
have read one element beyond the end of the array. Flip the conditions
around so that we check if "channel" is valid before using it as an array
index.
Fixes: 2b9ea4262a ("hwmon: Add driver for ltc2991")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/Zoa9Y_UMY4_ROfhF@stanley.mountain
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Configuration register bit 5 must read 0 for all JC42.4 compliant chips.
Several capability register bits must be set for all TSE2004 compliant
chips. Use that information to strengthen the detect function.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
TSE2004av standardizes the device ID of compliant temperature sensors to
be 0x22xx, where xx is the device revision. Use a single define for all
TSE2004av compliant temperature sensors, and relax the device id mask to
match the upper 8 bit of the device id register.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The SPD5118 specification says, in its documentation of the page bits
in the MR11 register:
"
This register only applies to non-volatile memory (1024) Bytes) access of
SPD5 Hub device.
For volatile memory access, this register must be programmed to '000'.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"
Renesas/ITD SPD5118 hub controllers take this literally and disable access
to volatile memory if the page selected in MR11 is != 0. Since the BIOS or
ROMMON will access the non-volatile memory and likely select a page != 0,
this means that the driver will not instantiate since it can not identify
the chip. Even if the driver instantiates, access to volatile registers
is blocked after a nvram read operation which selects a page other than 0.
To solve the problem, add initialization code to select page 0 during
probe. Before doing that, use basic validation to ensure that this is
really a SPD5118 device and not some random EEPROM.
Cc: Sasha Kozachuk <skozachuk@google.com>
Cc: John Hamrick <johnham@google.com>
Cc: Chris Sarra <chrissarra@google.com>
Tested-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Using regmap for paging significantly improves caching since the regmap
cache no longer needs to be cleared after changing the page, so let's
use it.
Suggested-by: Armin Wolf <W_Armin@gmx.de>
Tested-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The INA230 has an Alert pin which is asserted when the alert
function selected in the Mask/Enable register exceeds the
value programmed into the Alert Limit register. Assertion is based
on the Alert Polarity Bit (APOL, bit 1 of the Mask/Enable register).
It is default set to value 0 i.e Normal (active-low open collector).
However, hardware can be designed in such a way that expects Alert pin
to become active high if a user-defined threshold in Alert limit
register has been exceeded. This patch adds a way to pass alert polarity
value to the driver via device tree.
Signed-off-by: Amna Waseem <Amna.Waseem@axis.com>
Link: https://lore.kernel.org/r/20240611-apol-ina2xx-fix-v4-2-8df1d2282fc5@axis.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a property to the binding to configure the Alert Polarity.
Alert pin is asserted based on the value of Alert Polarity bit of
Mask/Enable register. It is by default 0 which means Alert pin is
configured to be active low open collector. Value of 1 maps to
Inverted (active high open collector).
Signed-off-by: Amna Waseem <Amna.Waseem@axis.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240603-apol-ina2xx-fix-v3-1-b9eff3158e4e@axis.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit ac0c26bae6 ("hwmon: (lm25066) Use i2c_get_match_data()") changed
enum chips to start with 1 instead of 0, under the assumption that
the data pointer in of_device_id must not start with 0 (NULL) if
i2c_get_match_data() is used. However, that is perfectly fine as long as
there is also an i2c_device_id array with the same data which is used
as fallback in that case.
Let enum chips start with 0 to avoid confusion against other drivers
where the enum starts with 0 and i2c_get_match_data() is used as well.
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit 10a0575ea0 ("hwmon: (nct6775-i2c) Use i2c_get_match_data()")
introduced calling i2c_get_match_data() to the nct6775 driver. As part
of that commit, enum kinds was changed to start with 1, based on
Adjust the 'kinds' enum to not use 0, so that no match data can be
distinguished from a valid enum value.
The patch had to be fixed later with commit 2792fc8f8c ("hwmon:
(nct6775-core) Explicitly initialize nct6775_device_names indexes") and
commit efe86092ab ("hwmon: (nct6775-platform) Explicitly initialize
nct6775_sio_names indexes").
Various patches submitted later show that the change from 0 to 1 is
not really necessary. As it turns out, it is perfectly fine as long as
there is an i2c_device_id array with the same data as in the of_device_id
array. This data is used as fallback if the data pointer in struct
of_device_id is NULL (0).
Let enum chips start with 0 to avoid confusion against other drivers
where the enum starts with 0 and i2c_get_match_data() is used as well.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Earlier it was assumed that the data pointer in of_device_id must not start
with 0 (NULL) if i2c_get_match_data() is used. However, it turns out that
this is perfectly fine as long as there is also an i2c_device_id array with
the same data, which is used as fallback in that case.
Let enum chips start with 0 to avoid confusion against other drivers
where the enum starts with 0 and i2c_get_match_data() is used as well.
While doing that, remove chip_id from struct mp2856_data since it is only
used in the probe function, and typecast the result of i2c_get_match_data()
to kernel_ulong_t to avoid the double typecast.
Cc: Peter Yin <peteryin.openbmc@gmail.com>
Cc: Potin Lai <potin.lai.pt@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If a driver calls device_get_match_data(), the .data pointer in its id
data structures must not be NULL/0 because device_get_match_data()
returns NULL if an entry is not found. Explain that in a comment to avoid
confusion why this is required in this driver but not in other drivers.
Cc: Daniel Matyas <daniel.matyas@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
With SPD5118 chip detection for the most part handled by the i2c-smbus
core using DMI information, the spd5118 driver no longer needs to
auto-detect spd5118 compliant chips.
Auto-detection by the driver is still needed on systems with no DMI support
or on systems with more than eight DIMMs and can not be removed entirely.
However, it affects boot time and introduces the risk of mis-identifying
chips. Add configuration option to be able to disable it on systems where
chip detection is handled outside the driver.
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Tested-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
