Single-channel regulators do not need and should not have a "regulators"
node. We can not entirely remove it due to existing bindings. To solve the
problem for new drivers, provide additional macros PMBUS_REGULATOR_ONE_NODE
and PMBUS_REGULATOR_STEP_ONE_NODE and convert existing drivers to use those
macros. The exception is the ir38064 driver because its devicetree files
and its description do not require or use the nested regulators node.
Modify PMBUS_REGULATOR_STEP_ONE and PMBUS_REGULATOR_ONE to set the
regulators_node pointer to NULL.
Cc: Cedricjustine.Encarnacion@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250322142602.560042-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
We have some buggy pmbus devices that require a delay after performing a
page change operation before trying to issue more commands to the
device.
This allows for a configurable delay after page changes, but not
affecting other read or write operations.
This makes a slight behavioral tweak to the existing delay logic, where
it considers the longest of delays between operations, instead of always
chosing the write delay over the access delay.
Signed-off-by: William A. Kennington III <william@wkennington.com>
Link: https://lore.kernel.org/r/20250407201002.1198092-1-william@wkennington.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Writing PMBus protected registers does succeed from the smbus perspective,
even if the write is ignored by the device and a communication fault is
raised. This fault will silently be caught and cleared by pmbus irq if one
has been registered.
This means that the regulator call may return succeed although the
operation was ignored.
With this change, the operation which are not supported will be properly
flagged as such and the regulator framework won't even try to execute them.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
[groeck: Adjust to EXPORT_SYMBOL_NS_GPL API change]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* 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
- ina2xx: Driver cleanup and update to use with_info API
- lm92: Driver cleanup and update to use regmap and with_info API
- lm95234: Driver cleanup and update to use regmap and with_info API
- max1619: Driver cleanup and update to use regmap and with_info API
- max1668: Driver cleanup and update to use regmap and with_info API
- max6697: Driver cleanup and update to use regmap and with_info API
* 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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmboX+AACgkQyx8mb86f
mYHRGA/7BVlHa3sxDTNLPvL3VMZ1/SgmQqC0xUx57bAOcpkLX0taXD/t+Nm93HaW
vCKGYPe0jII9tVz1YvZ1VSNwJXZo4X+jfdL3t6RpdKpn/op6vASzhKhh0sGeiyw1
aQNXzrm4dthFDRfmscZM1+CBQv4aTf6ApyTbRFH2dnViXu9idMZYcxoxz87uody5
AxUAgNDPb/mQww3x6r+rVv3VQaJZ+yrJxbYvaxgzbm8TqIFCpHgNtRJTVBhGjbOi
o9rushlUpOjBQE2/jKOajtfV9fWX/kpJu9dUfSbVMCvZgEPU985UX6dpg9Oc0t0o
oUhID2dHLUVNmn4dTQCtvzuLTEBDi87TcML6VDlMIn3dFi5QG3tJZkaWtbPymHz9
4Qf3TJ2TV0E/jIh8UueFd2SlRlkCE3HooM04Kbes7H8ftSbddMM3fTah8yzdOJJE
Dwv6eO3T9REHPaBauFq0Y9hzkx46rqF6Mli0tFUumh7oM1b68ILZ+oJxfpapatzO
Pa6UPFfaHU63VFmDCzNWc0IiI1beF7i5fzzWwj37HgIdaw1+cS6kNtvbv/6t5/41
5TVitpP1SLzDtjK6f+VDjroE/Qg4OeodamBOEopMPjYM/nipyWxPoOK1VEtbo1P5
vAJBmgPn45M02miB7l3ERCCkRVQdeL69ZM5vcRmLB8NQRKML830=
=z6jf
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
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>
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>
The bindings for single instance regulator should be named with no instance
(e.g., buck not buck0). Introduce a new helper macro to define the single pmbus
regulator.
Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>
Link: https://lore.kernel.org/r/20231011164754.449399-4-saravanan@linumiz.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Debugfs operations may set the page number, which must be done
atomically with the subsequent i2c operation. Lock the update_lock
in the debugfs functions and provide a function for pmbus drivers
to lock and unlock the update_lock.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20230412161526.252294-2-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This reverts commit 54cc3dbfc1.
Zev Weiss reports that the reverted patch may cause a regulator
undercount. Here is his report:
... having regulator-dummy set as a supply on my PMBus regulators
(instead of having them as their own top-level regulators without
an upstream supply) leads to enable-count underflow errors when
disabling them:
# echo 0 > /sys/bus/platform/devices/efuse01/state
[ 906.094477] regulator-dummy: Underflow of regulator enable count
[ 906.100563] Failed to disable vout: -EINVAL
[ 136.992676] reg-userspace-consumer efuse01: Failed to configure state: -22
Zev reports that reverting the patch fixes the problem. So let's do that
for now.
Fixes: 54cc3dbfc1 ("hwmon: (pmbus) Add regulator supply into macro")
Cc: Marcello Sylvester Bauer <sylv@sylv.io>
Reported-by: Zev Weiss <zev@bewilderbeest.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The LTC2977 regulator does not set the regulator_desc .n_voltages value
which is needed in order to let the regulator core list the regulator
voltage range.
This patch defines a regulator_desc with a voltage range, and uses it
for defining voltage resolution for regulators LTC2972/LTC2974/LTC2975/
LTC2977/LTC2978/LTC2979/LTC2980/LTM2987 based on that they all have a 16
bit ADC with the same stepwise 122.07uV resolution. It also scales the
resolution to a 1mV resolution which is easier to handle.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220614095144.3472305-1-marten.lindahl@axis.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some of the pmbus core functions uses pmbus_write_byte_data, which does
not support driver callbacks for chip specific write operations. This
could potentially influence some specific regulator chips that for
example need a time delay before each data access.
Lets add support for driver callback with _pmbus_write_byte_data.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220428144039.2464667-2-marten.lindahl@axis.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If there is an input undervoltage fault, reported in STATUS_INPUT
command response, there is quite likely a "Unit Off For Insufficient
Input Voltage" condition as well.
Add a constant for bit 3 of STATUS_INPUT. Update the Vin limit
attributes to include both bits in the mask for clearing faults.
If an input undervoltage fault occurs, causing a unit off for
insufficient input voltage, but the unit is off bit is not cleared, the
STATUS_WORD will not be updated to clear the input fault condition.
Including the unit is off bit (bit 3) allows for the input fault
condition to completely clear.
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Link: https://lore.kernel.org/r/20220317232123.2103592-1-bjwyman@gmail.com
Fixes: b4ce237b7f ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers")
[groeck: Dropped unnecessary ()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add regulator supply into PWBUS_REGULATOR macro. This makes it optional
to define a vin-supply in DT. Not defining a supply will add a dummy
regulator supply instead and only cause the following debug output:
```
Looking up vin-supply property in node [...] failed
```
Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
Link: https://lore.kernel.org/r/58f2ff7b90233fad3d7ae2e9d66d5192e2c1ac01.1645437439.git.sylv@sylv.io
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Increase maximum number of phases from 8 to 10 to support multi-phase
devices allowing up to 10 phases.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210511055619.118104-2-vadimp@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
For the STPDDC60 chip, the vout alarm-limits are represented as an offset
relative to the commanded output voltage. This means that the limits are
dynamic and must not be cached by the pmbus driver. This patch adds a
pmbus_set_sensor() function to pmbus_core to be able to set the update flag
on selected sensors after auto-detection of limit attributes.
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Link: https://lore.kernel.org/r/20210218115249.28513-2-erik.rosen@metormote.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The only action currently performed in pmbus_do_remove() is removing the
debugfs hierarchy. We can schedule a devm action at probe time and remove
pmbus_do_remove() entirely from all pmbus drivers.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20201026105352.20359-1-brgl@bgdev.pl
[groeck: Removed references to pmbus_do_remove from documentation]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
pmbus_do_probe doesn't use the id information provided in its second
argument, so this can be removed, which then allows using the
single-parameter i2c probe function ("probe_new") for probes.
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);
* configured v. probed comparisons are performed by comparing the
configured name to the detected name, instead of the ids; this
involves strcmp but is still cheaper than comparing all the device
names when scanning the tables;
* anything else is handled by calling i2c_match_id() with the same
level of error-handling (if any) as before.
Additionally, the mismatch message in the ltc2978 driver is adjusted
so that it no longer assumes that the driver_data is an index into
ltc2978_id.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20200808210004.30880-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Adding implementation for new attributes (rated_min/rated_max) to
cover PMBus specification about rated values reporting:
MFR_VIN_MIN, MFR_VIN_MAX, MFR_IIN_MAX, MFR_PIN_MAX, MFR_VOUT_MIN,
MFR_VOUT_MAX, MFR_IOUT_MAX, MFR_POUT_MAX, MFR_MAX_TEMP_1/2/3.
Tested with OpenBMC stack. All rated attributes were available
and reported correct values.
Signed-off-by: Zbigniew Lukwinski <zbigniew.lukwinski@linux.intel.com>
Link: https://lore.kernel.org/r/1596224237-32280-4-git-send-email-zbigniew.lukwinski@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some PMBus chips support multiple phases, and report telemetry such
as input current, output current, or temperature for each phase.
Add support for such chips to the PMBus core.
Start with a maximum of 8 phases per page, and assume that supported
sensors per phase are similar for all pages. Only support per-phase
telemetry attributes, no limits or alarms.
As part of this patch, set the initial page variable to 0xff to ensure
that the page is updated when the first page command is issued. Also
only issue page commands if the chip supports more than one page.
Cc: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In preparation for multi-phase support, add 'phase' parameter to read_word
and set_page functions. Actual multi-phase support will be added in
a subsequent patch.
Cc: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Recent PMBus versions added IC_DEVICE_ID and IC_DEVICE_REV commands as
additional means to identify the chip. Add command definitions to
pmbus.h include file.
Cc: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Extend "vrm_version" with the type for Intel IMVP9 and AMD 6.25mV VID
modes.
Add calculation for those types.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-3-vadimp@mellanox.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for VID protocol detection per page bases, instead of
detecting it based on "PMBU_VOUT" readout from page 0 for all the pages
supported by particular device.
The reason that some devices allows to configure different VID modes
per page within the same device.
Patch modifies the field "vrm_version" within the structure
"pmbus_driver_info" to be per page array.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-2-vadimp@mellanox.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If a chip is write protected, we can not change any limits, and we can
not clear status flags. This may be the reason why clearing status flags
is reported to not work for some chips. Detect the condition in the pmbus
core. If the chip is write protected, set limit attributes as read-only,
and set the flag indicating that the status flag should be ignored.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
675 mass ave cambridge ma 02139 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 441 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520071858.739733335@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch makes it possible to pass custom struct attribute_group array
via the pmbus_driver_info struct so that those can be added to the
attribute groups passed to hwmon_device_register_with_groups().
This makes it possible to register custom sysfs attributes by PMBUS
drivers similar to how you can do this with most other busses/classes.
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Those virtual registers can be used to export manufacturer specific
functionality for controlling the number of samples for average values
reported by the device.
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Pmbus client drivers, if they want to use debugfs, should use the same
root directory as the pmbus debugfs entries are using. Therefore, export
the device dentry for the pmbus client.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some circumstances call for virtual pages, to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. An example of this is the Maxim MAX31785 controller,
which extends the READ_FAN_SPEED_1 PMBus register from two to four bytes
to support tach readings for both rotors of a dual rotor fan. This extended
register contains two word-sized values, one reporting the rate of the
fastest rotor, the other the rate of the slowest. The concept of virtual
pages aids this situation by mapping the page number onto the value to be
selected from the vectored result.
We should not try to set virtual pages on the device as such a page
explicitly doesn't exist; add a flag so we can avoid doing so.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
Fans in a PMBus device are driven by the configuration of two registers,
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding configuration in FAN_CONFIG_x_y.
The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers to
facilitate the necessary side-effects of each access:
1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x
Some complexity arises with the fanX_target and pwmX attributes both mapping
onto FAN_COMMAND_x: There is no general mapping between PWM percent duty and
RPM, so we can't display values in either attribute in terms of the other
(which in my mind is the intuitive, if impossible, behaviour). This problem
also affects the pwmX_enable attribute which allows userspace to switch between
full speed, manual PWM and a number of automatic control modes, possibly
including a switch to RPM behaviour (e.g. automatically adjusting PWM duty to
reach a RPM target, the behaviour of fanX_target).
The next most intuitive behaviour is for fanX_target and pwmX to simply be
independent, to retain their most recently set value even if that value is not
active on the hardware (due to switching to the alternative control mode). This
property of retaining the value independent of the hardware state has useful
results for both userspace and the kernel: Userspace always sees a sensible
value in the attribute (the last thing it was set to, as opposed to 0 or
receiving an error on read), and the kernel can use the attributes as a value
cache. This latter point eases the implementation of pwmX_enable, which can
look up the associated pmbus_sensor object, take its cached value and apply it
to hardware on changing control mode. This ensures we will not arbitrarily set
a PWM value as an RPM value or vice versa, and we can assume that the RPM or
PWM value set was sensible at least at some point in the past.
Finally, the DIRECT mode coefficients of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to capture the
necessary coefficients. As pmbus core had no PWM support previously PSC_FAN
continues to be used to capture the RPM DIRECT coefficients, but in order to
avoid falsely applying RPM scaling to PWM values I have introduced the
PMBUS_HAVE_PWM12 and PMB_BUS_HAVE_PWM34 feature bits. These feature bits allow
drivers to explicitly declare PWM support in order to have the attributes
exposed.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The pmbus core may call read/write word data functions with a page value
of -1, intending to perform the operation without setting the page.
However, the read/write word data functions accept only unsigned 8-bit
page numbers, and therefore cannot check for negative page number to
avoid setting the page. This results in setting the page number to 0xFF.
This may result in errors or undefined behavior of some devices
(specifically the ir35221, which allows the page to be set to 0xFF,
but some subsequent operations to read registers may fail).
Switch the pmbus_set_page page parameter to an integer and perform the
check for negative page there. Make read/write functions consistent in
accepting an integer page number parameter.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Fixes: cbcdec6202 ("hwmon: (pmbus): Access word data for STATUS_WORD")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The below lists of VOUT_MODE command readout with their related VID
protocols, Digital to Analog Converter steps:
- VR13.0 mode, 10-mV DAC - 0x24
- VR13.0 mode, 5-mV DAC - 0x27
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
pmbus_regulator_ops is not modified after initialized, so make it const.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The pmbus_regulator_ops is for voltage regulators, so explicitly set
regulator type for better readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for simple on/off control of each channel.
To add regulator support, the pmbus part driver needs to add
regulator_desc information and number of regulators to its
pmbus_driver_info struct.
regulator_desc can be declared using default macro for a
regulator (PMBUS_REGULATOR) that is in pmbus.h
The regulator_init_data can be initialized from either
platform data or the device tree.
Signed-off-by: Alan Tull <atull@opensource.altera.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
For PMBus chips, modifying one limit register may affect other limits.
Since limits are all cached in the PMBus core driver, related changes
are not reflected in reported limits.
Introduce function to clear the attribute cache. After calling this function,
the core pmbus driver re-reads all cached values.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some PMBus chips support monitoring an additional non-standard voltage. While
this voltage can in many cases be supported by simulating an additional sensor
page, this does not work in all cases. Specifically, it is problematic if the
data format is linear and the voltage is reported in LINEAR11 format. Since
output voltages use LINEAR16, and the exponent for LINEAR16 data is chip-wide
and fixed, this can result in overflows.
To solve this problem, add support for an additional virtual input voltage,
call it 'vmon', and treat this voltage as input voltage (which, when the chip
supports linear data format, uses LINEAR11).
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add PMBUS_VIRT_READ_TEMP_AVG, PMBUS_VIRT_READ_TEMP2_AVG,
PMBUS_VIRT_READ_POUT_AVG, PMBUS_VIRT_READ_POUT_MAX,
and PMBUS_VIRT_RESET_POUT_HISTORY.
We'll need those for MAX34446.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since devm_kzalloc() is now used to allocate driver memory, the client
driver remove function has no purpose other than to call pmbus_do_remove().
This means we can get rid of it by redefining pmbus_do_remove() to use the
same prototype, and pointing to it directly.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
At least one PMBus chip supports peak attributes for READ_TEMPERATURE2.
Add virtual registers to be able to report it to the user.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Driver remove functions have an error return value, but rarely return an error
in practice. If a driver does return an error from its remove function, the
driver won't be unloaded and is expected to stay alive.
pmbus_do_remove() is defined as returning an int, but always returns 0 (no
error). Calling code passes that return value on to high level driver
remove functions, but does not evaluate it and removes driver data even if
pmbus_do_remove() returned an error (which it in practice never does). Even if
this code could never cause a real problem, it is nevertheless conceptually
wrong.
To reduce confusion and simplify the code, change pmbus_do_remove() to be a void
function, and have PMBus client drivers always return zero in their driver
remove functions.
Reported-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
