Pull hwmon updates from Guenter Roeck:
"New drivers:
- driver for Sophgo SG2042 external hardware monitor
- thermal sensor driver for Surface Aggregator Module
Added support to existing drivers:
- oxp-sensors: Support for multiple new devices.
- nct6775: Added G15CF to ASUS WMI monitoring list
Modernizations:
- driver cleanup and update to use with_info API: ina2xx, lm92,
lm95234, max1619, max1668, and max6697.
API updates:
- removed unused devm_hwmon_device_unregister() API function
Other notable changes
- implement and use generic bus access delay for pmbus drivers
- use with scoped for each OF child loop in several drivers
- module unloading fixes for gsc-hwmon and ntc_thermistor drivers
- converted various drivers to use multi-byte regmap operations
- adt7475: Improved devicetree based configuration
- ltc2947: Move to firmware agnostic API
- ltc2978: Converted devicetree description to yaml
- max16065: Addressed overflows when writing limit attributes
Various other minor cleanups, fixes and improvements"
* tag 'hwmon-for-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (96 commits)
hwmon: Remove devm_hwmon_device_unregister() API function
hwmon: (sch5636) Print unknown ID in error string via %*pE
hwmon: (sht21) Use %*ph to print small buffer
hwmon: (pmbus/mpq7932) Constify struct regulator_desc
hwmon: pmbus: pli12096bc: Add write delay
hwmon: pmbus: zl6100: Use generic code
hwmon: pmbus: ucd9000: Use generic code
hwmon: pmbus: max15301: Use generic code
hwmon: pmbus: Implement generic bus access delay
hwmon: (ina2xx) Use shunt voltage to calculate current
hwmon: (ina2xx) Add support for current limits
hwmon: (ina2xx) Pass register to alert limit write functions
hwmon: (ina2xx) Convert to use with_info hwmon API
hwmon: (ina2xx) Move ina2xx_get_value()
hwmon: (ina2xx) Set alert latch
hwmon: (ina2xx) Consolidate chip initialization code
hwmon: (ina2xx) Fix various overflow issues
hwmon: (ina2xx) Re-initialize chip using regmap functions
hwmon: (ina2xx) Use local regmap pointer if used more than once
hwmon: (ina2xx) Mark regmap_config as const
...
The current implementation of pmbus_show_boolean assumes that all devices
support write-back operation of status register to clear pending warnings
or faults. Since clearing individual bits in the status registers was only
introduced in PMBus specification 1.2, this operation may not be supported
by some older devices. This can result in an error while reading boolean
attributes such as temp1_max_alarm.
Fetch PMBus revision supported by the device and modify pmbus_show_boolean
so that it only tries to clear individual status bits if the device is
compliant with PMBus specs >= 1.2. Otherwise clear all fault indicators
on the current page after a fault status was reported.
Fixes: 35f165f089 ("hwmon: (pmbus) Clear pmbus fault/warning bits after read")
Signed-off-by: Patryk Biel <pbiel7@gmail.com>
Message-ID: <20240909-pmbus-status-reg-clearing-v1-1-f1c0d68c6408@gmail.com>
[groeck:
Rewrote description
Moved revision detection code ahead of clear faults command
Assigned revision if return value from PMBUS_REVISION command is 0
Improved return value check from calling _pmbus_write_byte_data()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
'struct regulator_desc' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
This also makes mpq7932_regulators_desc consistent with
mpq7932_regulators_desc_one which is already a "static const struct
regulator_desc".
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
3516 2264 0 5780 1694 drivers/hwmon/pmbus/mpq7932.o
After:
=====
text data bss dec hex filename
5396 384 0 5780 1694 drivers/hwmon/pmbus/mpq7932.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-ID: <c0585a07547ec58d99a5bff5e02b398114bbe312.1725784343.git.christophe.jaillet@wanadoo.fr>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tests on PLI12096bc showed that sometimes a small delay is necessary
after a write operation before a new operation can be processed.
If not respected the device will probably NACK the data phase of
the SMBus transaction. Tests showed that the probability to observe
transaction errors can be raised by either reading sensor data or
toggling the regulator enable.
Further tests showed that 250 microseconds, as used previously for
the CLEAR_FAULTS workaround, is sufficient.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Message-ID: <20240902075319.585656-5-patrick.rudolph@9elements.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some drivers, like the max15301 or zl6100, are intentionally delaying
SMBus communications, to prevent transmission errors. As this is necessary
on additional PMBus compatible devices, implement a generic delay mechanism
in the pmbus core.
Introduces two delay settings in the pmbus_driver_info struct, one applies
to every SMBus transaction and the other is for write transaction only.
Once set by the driver the SMBus traffic, using the generic pmbus access
helpers, is automatically delayed when necessary.
The two settings are:
access_delay:
- Unit in microseconds
- Stores the accessed timestamp after every SMBus access
- Delays when necessary before the next SMBus access
write_delay:
- Unit in microseconds
- Stores the written timestamp after a write SMBus access
- Delays when necessary before the next SMBus access
This allows to drop the custom delay code from the drivers and easily
introduce this feature in additional pmbus drivers.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Message-ID: <20240902075319.585656-1-patrick.rudolph@9elements.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>
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>
Pull hwmon updates from Guenter Roeck:
"New drivers:
- Infineon XDP710
- EC Chip driver for Lenovo ThinkStation motherboards
- Analog Devices ADP1050
Improved support for existing drivers:
- emc1403: Convert to with_info API; Support for EMC1428 and EMC1438
- nzxt-kraken3: Support for NZXT Kraken 2023
- aquacomputer_d5next: Support for Octo flow sensors
- pmbus/adm1275: Support for ADM1281
- dell-smm: Supportt for Precision 7540 and G5 5505
Other notable cleanup:
- max6639: Use regmap
- Remove unused structure fields from multiple drivers
- Drop explicit initialization of struct i2c_device_id::driver_data
to zero
- Improve configuration mode handling in it87 driver
- jc42: Drop support for I2C_CLASS_SPD
- Various conversions to devicetree schema
- Add HAS_IOPORT dependencies as needed
Minor fixes and improvements to max31790, coretemp, aspeed-g6-pwm-tach,
pwm-fan, pmbus/mp2975, acpi_power_meter, and lm70 drivers"
* tag 'hwmon-for-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (52 commits)
hwmon: (nzxt-kraken3) Bail out for unsupported device variants
hwmon: (emc1403) Add support for EMC1428 and EMC1438.
hwmon: Drop explicit initialization of struct i2c_device_id::driver_data to 0 (part 2)
hwmon: (emc1403) Add support for conversion interval configuration
hwmon: (emc1403) Support 11 bit accuracy
hwmon: (emc1403) Convert to with_info API
hwmon: (max6639) Use regmap
hwmon: (npcm750-pwm-fan) Remove another unused field in struct npcm7xx_cooling_device
hwmon: (npcm750-pwm-fan) Remove an unused field in struct npcm7xx_cooling_device
hwmon: (stts751) Remove an unused field in struct stts751_priv
hwmon: Drop explicit initialization of struct i2c_device_id::driver_data to 0
hwmon: (max31790) revise the scale to write pwm
hwmon: (nzxt-kraken3) Add support for NZXT Kraken 2023 (standard and Elite) models
hwmon: (nzxt-kraken3) Decouple device names from kinds
hwmon: (it87) Remove tests nolonger required
hwmon: (it87) Test for chipset before entering configuration mode
hwmon: (it87) Do not enter configuration mode for some chiptypes
hwmon: (it87) Rename FEAT_CONF_NOEXIT to FEAT_NOCONF as more descriptive of requirement
hwmon: (pmbus) Add support for Infineon XDP710
dt-bindings: hwmon: Add infineon xdp710 driver bindings
...
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
This is a follow up to commit d8a66f3621 ("hwmon: Drop explicit
initialization of struct i2c_device_id::driver_data to 0") which I
created before identifying a few corner cases in my conversion script.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240508072027.2119857-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for ADP1050 Digital Controller for Isolated Power Supplies
with PMBus interface Voltage, Current and Temperature Monitor.
The ADP1050 implements several features to enable a robust
system of parallel and redundant operation for customers who
require high availability. The device can measure voltage,
current and temperature that can be used in different
techniques to identify and safely shut down an erroneous
power supply in parallel operation mode.
Signed-off-by: Radu Sabau <radu.sabau@analog.com>
Link: https://lore.kernel.org/r/20240321142201.10330-2-radu.sabau@analog.com
[groeck: Fixed corrupted link in documentation]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The current driver code no longer perfrom internal conversion from
VID to direct. Instead it configures READ_VOUT using MFR_DC_LOOP_CTRL.
Correct the comment message inside the 'mp2975_read_byte_data'
function to match the driver logic.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Fixes: c60fe56c16 ("hwmon: (pmbus/mp2975) Fix driver initialization for MP2975 device")
Link: https://lore.kernel.org/r/20240127154844.989-1-aladyshev22@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The commit 1feb31e810 ("hwmon: (pmbus/mp2975) Simplify VOUT code")
has introduced a bug that makes it impossible to initialize MP2975
device:
"""
mp2975 5-0020: Failed to identify chip capabilities
i2c i2c-5: new_device: Instantiated device mp2975 at 0x20
i2c i2c-5: delete_device: Deleting device mp2975 at 0x20
"""
Since the 'read_byte_data' function was removed from the
'pmbus_driver_info ' structure the driver no longer reports correctly
that VOUT mode is direct. Therefore 'pmbus_identify_common' fails
with error, making it impossible to initialize the device.
Restore 'read_byte_data' function to fix the issue.
Tested:
- before: it is not possible to initialize MP2975 device with the
'mp2975' driver,
- after: 'mp2975' correctly initializes MP2975 device and all sensor
data is correct.
Fixes: 1feb31e810 ("hwmon: (pmbus/mp2975) Simplify VOUT code")
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Link: https://lore.kernel.org/r/20240126205714.2363-1-aladyshev22@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use preferred i2c_get_match_data() instead of of_match_device() and
i2c_match_id() to get the driver match data. With this, adjust the
includes to explicitly include the correct headers.
Adjust the 'chips' enum to not use 0, so that no match data can be
distinguished from a valid enum value.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231115205703.3730448-3-robh@kernel.org
[groeck: Use double cast for enum chips assignment to make compiler happy]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The MAX31785 has shown erratic behaviour across multiple system
designs, unexpectedly clock stretching and NAKing transactions.
Experimentation shows that this seems to be triggered by a register access
directly back to back with a previous register write. Experimentation also
shows that inserting a small delay after register writes makes the issue go
away.
Use a similar solution to what the max15301 driver does to solve the same
problem. Create a custom set of bus read and write functions that make sure
that the delay is added.
Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
Link: https://lore.kernel.org/r/20231027044346.2167548-1-lakshmiy@us.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The MPQ2286 is a programmable, high frequency synchronous buck regulator
designed to power a variety of Automotive system peripherals. Single buck
converters with hardware monitoring capability is configurable over PMBus
interface.
Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>
Link: https://lore.kernel.org/r/20231011164754.449399-5-saravanan@linumiz.com
[groeck: Updated subject (mpq2286 -> mpq7932)]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
TDA38640 can operate in either PMBus mode or SVID mode.
In SVID mode, by design ENABLE pin is the only option for controlling
the output rail i.e., ENABLE pin is chained to power good of another
reglator & FPGA.
In cases where the chip is configured for SVID mode, and the ENABLE pin
is set at a fixed level or is left unconnected (with an internal
pull-down), while requiring software control, the following
workaround is necessary.
The workaround utilizes ENABLE pin polarity flipping to control
output rail.
If property 'infineon,en-pin-fixed-level' is specified then
determine if chip is in SVID mode by checking BIT15 of MTP memory offset
0x44 as described in the datasheet.
If chip is in SVID mode then apply the workaround by
1. Determine EN pin level
2. Maps BIT7 of OPERATION(01h) to EN_PIN_POLARITY(BIT1) of
PB_ON_OFF_CONFIG.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230831190731.265099-3-Naresh.Solanki@9elements.com
[groeck: Dropped unnecessary line continuation]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
After doing performance optimizations the pli1209 driver failed to
probe with a probabilty of 2%. It wasn't able to read the PMBUS_OPERATION
register due to an -EIO error.
An investigation showed that the PLI1209 takes 230 usec to execute the
CLEAR_FAULTS command. During that time it's busy and NACKs all requests
on the SMBUS interface. It also NACKs reads on PMBUS_STATUS_BYTE
making it impossible to poll the BUSY flag.
Add a custom write_data function to just wait for not BUSY unconditionally
after sending a CLEAR_FAULTS command.
TEST: Verified using an I2C bus analyser that no more NACKs are seen after
sending a CLEAR_FAULTS command.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230817092527.808631-3-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Observing I2C traffic revealed consecutive transmission of CLEAR_FAULT
commands. While this doesn't cause issues, it extends driver probe time.
Avoid invoking pmbus_clear_fault_page for virtual registers, as they're
managed by the driver, not the chip.
TEST: Verified using an I2C bus analyzer that only one CLEAR_FAULT
command is send instead 5 in a row.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230817092527.808631-1-Naresh.Solanki@9elements.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
