kernel.git/drivers/hwmon/max31790.c, branch linux-6.9.y

hwmon: Remove I2C_CLASS_HWMON from drivers w/o detect() and address_list

2024-02-11T21:43:08Z

Class-based I2C probing requires detect() and address_list to be set in the I2C client driver, see checks in i2c_detect(). It's misleading to declare I2C_CLASS_HWMON support if this precondition isn't met. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/75747c6a-d414-4b07-8f66-5a5cdddc3c36@gmail.com Signed-off-by: Guenter Roeck

hwmon: Switch i2c drivers back to use .probe()

2023-06-08T13:41:17Z

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230505131718.1210071-1-u.kleine-koenig@pengutronix.de [groeck: Added missing change in pmbus/acbel-fsg032.c] Signed-off-by: Guenter Roeck

hwmon: max31790: constify pointers to hwmon_channel_info

2023-04-19T14:08:37Z

Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Guenter Roeck

hwmon: (max31790) add fanN_enable

2022-09-19T13:17:05Z

The MAX31790 has a tach input enable bit in each fan's configuration register. This is only enabled by the driver if RPM mode is selected, but the driver doesn't provide a way to independently enable tachometer input regardless of the regulator mode. By adding the fanN_enable sysfs files, we can decouple the tach input from the regulator mode. Also update the documentation. Signed-off-by: Justin Ledford Link: https://lore.kernel.org/r/20220829195930.2521755-1-justinledford@google.com Signed-off-by: Guenter Roeck

hwmon: (max31790) Detect and report zero fan speed

2021-06-17T11:21:46Z

If a fan is not running or not connected, of if fan monitoring is disabled, the fan count register returns a fixed value of 0xffe0. So far this is then translated to a RPM value larger than 0. Since this is misleading and does not really make much sense, report a fan RPM of 0 in this situation. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Link: https://lore.kernel.org/r/20210526154022.3223012-7-linux@roeck-us.net

hwmon: (max31790) Clear fan fault after reporting it

2021-06-17T11:21:46Z

Fault bits in MAX31790 are sticky and have to be cleared explicitly. A write operation into either the 'Target Duty Cycle' register or the 'Target Count' register is necessary to clear a fault. At the same time, we can never clear cached fault status values before reading them because the companion fault status for any given fan is cleared as well when clearing a fault. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Link: https://lore.kernel.org/r/20210526154022.3223012-6-linux@roeck-us.net

hwmon: (max31790) Fix pwmX_enable attributes

2021-06-17T11:21:46Z

pwmX_enable supports three possible values: 0: Fan control disabled. Duty cycle is fixed to 0% 1: Fan control enabled, pwm mode. Duty cycle is determined by values written into Target Duty Cycle registers. 2: Fan control enabled, rpm mode Duty cycle is adjusted such that fan speed matches the values in Target Count registers The current code does not do this; instead, it mixes pwm control configuration with fan speed monitoring configuration. Worse, it reports that pwm control would be disabled (pwmX_enable==0) when it is in fact enabled in pwm mode. Part of the problem may be that the chip sets the "TACH input enable" bit on its own whenever the mode bit is set to RPM mode, but that doesn't mean that "TACH input enable" accurately reflects the pwm mode. Fix it up and only handle pwm control with the pwmX_enable attributes. In the documentation, clarify that disabling pwm control (pwmX_enable=0) sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN is set together with RPM_MODE. While at it, only update the configuration register if the configuration has changed, and only update the cached configuration if updating the chip configuration was successful. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Reviewed-by: Jan Kundrát Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net

hwmon: (max31790) Report correct current pwm duty cycles

2021-06-17T11:21:45Z

The MAX31790 has two sets of registers for pwm duty cycles, one to request a duty cycle and one to read the actual current duty cycle. Both do not have to be the same. When reporting the pwm duty cycle to the user, the actual pwm duty cycle from pwm duty cycle registers needs to be reported. When setting it, the pwm target duty cycle needs to be written. Since we don't know the actual pwm duty cycle after a target pwm duty cycle has been written, set the valid flag to false to indicate that actual pwm duty cycle should be read from the chip instead of using cached values. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Reviewed-by: Jan Kundrát Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net

hwmon: (max31790) Fix fan speed reporting for fan7..12

2021-06-17T11:21:45Z

Fans 7..12 do not have their own set of configuration registers. So far the code ignored that and read beyond the end of the configuration register range to get the tachometer period. This resulted in more or less random fan speed values for those fans. The datasheet is quite vague when it comes to defining the tachometer period for fans 7..12. Experiments confirm that the period is the same for both fans associated with a given set of configuration registers. Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API") Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790") Cc: Jan Kundrát Reviewed-by: Jan Kundrát Cc: Václav Kubernát Reviewed-by: Jan Kundrát Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net

hwmon: use simple i2c probe function

2020-09-23T16:42:39Z

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 Link: https://lore.kernel.org/r/20200813160222.1503401-1-steve@sk2.org Signed-off-by: Guenter Roeck