- 14 Jun, 2024 1 commit
-
-
Naresh Solanki authored
Update hwmon init with info instead of group. The hwmon info structure in more flexible to describe sensor attribute & easy to maintian. Signed-off-by:
Naresh Solanki <naresh.solanki@9elements.com> Link: https://lore.kernel.org/r/20240614055533.2735210-1-naresh.solanki@9elements.com [groeck: Replace clamp_val() with range check when writing pwmX_input] Signed-off-by:
Guenter Roeck <linux@roeck-us.net>
-
- 13 Jun, 2024 2 commits
-
-
Thomas Weißschuh authored
Now that the driver core allows for struct class to be in read-only memory, mark hwmon_class as const. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240614-class-const-hwmon-v1-1-27b910d06a90@weissschuh.netSigned-off-by:
-
Noah Wang authored
Add support for MPS step-down converter mp9941. This driver exposes telemetry and limit value readings and writtings. Signed-off-by:
Noah Wang <noahwang.wang@outlook.com> Link: https://lore.kernel.org/r/SEYPR04MB648294005D55F70736B519F6FAC72@SEYPR04MB6482.apcprd04.prod.outlook.com [groeck: Include bitfield.h (for FIELD_PREP) and bits.h (for GENMASK)] Signed-off-by:
-
- 12 Jun, 2024 5 commits
-
-
Noah Wang authored
Add support for MPS mp9941 controller Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Noah Wang authored
Add support for MPS VR controller mp2993. This driver exposes telemetry and limits value readings and writtings. Signed-off-by:
-
Noah Wang authored
Add support for MPS mp2993 controller Acked-by:
-
Amna Waseem authored
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.comSigned-off-by:
-
Amna Waseem authored
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:
Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240603-apol-ina2xx-fix-v3-1-b9eff3158e4e@axis.comSigned-off-by:
-
- 11 Jun, 2024 4 commits
-
-
Guenter Roeck authored
Commit ac0c26ba ("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 authored
Commit 10a0575e ("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 2792fc8f ("hwmon: (nct6775-core) Explicitly initialize nct6775_device_names indexes") and commit efe86092 ("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 authored
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 authored
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:
-
- 10 Jun, 2024 7 commits
-
-
Eugene Shalygin authored
Provided and tested by a user in a GitHub PR [1]. [1] https://github.com/zeule/asus-ec-sensors/pull/56Signed-off-by:
Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20240608085146.572777-2-eugene.shalygin@gmail.comSigned-off-by:
-
Guenter Roeck authored
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:
Armin Wolf <W_Armin@gmx.de> Signed-off-by:
-
Guenter Roeck authored
Detect (LP)DDR5 memory and instantiate the SPD5118 driver automatically. Suggested-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
Guenter Roeck authored
Add support for reading SPD NVMEM data from SPD5118 (Jedec JESD300) compliant memory modules. NVMEM write operation is not supported. NVMEM support is optional. If CONFIG_NVMEM is disabled, the driver will still instantiate but not provide NVMEM attribute files. Reviewed-by:
-
Guenter Roeck authored
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:
Stephen Horvath <s.horvath@outlook.com.au> Tested-by:
-
Guenter Roeck authored
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:
-
Guenter Roeck authored
Add bindings for the SPD hub present in DDR5 modules. (https://www.jedec.org/standards-documents/docs/jesd300-5b01). Acked-by:
-
- 08 Jun, 2024 21 commits
-
-
Jeff Johnson authored
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. Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240607-md-drivers-hwmon-v1-1-1ea6d6fe61e3@quicinc.comSigned-off-by:
-
Javier Carrasco authored
Switch to the _scoped() version introduced in commit 365130fd ("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. Signed-off-by:
Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240404-hwmon_device_for_each_child_node_scoped-v1-2-53997abde43c@gmail.comSigned-off-by:
-
Javier Carrasco authored
Switch to the _scoped() version introduced in commit 365130fd ("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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240403203633.914389-32-afd@ti.comSigned-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
Andrew Davis authored
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. Signed-off-by:
-
