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>
Starting with MAX34451, the chips of this series support STATUS_IOUT and
STATUS_TEMPERATURE commands, and no longer report over-current and
over-temperature status with STATUS_MFR_SPECIFIC.
Fixes: 7a001dbab4 ("hwmon: (pmbus/max34440) Add support for MAX34451.")
Fixes: 50115ac9b6 ("hwmon: (pmbus/max34440) Add support for MAX34460 and MAX34461")
Reported-by: Steve Foreman <foremans@google.com>
Cc: Steve Foreman <foremans@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Per the RAA228228 datasheet, READ_TEMPERATURE_1 is not a supported PMBus
command.
Signed-off-by: Grant Peltier <grantpeltier93@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Using s64 type, instead of long type, for internal calculations and for
the sysfs interface.
This allows 64-bit values to appear correctly on 32-bit kernels.
As wattage is reported in microwatts, monitoring a power supply over
2KW requires this.
Although it may seem unlikely to run a 32-bit kernel on such a large
machine, enterprise servers often include a BMC, and the BMC might be
running a 32-bit kernel.
Signed-off-by: Josh Lehan <krellan@google.com>
[groeck: Removed Change-Id and other tags, reformatted description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Issue:
When PEC is enabled, binding adm1272 to the adm1275 would
fail due to PEC error. See below:
adm1275: probe of xxxx failed with error -74
Diagnosis:
Per the datasheet of adm1272, adm1278, adm1293 and amd1294,
PMON_CONFIG (0xd4) is 16bits wide. On the other hand,
PMON_CONFIG (0xd4) for adm1275 is 8bits wide. The driver should not
assume everything is 8bits wide and read only 8bits from it.
Solution:
If it is adm1272, adm1278, adm1293 and adm1294, use i2c_read_word.
Else, use i2c_read_byte
Testing:
Binding adm1272 to the driver.
The change is only tested on adm1272.
Signed-off-by: Chu Lin <linchuyuan@google.com>
Link: https://lore.kernel.org/r/20200709040612.3977094-1-linchuyuan@google.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
MAX16601 is a VR13.HC Dual-Output Voltage Regulator Chipset,
implementing a (8+1) multiphase synchronous buck converter.
Cc: Alex Qiu <xqiu@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The 'currpage' and 'currphase' variables in struct pmbus_data are used by
the PMBus core to determine if the phase or page value has changed. Both
are initialized with values which are never expected to be set in the code
to ensure that the first page/phase write operation is actually performed.
This is not well explained and occasionally causes confusion. Change the
type of both variables to s16 and initialize with -1 to ensure that the
initial value never matches a requested value, and clarify that this
value means "unknown/unset".
Cc: Alex Qiu <xqiu@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
I2C chip IDs need to reflect chip names, not chip functionality.
Fixes: f621d61fd5 ("hwmon: (pmbus) add support for 2nd Gen Renesas digital multiphase")
Cc: Grant Peltier <grantpeltier93@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
TPS53647 and TPS53667 are single channel, Step-Down Buck Controllers.
TPS53647 supports 4 phases, TPS53667 supports 6 phases.
The chips do not support per-phase output telemetry.
Cc: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
All chips of this series with published datasheets support IIN, PIN, and
STATUS_INPUT PMBus commands. Per TI Power Management Forum, "TPS53679 and
TPS53681 have the same PMBus command set". There is no reason to believe
that this does not apply to TPS53688. Let's assume that this is correct
and add support for IIN, PIN, and STATUS_INPUT to TPS53679 and TPS53688
to simplify adding support for more chips of the same series.
At the same time, drop reporting VIN on channel 2. On chips with published
datasheets this voltage is identical to the voltage reported on channel 1,
and there is no reason to believe that this is different for TPS53679 and
TPS53888.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Chip specific support will be needed in the driver to be able to
support additional chips of the same series. Add support for it
to the driver.
To simplify adding support for more chips, call identification code
from the probe function. This lets us use a single structure for common
elements of struct pmbus_driver_info, thus reducing code size as support
for more chips is added.
Cc: Vadim Pasternak <vadimp@mellanox.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>
Provide read_word_data() callback for overvoltage and undervoltage
output readouts conversion. These registers are presented in
'slinear11' format, while default conversion for 'vout' class for the
devices is 'vid'. It is resulted in wrong conversion in pmbus_reg2data()
for in{3-4}_lcrit and in{3-4}_crit attributes.
)
Fixes: aaafb7c8eb ("hwmon: (pmbus) Add support for Infineon Multi-phase xdpe122 family controllers")
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200224225202.19576-1-vadimp@mellanox.com
[gropeck: Adjusted to mainline PMBus API]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
bits 6/5. This fixs a LTC297X family bug where polling always returns
not busy even when the part is busy. This fixes a LTC388X and
LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY was
not polled, which can lead to NACKing of commands. LTC388X and
LTM467X modules now poll BUSY and PEND, increasing reliability by
eliminating NACKing of commands.
Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
Link: https://lore.kernel.org/r/1580234400-2829-2-git-send-email-michael-a1.jones@analog.com
Fixes: e04d1ce9bb ("hwmon: (ltc2978) Add polling for chips requiring it")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for devices XDPE12254, XDPE12284.
All these device support two pages.
The below lists of VOUT_MODE command readout with their related VID
protocols, Digital to Analog Converter steps, supported by these
devices:
VR12.0 mode, 5-mV DAC - 0x01;
VR12.5 mode, 10-mV DAC - 0x02;
IMVP9 mode, 5-mV DAC - 0x03;
AMD mode 6.25mV - 0x10.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-5-vadimp@mellanox.com
[groeck: Added missing break statement]
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>
The LED blink_set function incorrectly did not tell the PSU LED to blink
if brightness was LED_OFF. Fix this, and also correct the LED_OFF
command data, which should give control of the LED back to the PSU
firmware. Also prevent I2C failures from getting the driver LED state
out of sync and add some dev_dbg statements.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20191106200106.29519-3-eajames@linux.ibm.com
Fixes: ef9e1cdf41 ("hwmon: (pmbus/cffps) Add led class device for power supply fault led")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add the driver to monitor Inspur Power System power supplies
with hwmon over pmbus.
This driver adds sysfs attributes for additional power supply data,
including vendor, model, part_number, serial number,
firmware revision, hardware revision, and psu mode(active/standby).
Signed-off-by: John Wang <wangzqbj@inspur.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20190819091509.29276-1-wangzqbj@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Build bot reports the following build issue after commit 9091373ab7
("gpio: remove less important #ifdef around declarations):
In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
>> include/linux/gpio/driver.h:576:1: error: redefinition of 'gpiochip_add_pin_range'
gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
include/linux/gpio.h:245:1: note: previous definition of 'gpiochip_add_pin_range' was here
gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
>> include/linux/gpio/driver.h:583:1: error: redefinition of 'gpiochip_add_pingroup_range'
gpiochip_add_pingroup_range(struct gpio_chip *chip,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
include/linux/gpio.h:254:1: note: previous definition of 'gpiochip_add_pingroup_range' was here
gpiochip_add_pingroup_range(struct gpio_chip *chip,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
>> include/linux/gpio/driver.h:591:1: error: redefinition of 'gpiochip_remove_pin_ranges'
gpiochip_remove_pin_ranges(struct gpio_chip *chip)
^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
include/linux/gpio.h:263:1: note: previous definition of 'gpiochip_remove_pin_ranges' was here
gpiochip_remove_pin_ranges(struct gpio_chip *chip)
This is caused by conflicting defines from linux/gpio.h and
linux/gpio/driver.h. Drivers should not include both the legacy and
the new API headers. This driver doesn't even use linux/gpio.h so
remove it.
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20190808080144.6183-1-brgl@bgdev.pl
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
