Guenter Roeck [Thu, 27 Jun 2024 17:48:27 +0000 (10:48 -0700)]
hwmon: (amc6821) Convert to use regmap
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.
Guenter Roeck [Thu, 27 Jun 2024 16:46:12 +0000 (09:46 -0700)]
hwmon: (amc6821) Use BIT() and GENMASK()
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.
Guenter Roeck [Thu, 27 Jun 2024 14:05:35 +0000 (07:05 -0700)]
hwmon: (amc6821) Rename fan1_div to fan1_pulses
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.
Guenter Roeck [Thu, 27 Jun 2024 00:46:04 +0000 (17:46 -0700)]
hwmon: (amc6821) Make reading and writing fan speed limits consistent
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.
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.
hwmon: (w83627ehf) Fix underflows seen when writing limit attributes
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.
hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
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.
hwmon: (lm95234) Fix underflows seen when writing limit attributes
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.
hwmon: (adc128d818) Fix underflows seen when writing limit attributes
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.
Dan Carpenter [Thu, 4 Jul 2024 15:18:59 +0000 (10:18 -0500)]
hwmon: (ltc2991) re-order conditions to fix off by one bug
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.
Alex Vdovydchenko [Tue, 2 Jul 2024 11:52:51 +0000 (14:52 +0300)]
hwmon: add MP5920 driver
Add support for MPS Hot-Swap controller mp5920. This driver exposes
telemetry and limit value readings and writings.
Signed-off-by: Alex Vdovydchenko <xzeol@yahoo.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240702115252.981416-3-xzeol@yahoo.com
[groeck: Use min_t() to limit length of displayed model string] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Wayne Tung [Mon, 1 Jul 2024 07:32:52 +0000 (15:32 +0800)]
hwmon: (adt7475) Fix default duty on fan is disabled
According to the comments on fan is disabled, we change to manual mode
and set the duty cycle to 0.
For setting the duty cycle part, the register is wrong. Fix it.
Guenter Roeck [Sun, 30 Jun 2024 20:08:40 +0000 (13:08 -0700)]
hwmon: (jc42) Strengthen detect function
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.
Guenter Roeck [Sun, 30 Jun 2024 16:32:10 +0000 (09:32 -0700)]
hwmon: (jc42) Use common device ID for TSE2004av compliant sensors
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.
Armin Wolf [Fri, 28 Jun 2024 21:47:23 +0000 (23:47 +0200)]
hwmon: (dell-smm) Add Dell OptiPlex 7060 to DMI table
The BIOS on this machine is buggy and will in some cases return
an error when trying to get the fan state, but reading of the
RPM values and the temperature sensors still works.
Guenter Roeck [Fri, 14 Jun 2024 15:27:21 +0000 (08:27 -0700)]
hwmon: (spd5118) Add support for Renesas/ITD SPD5118 hub controllers
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>
Stanislav Jakubek [Mon, 17 Jun 2024 16:36:29 +0000 (18:36 +0200)]
dt-bindings: hwmon: ti,tmp108: document V+ supply, add short description
TMP108 is powered by its V+ supply, document it. The property is called
"vcc-supply" since the plus sign (+) is not an expected character.
While at it, add a short description with a link to its datasheets.
Amna Waseem [Tue, 11 Jun 2024 09:36:26 +0000 (11:36 +0200)]
hwmon: (ina2xx) Add device tree support to pass alert polarity
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.
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).
Guenter Roeck [Thu, 6 Jun 2024 16:16:40 +0000 (09:16 -0700)]
hwmon: (pmbus/lm25066) Let enum chips start with index 0
Commit ac0c26bae662 ("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>
Guenter Roeck [Thu, 6 Jun 2024 16:23:44 +0000 (09:23 -0700)]
hwmon: (nct6775) Let enum kinds start with index 0
Commit 10a0575ea09d ("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 2792fc8f8c83 ("hwmon:
(nct6775-core) Explicitly initialize nct6775_device_names indexes") and
commit efe86092ab31 ("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.
Guenter Roeck [Thu, 6 Jun 2024 16:36:38 +0000 (09:36 -0700)]
hwmon: (pmbus/mp2856) Let enum chips start with index 0
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>
Guenter Roeck [Fri, 7 Jun 2024 13:32:04 +0000 (06:32 -0700)]
hwmon: (pmbus/max31827) Explain why enum chips must not start with 0
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>
Guenter Roeck [Mon, 3 Jun 2024 05:31:52 +0000 (22:31 -0700)]
hwmon: (spd5118) Add configuration option for auto-detection
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>
Guenter Roeck [Sat, 1 Jun 2024 13:44:47 +0000 (06:44 -0700)]
i2c: smbus: Support DDR5 and LPDDR5 SPD EEPROMs
Detect (LP)DDR5 memory and instantiate the SPD5118 driver automatically.
Suggested-by: Thomas Weißschuh <linux@weissschuh.net> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Thu, 30 May 2024 18:44:11 +0000 (11:44 -0700)]
hwmon: (spd5118) Add suspend/resume support
Add suspend/resume support to ensure that limit and configuration
registers are updated and synchronized after a suspend/resume cycle.
Cc: Armin Wolf <W_Armin@gmx.de> Cc: Stephen Horvath <s.horvath@outlook.com.au> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Stephen Horvath <s.horvath@outlook.com.au> Tested-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Mon, 27 May 2024 17:49:10 +0000 (10:49 -0700)]
hwmon: Add support for SPD5118 compliant temperature sensors
Add support for SPD5118 (Jedec JESD300) compliant temperature
sensors. Such sensors are typically found on DDR5 memory modules.
Cc: René Rebe <rene@exactcode.de> Cc: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Stephen Horvath <s.horvath@outlook.com.au> Tested-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Jeff Johnson [Fri, 7 Jun 2024 22:27:59 +0000 (15:27 -0700)]
hwmon: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hwmon/asus_atk0110.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hwmon/corsair-cpro.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hwmon/mr75203.o
Add all missing invocations of the MODULE_DESCRIPTION() macro.
Javier Carrasco [Thu, 4 Apr 2024 11:13:28 +0000 (13:13 +0200)]
hwmon: (gsc-hwmon) use device_for_each_child_node_scoped()
Switch to the _scoped() version introduced in commit 365130fd47af
("device property: Introduce device_for_each_child_node_scoped()")
to remove the need for manual calling of fwnode_handle_put() in the
paths where the code exits the loop early.
Javier Carrasco [Thu, 4 Apr 2024 11:13:27 +0000 (13:13 +0200)]
hwmon: (ltc2991) use device_for_each_child_node_scoped()
Switch to the _scoped() version introduced in commit 365130fd47af
("device property: Introduce device_for_each_child_node_scoped()")
to remove the need for manual calling of fwnode_handle_put() in the
paths where the code exits the loop early.
Andrew Davis [Wed, 3 Apr 2024 20:36:33 +0000 (15:36 -0500)]
hwmon: (w83795): Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:32 +0000 (15:36 -0500)]
hwmon: (w83781d) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:31 +0000 (15:36 -0500)]
hwmon: (tmp464) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:30 +0000 (15:36 -0500)]
hwmon: (tmp421) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:29 +0000 (15:36 -0500)]
hwmon: (tmp401) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:28 +0000 (15:36 -0500)]
hwmon: (thmc50) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:27 +0000 (15:36 -0500)]
hwmon: (shtc1) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:26 +0000 (15:36 -0500)]
hwmon: (sht3x) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:25 +0000 (15:36 -0500)]
hwmon: (powr1220) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:24 +0000 (15:36 -0500)]
hwmon: (mcp3021) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:23 +0000 (15:36 -0500)]
hwmon: (max6697) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:22 +0000 (15:36 -0500)]
hwmon: (max1668) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:21 +0000 (15:36 -0500)]
hwmon: (max16065) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:20 +0000 (15:36 -0500)]
hwmon: (lm95234) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:19 +0000 (15:36 -0500)]
hwmon: (lm90) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:18 +0000 (15:36 -0500)]
hwmon: (lm85) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:17 +0000 (15:36 -0500)]
hwmon: (lm83) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:16 +0000 (15:36 -0500)]
hwmon: (lm78) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:15 +0000 (15:36 -0500)]
hwmon: (lm75) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:14 +0000 (15:36 -0500)]
hwmon: (lm63) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:13 +0000 (15:36 -0500)]
hwmon: (ina2xx) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:12 +0000 (15:36 -0500)]
hwmon: (fschmd) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:11 +0000 (15:36 -0500)]
hwmon: (f75375s) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:10 +0000 (15:36 -0500)]
hwmon: (ds1621) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:09 +0000 (15:36 -0500)]
hwmon: (dme1737) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:08 +0000 (15:36 -0500)]
hwmon: (aht10) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:07 +0000 (15:36 -0500)]
hwmon: (adt7475) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:06 +0000 (15:36 -0500)]
hwmon: (ads7828) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:05 +0000 (15:36 -0500)]
hwmon: (adm1031) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:04 +0000 (15:36 -0500)]
hwmon: (adm1021) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Wed, 3 Apr 2024 20:36:03 +0000 (15:36 -0500)]
hwmon: (ad7418) Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Krzysztof Kozlowski [Thu, 6 Jun 2024 14:25:15 +0000 (16:25 +0200)]
hwmon: lm70: simplify with spi_get_device_match_data()
Use spi_get_device_match_data() helper to simplify a bit the driver.
Also kernel_ulong_t type is preferred for kernel code over uintptr_t
(needed for the cast).
Christian Marangi [Tue, 4 Jun 2024 16:43:43 +0000 (18:43 +0200)]
hwmon: g672: add support for g761
Add support for g761 PWM Fan Controller.
The g761 is a copy of the g763 with the only difference of supporting
and internal clock. The internal clock is used if no clocks property is
defined in device node and in such case the required bit is enabled and
clock handling is skipped.
Guenter Roeck [Tue, 28 May 2024 20:33:29 +0000 (13:33 -0700)]
hwmon: Add PEC attribute support to hardware monitoring core
Several hardware monitoring chips optionally support Packet Error Checking
(PEC). For some chips, PEC support can be enabled simply by setting
I2C_CLIENT_PEC in the i2c client data structure. Others require chip
specific code to enable or disable PEC support.
Introduce hwmon_chip_pec and HWMON_C_PEC to simplify adding configurable
PEC support for hardware monitoring drivers. A driver can set HWMON_C_PEC
in its chip information data to indicate PEC support. If a chip requires
chip specific code to enable or disable PEC support, the driver only needs
to implement support for the hwmon_chip_pec attribute to its write
function.
Packet Error Checking is only supported for SMBus devices. HWMON_C_PEC
must therefore only be set by a driver if the parent device is an I2C
device. Attempts to set HWMON_C_PEC on any other device type is not
supported and rejected.
The code calls i2c_check_functionality() to check if PEC is supported
by the I2C/SMBus controller. This function is only available if CONFIG_I2C
is enabled and reachable. For this reason, the added code needs to depend
on reachability of CONFIG_I2C.
Cc: Radu Sabau <radu.sabau@analog.com> Acked-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Aleksandr Mezin [Fri, 24 May 2024 00:39:58 +0000 (03:39 +0300)]
hwmon: (nzxt-smart2) Add support for another version of NZXT RGB & Fan Controller
Add support for NZXT RGB & Fan Controller with USB ID 1e71:2020.
Fan speed control reported to be working with existing userspace (hidraw)
software, so it should be compatible. Fan channel count is the same.
No known differences from already supported devices, at least regarding
fan speed control and initialization.
Wilken Gottwalt [Fri, 24 May 2024 04:38:11 +0000 (04:38 +0000)]
hwmon: corsair-psu: add USB id of HX1200i Series 2023 psu
Add the usb id of the HX1200i Series 2023. Update the documentation
accordingly. Also fix the version comments, there are no Series 2022
products. That are legacy or first version products going back many
many years.
Kent Overstreet [Fri, 24 May 2024 15:42:09 +0000 (11:42 -0400)]
mm: percpu: Include smp.h in alloc_tag.h
percpu.h depends on smp.h, but doesn't include it directly because of
circular header dependency issues; percpu.h is needed in a bunch of low
level headers.
This fixes a randconfig build error on mips:
include/linux/alloc_tag.h: In function '__alloc_tag_ref_set':
include/asm-generic/percpu.h:31:40: error: implicit declaration of function 'raw_smp_processor_id' [-Werror=implicit-function-declaration]
projects / linux.git / log