kernel.git/drivers/hwmon/pmbus, branch linux-5.19.y

hwmon: (pmbus/mp2888) Fix sensors readouts for MPS Multi-phase mp2888 controller

2022-10-24T07:57:15Z

[ Upstream commit 525dd5aed67a2f4f7278116fb92a24e6a53e2622 ] Fix scale factors for reading MPS Multi-phase mp2888 controller. Fixed sensors: - PIN/POUT: based on vendor documentation, set bscale factor 0.5W/LSB - IOUT: based on vendor documentation, set scale factor 0.25 A/LSB Fixes: e4db7719d037 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2888 controller") Signed-off-by: Oleksandr Shamray Reviewed-by: Vadim Pasternak Link: https://lore.kernel.org/r/20220929121642.63051-1-oleksandrs@nvidia.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (pmbus/ucd9200) fix typos in comments

2022-06-29T21:02:08Z

Drop the redundant word 'the' in the comments following /* * Set PHASE registers on all pages to 0xff to ensure that phase * specific commands will apply to all phases of a given page (rail). * This only affects the READ_IOUT and READ_TEMPERATURE2 registers. * READ_IOUT will return the sum of currents of all phases of a rail, * and READ_TEMPERATURE2 will return the maximum temperature detected * for the [the - DROP] phases of the rail. */ Signed-off-by: Jiang Jian Link: https://lore.kernel.org/r/20220622063231.20612-1-jiangjian@cdjrlc.com Signed-off-by: Guenter Roeck

hwmon: (pmbus) Check PEC support before reading other registers

2022-05-22T18:32:32Z

Make sure that the support of PEC is determined before the read of other registers. Otherwise the validation of PEC can trigger an error on the read of STATUS_BYTE or STATUS_WORD registers. The problematic scenario is the following. A device with enabled PEC support is up and running and a kernel driver is loaded. Then the driver is unloaded (or device unbound), the HW device is reconfigured externally (e.g. by i2cset) to advertise itself as not supporting PEC. Without the move of the code, at the second load of the driver (or bind) the STATUS_BYTE or STATUS_WORD register is always read with PEC enabled, which is likely to cause a read error resulting with fail of a driver load (or bind). Signed-off-by: Adam Wujek Link: https://lore.kernel.org/r/20220519233334.438621-1-dev_public@wujek.eu Fixes: 75d2b2b06bd84 ("hwmon: (pmbus) disable PEC if not enabled") Fixes: 4e5418f787ec5 ("hwmon: (pmbus_core) Check adapter PEC support") [groeck: Added Fixes: tags, dropped continuation line] Signed-off-by: Guenter Roeck

hwmon: (pmbus) Add get_voltage/set_voltage ops

2022-05-22T18:32:31Z

The pmbus core does not have operations for getting or setting voltage. Add functions get/set voltage for the dynamic regulator framework. Signed-off-by: Mårten Lindahl Link: https://lore.kernel.org/r/20220503104631.3515715-5-marten.lindahl@axis.com [groeck: cosmetic alignment / empty line fixes] Signed-off-by: Guenter Roeck

hwmon: (pmbus) Register with thermal for PSC_TEMPERATURE

2022-05-22T18:32:31Z

Some pmbus device drivers have device tree support and may want to use of-thermal to register a thermal zone OF sensor for those device drivers. This way we allow describing device tree thermal zones for pmbus device drivers with device tree support. This patch achieves this by registering pmbus sensors with thermal subsystem if they are PSC_TEMPERATURE and are providing _input hwmon interface. Cc: Guenter Roeck (maintainer:PMBUS HARDWARE MONITORING DRIVERS) Cc: Jean Delvare (maintainer:HARDWARE MONITORING) Cc: linux-hwmon@vger.kernel.org (open list:PMBUS HARDWARE MONITORING DRIVERS) Cc: linux-kernel@vger.kernel.org (open list) Signed-off-by: Eduardo Valentin Signed-off-by: Eduardo Valentin Link: https://lore.kernel.org/r/20220428174926.2150-1-eduval@amazon.com Signed-off-by: Guenter Roeck

hwmon: (pmbus) Add support for Infineon Digital Multi-phase xdp152 family controllers

2022-05-22T18:32:20Z

Add support for devices XDPE152C4, XDPE12584. Signed-off-by: Greg Schwendimann Link: https://lore.kernel.org/r/5e6d50e9b28140158f339b0de343eea4@infineon.com Signed-off-by: Guenter Roeck

hwmon: (pmbus/ltc2978) Add chip specific write_byte_data

2022-05-20T17:57:06Z

Several of the manuals for devices supported by this driver describes the need for a minimum wait time before the chip is ready to receive next command. This wait time is already implemented in the driver as a ltc_wait_ready function with a driver defined wait time of 100 ms, and is considered for specific devices before reading/writing data on the pmbus. Since this driver uses the default pmbus_regulator_ops for the enable/ disable/is_enabled functions we should add a driver specific callback for write_byte_data to prevent bypassing the wait time recommendations for the following devices: ltc3880/ltc3882/ltc3883/ltc3884/ltc3886/ ltc3887/ltc3889/ltm4664/ltm4675/ltm4676/ltm4677/ltm4678/ltm4680/ltm4686/ ltm4700/ltc7880. Signed-off-by: Mårten Lindahl Link: https://lore.kernel.org/r/20220428144039.2464667-4-marten.lindahl@axis.com Signed-off-by: Guenter Roeck

hwmon: (pmbus) Use _pmbus_read_byte_data with callback

2022-05-20T17:57:06Z

Some of the pmbus core functions uses pmbus_read_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 use _pmbus_read_byte_data with callback check. Signed-off-by: Mårten Lindahl Link: https://lore.kernel.org/r/20220428144039.2464667-3-marten.lindahl@axis.com Signed-off-by: Guenter Roeck

hwmon: (pmbus) Introduce and use write_byte_data callback

2022-05-20T17:57:06Z

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 Link: https://lore.kernel.org/r/20220428144039.2464667-2-marten.lindahl@axis.com Signed-off-by: Guenter Roeck

hwmon: (pmbus/max16601) Add MAX16602 support

2022-05-20T17:57:05Z

Adding another MAX16602 chip support to MAX16601 driver Tested with MAX16602 works as expected. Signed-off-by: Atif Ofluoglu Signed-off-by: Guenter Roeck