| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <7af2d708-7e22-3970-7bf8-1cb23317cb55@roeck-us.net>
Date: Thu, 27 May 2021 07:50:01 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Robert Marko <robert.marko@...tura.hr>
Cc: jdelvare@...e.com, corbet@....net, linux-hwmon@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Luka Perkov <luka.perkov@...tura.hr>, jmp@...phyte.org,
Paul Menzel <pmenzel@...gen.mpg.de>,
Donald Buczek <buczek@...gen.mpg.de>
Subject: Re: [PATCH 1/3] hwmon: (pmbus) Add driver for Delta DPS-920AB PSU
On 5/27/21 7:17 AM, Robert Marko wrote:
> On Thu, May 27, 2021 at 4:03 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On 5/27/21 3:59 AM, Robert Marko wrote:
>>> On Thu, May 27, 2021 at 12:22 PM Robert Marko <robert.marko@...tura.hr> wrote:
>>>>
>>>> On Mon, May 24, 2021 at 3:47 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>
>>>>> On 5/24/21 5:21 AM, Robert Marko wrote:
>>>>>> On Fri, May 21, 2021 at 4:46 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>>>
>>>>>>> On 5/21/21 4:56 AM, Robert Marko wrote:
>>>>>>>> On Fri, May 21, 2021 at 12:56 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>>>>>
>>>>>>>>> On 5/21/21 1:36 AM, Robert Marko wrote:
>>>>>>>>>> On Wed, May 19, 2021 at 3:19 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 5/19/21 5:38 AM, Robert Marko wrote:
>>>>>>>>>>>> On Fri, Apr 30, 2021 at 3:48 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Apr 30, 2021 at 03:27:33PM +0200, Robert Marko wrote:
>>>>>>>>>>>>>> This adds support for the Delta DPS-920AB PSU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only missing feature is fan control which the PSU supports.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Robert Marko <robert.marko@...tura.hr>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> Documentation/hwmon/dps920ab.rst | 80 ++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>> Documentation/hwmon/index.rst | 1 +
>>>>>>>>>>>>>> drivers/hwmon/pmbus/Kconfig | 9 ++++
>>>>>>>>>>>>>> drivers/hwmon/pmbus/Makefile | 1 +
>>>>>>>>>>>>>> drivers/hwmon/pmbus/dps920ab.c | 63 +++++++++++++++++++++++++
>>>>>>>>>>>>>> 5 files changed, 154 insertions(+)
>>>>>>>>>>>>>> create mode 100644 Documentation/hwmon/dps920ab.rst
>>>>>>>>>>>>>> create mode 100644 drivers/hwmon/pmbus/dps920ab.c
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/Documentation/hwmon/dps920ab.rst b/Documentation/hwmon/dps920ab.rst
>>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>>> index 000000000000..df0aef530c7e
>>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>>> +++ b/Documentation/hwmon/dps920ab.rst
>>>>>>>>>>>>>> @@ -0,0 +1,80 @@
>>>>>>>>>>>>>> +.. SPDX-License-Identifier: GPL-2.0-or-later
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Kernel driver dps920ab
>>>>>>>>>>>>>> +========================
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Supported chips:
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + * Delta DPS920AB
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + Prefix: 'dps920ab'
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + Addresses scanned: -
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Authors:
>>>>>>>>>>>>>> + Robert Marko <robert.marko@...tura.hr>
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Description
>>>>>>>>>>>>>> +-----------
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +This driver implements support for Delta DPS920AB 920W 54V DC single output
>>>>>>>>>>>>>> +power supply with PMBus support.
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +The driver is a client driver to the core PMBus driver.
>>>>>>>>>>>>>> +Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Usage Notes
>>>>>>>>>>>>>> +-----------
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +This driver does not auto-detect devices. You will have to instantiate the
>>>>>>>>>>>>>> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
>>>>>>>>>>>>>> +details.
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Sysfs entries
>>>>>>>>>>>>>> +-------------
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +======================= ======================================================
>>>>>>>>>>>>>> +curr1_label "iin"
>>>>>>>>>>>>>> +curr1_input Measured input current
>>>>>>>>>>>>>> +curr1_crit Critical maximum current
>>>>>>>>>>>>>> +curr1_crit_alarm Current critical high alarm
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +curr2_label "iout1"
>>>>>>>>>>>>>> +curr2_input Measured output current
>>>>>>>>>>>>>> +curr2_crit Critical maximum current
>>>>>>>>>>>>>> +curr2_crit_alarm Current critical high alarm
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +in1_label "vin"
>>>>>>>>>>>>>> +in1_input Measured input voltage
>>>>>>>>>>>>>> +in1_lcrit Critical minimum input voltage
>>>>>>>>>>>>>> +in1_lcrit_alarm Input voltage critical low alarm
>>>>>>>>>>>>>> +in1_crit Critical maximum input voltage
>>>>>>>>>>>>>> +in1_crit_alarm Input voltage critical high alarm
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +in2_label "vout1"
>>>>>>>>>>>>>> +in2_input Measured output voltage
>>>>>>>>>>>>>> +in2_lcrit Critical minimum output voltage
>>>>>>>>>>>>>> +in2_lcrit_alarm Output voltage critical low alarm
>>>>>>>>>>>>>> +in2_crit Critical maximum output voltage
>>>>>>>>>>>>>> +in2_crit_alarm Output voltage critical high alarm
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +power1_label "pin"
>>>>>>>>>>>>>> +power1_input Measured input power
>>>>>>>>>>>>>> +power1_alarm Input power high alarm
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +power2_label "pout1"
>>>>>>>>>>>>>> +power2_input Measured output power
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +temp[1-2]_input Measured temperature
>>>>>>>>>>>>>> +temp[1-2]_crit Critical high temperature
>>>>>>>>>>>>>> +temp[1-2]_crit_alarm Chip temperature critical high alarm
>>>>>>>>>>>>>> +temp[1-2]_max Maximum temperature
>>>>>>>>>>>>>> +temp[1-2]_max_alarm Chip temperature high alarm
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +fan1_alarm Fan 1 warning.
>>>>>>>>>>>>>> +fan1_fault Fan 1 fault.
>>>>>>>>>>>>>> +fan1_input Fan 1 speed in RPM.
>>>>>>>>>>>>>> +======================= ======================================================
>>>>>>>>>>>>>> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
>>>>>>>>>>>>>> index 8d5a2df1ecb6..b24436f22052 100644
>>>>>>>>>>>>>> --- a/Documentation/hwmon/index.rst
>>>>>>>>>>>>>> +++ b/Documentation/hwmon/index.rst
>>>>>>>>>>>>>> @@ -54,6 +54,7 @@ Hardware Monitoring Kernel Drivers
>>>>>>>>>>>>>> dell-smm-hwmon
>>>>>>>>>>>>>> dme1737
>>>>>>>>>>>>>> drivetemp
>>>>>>>>>>>>>> + dps920ab
>>>>>>>>>>>>>> ds1621
>>>>>>>>>>>>>> ds620
>>>>>>>>>>>>>> emc1403
>>>>>>>>>>>>>> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
>>>>>>>>>>>>>> index 32d2fc850621..865ade0aa205 100644
>>>>>>>>>>>>>> --- a/drivers/hwmon/pmbus/Kconfig
>>>>>>>>>>>>>> +++ b/drivers/hwmon/pmbus/Kconfig
>>>>>>>>>>>>>> @@ -66,6 +66,15 @@ config SENSORS_IBM_CFFPS
>>>>>>>>>>>>>> This driver can also be built as a module. If so, the module will
>>>>>>>>>>>>>> be called ibm-cffps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +config SENSORS_DPS920AB
>>>>>>>>>>>>>> + tristate "Delta DPS920AB Power Supply"
>>>>>>>>>>>>>> + help
>>>>>>>>>>>>>> + If you say yes here you get hardware monitoring support for Delta
>>>>>>>>>>>>>> + DPS920AB Power Supplies.
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + This driver can also be built as a module. If so, the module will
>>>>>>>>>>>>>> + be called dps920ab.
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> config SENSORS_INSPUR_IPSPS
>>>>>>>>>>>>>> tristate "INSPUR Power System Power Supply"
>>>>>>>>>>>>>> help
>>>>>>>>>>>>>> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
>>>>>>>>>>>>>> index 6a4ba0fdc1db..f59ba0123d68 100644
>>>>>>>>>>>>>> --- a/drivers/hwmon/pmbus/Makefile
>>>>>>>>>>>>>> +++ b/drivers/hwmon/pmbus/Makefile
>>>>>>>>>>>>>> @@ -9,6 +9,7 @@ obj-$(CONFIG_SENSORS_ADM1266) += adm1266.o
>>>>>>>>>>>>>> obj-$(CONFIG_SENSORS_ADM1275) += adm1275.o
>>>>>>>>>>>>>> obj-$(CONFIG_SENSORS_BEL_PFE) += bel-pfe.o
>>>>>>>>>>>>>> obj-$(CONFIG_SENSORS_IBM_CFFPS) += ibm-cffps.o
>>>>>>>>>>>>>> +obj-$(CONFIG_SENSORS_DPS920AB) += dps920ab.o
>>>>>>>>>>>>>> obj-$(CONFIG_SENSORS_INSPUR_IPSPS) += inspur-ipsps.o
>>>>>>>>>>>>>> obj-$(CONFIG_SENSORS_IR35221) += ir35221.o
>>>>>>>>>>>>>> obj-$(CONFIG_SENSORS_IR38064) += ir38064.o
>>>>>>>>>>>>>> diff --git a/drivers/hwmon/pmbus/dps920ab.c b/drivers/hwmon/pmbus/dps920ab.c
>>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>>> index 000000000000..d579ed9f879c
>>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>>> +++ b/drivers/hwmon/pmbus/dps920ab.c
>>>>>>>>>>>>>> @@ -0,0 +1,63 @@
>>>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>>>>>>>>>>>>> +/*
>>>>>>>>>>>>>> + * Driver for Delta DPS920AB PSU
>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>> + * Copyright (C) 2021 Delta Networks, Inc.
>>>>>>>>>>>>>> + * Copyright (C) 2021 Sartura Ltd.
>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +#include <linux/i2c.h>
>>>>>>>>>>>>>> +#include <linux/module.h>
>>>>>>>>>>>>>> +#include <linux/of_device.h>
>>>>>>>>>>>>>> +#include "pmbus.h"
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +static struct pmbus_driver_info dps920ab_info = {
>>>>>>>>>>>>>> + .pages = 1,
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + .format[PSC_VOLTAGE_IN] = linear,
>>>>>>>>>>>>>> + .format[PSC_VOLTAGE_OUT] = linear,
>>>>>>>>>>>>>> + .format[PSC_CURRENT_IN] = linear,
>>>>>>>>>>>>>> + .format[PSC_CURRENT_OUT] = linear,
>>>>>>>>>>>>>> + .format[PSC_POWER] = linear,
>>>>>>>>>>>>>> + .format[PSC_FAN] = linear,
>>>>>>>>>>>>>> + .format[PSC_TEMPERATURE] = linear,
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN |
>>>>>>>>>>>>>> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
>>>>>>>>>>>>>> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
>>>>>>>>>>>>>> + PMBUS_HAVE_TEMP | PMBUS_HAVE_TEMP2 |
>>>>>>>>>>>>>> + PMBUS_HAVE_PIN | PMBUS_HAVE_POUT |
>>>>>>>>>>>>>> + PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12 |
>>>>>>>>>>>>>> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +static int dps920ab_probe(struct i2c_client *client)
>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>> + if (!i2c_check_functionality(client->adapter,
>>>>>>>>>>>>>> + I2C_FUNC_SMBUS_BYTE_DATA |
>>>>>>>>>>>>>> + I2C_FUNC_SMBUS_WORD_DATA))
>>>>>>>>>>>>>> + return -ENODEV;
>>>>>>>>>>>>>
>>>>>>>>>>>>> This check is done in pmbus_do_probe(), and repeating it here does not add
>>>>>>>>>>>>> any value.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, makes sense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That makes me wonder: Is this driver needed in the first place, or could
>>>>>>>>>>>>> it be added to drivers/hwmon/pmbus/pmbus.c ?
>>>>>>>>>>>>
>>>>>>>>>>>> It could be added as a generic driver, but that creates properties in
>>>>>>>>>>>> the sysfs that this thing
>>>>>>>>>>>> does not support like 3 voltage readings, 3 fans, and so on.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Can you be more specific ? What additional unsupported attributes
>>>>>>>>>>> are added, and why ? Are you saying the PSU reports registers as
>>>>>>>>>>> existing which do not really exist ? If so, which registers are those ?
>>>>>>>>>>
>>>>>>>>>> Sure, when core does probing and autodiscovery, then the following
>>>>>>>>>> sysfs attributes are created:
>>>>>>>>>>>
>>>>>>>>>>> curr1_crit fan3_fault in3_min_alarm temp1_max
>>>>>>>>>>> curr1_crit_alarm fan3_input in3_rated_max temp1_max_alarm
>>>>>>>>>>> curr1_input fan3_target in3_rated_min temp1_min
>>>>>>>>>>> curr1_label in1_crit name temp1_min_alarm
>>>>>>>>>>> curr1_max in1_crit_alarm of_node temp1_rated_max
>>>>>>>>>>> curr1_max_alarm in1_input power temp2_crit
>>>>>>>>>>> curr1_rated_max in1_label power1_alarm temp2_crit_alarm
>>>>>>>>>>> curr2_crit in1_lcrit power1_input temp2_input
>>>>>>>>>>> curr2_crit_alarm in1_lcrit_alarm power1_label temp2_lcrit
>>>>>>>>>>> curr2_input in1_max power1_max temp2_lcrit_alarm
>>>>>>>>>>> curr2_label in1_max_alarm power1_rated_max temp2_max
>>>>>>>>>>> curr2_lcrit in1_min power2_cap temp2_max_alarm
>>>>>>>>>>> curr2_lcrit_alarm in1_min_alarm power2_cap_alarm temp2_min
>>>>>>>>>>> curr2_max in1_rated_max power2_crit temp2_min_alarm
>>>>>>>>>>> curr2_max_alarm in1_rated_min power2_crit_alarm temp2_rated_max
>>>>>>>>>>> curr2_rated_max in2_input power2_input temp3_crit
>>>>>>>>>>> device in2_label power2_label temp3_crit_alarm
>>>>>>>>>>> fan1_alarm in3_crit power2_max temp3_input
>>>>>>>>>>> fan1_fault in3_crit_alarm power2_max_alarm temp3_lcrit
>>>>>>>>>>> fan1_input in3_input power2_rated_max temp3_lcrit_alarm
>>>>>>>>>>> fan1_target in3_label subsystem temp3_max
>>>>>>>>>>> fan2_alarm in3_lcrit temp1_crit temp3_max_alarm
>>>>>>>>>>> fan2_fault in3_lcrit_alarm temp1_crit_alarm temp3_min
>>>>>>>>>>> fan2_input in3_max temp1_input temp3_min_alarm
>>>>>>>>>>> fan2_target in3_max_alarm temp1_lcrit temp3_rated_max
>>>>>>>>>>> fan3_alarm in3_min temp1_lcrit_alarm uevent
>>>>>>>>>>
>>>>>>>>>> The following return -1, or -500 so they are not supported.
>>>>>>>>>> * fan2
>>>>>>>>>> * in2
>>>>>>>>>>
>>>>>>>>>> Weirdly, with the external driver both fan2 and in2 are enabled and work fine,
>>>>>>>>>> but when auto probing they are fan3 and in3.
>>>>>>>>>>
>>>>>>>>>> temp3 actually seems to return a valid temperature despite it not being used in
>>>>>>>>>> the vendor driver that features were picked from.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can you run "grep . *" in the hwmon directory so I can see actual values ?
>>>>>>>>>
>>>>>>>> Sure:
>>>>>>>>>
>>>>>>>>> curr1_crit:-500
>>>>>>>>> curr1_crit_alarm:0
>>>>>>>>> curr1_input:195
>>>>>>>>> curr1_label:iin
>>>>>>>>> curr1_max:-500
>>>>>>>>> curr1_max_alarm:0
>>>>>>>>> curr1_rated_max:-500
>>>>>>>>> curr2_crit:-500
>>>>>>>>> curr2_crit_alarm:0
>>>>>>>>> curr2_input:320
>>>>>>>>> curr2_label:iout1
>>>>>>>>> curr2_lcrit:-500
>>>>>>>>> curr2_lcrit_alarm:0
>>>>>>>>> curr2_max:18625
>>>>>>>>> curr2_max_alarm:0
>>>>>>>>> curr2_rated_max:16875
>>>>>>>>> grep: device: Is a directory
>>>>>>>>> fan1_alarm:0
>>>>>>>>> fan1_fault:0
>>>>>>>>> fan1_input:10000
>>>>>>>>> fan1_target:0
>>>>>>>>> fan2_alarm:1
>>>>>>>>> fan2_fault:1
>>>>>>>>> fan2_input:-1
>>>>>>>>> fan2_target:-1
>>>>>>>>> fan3_alarm:1
>>>>>>>>> fan3_fault:1
>>>>>>>>> fan3_input:-1
>>>>>>>>> fan3_target:-1
>>>>>>>>> in1_crit:-500
>>>>>>>>> in1_crit_alarm:0
>>>>>>>>> in1_input:245250
>>>>>>>>> in1_label:vin
>>>>>>>>> in1_lcrit:-500
>>>>>>>>> in1_lcrit_alarm:0
>>>>>>>>> in1_max:-500
>>>>>>>>> in1_max_alarm:0
>>>>>>>>> in1_min:-500
>>>>>>>>> in1_min_alarm:0
>>>>>>>>> in1_rated_max:-500
>>>>>>>>> in1_rated_min:-500
>>>>>>>>> in2_input:-500
>>>>>>>>> in2_label:vcap
>>>>>>>>> in3_crit:255996
>>>>>>>>> in3_crit_alarm:0
>>>>>>>>> in3_input:54511
>>>>>>>>> in3_label:vout1
>>>>>>>>> in3_lcrit:255996
>>>>>>>>> in3_lcrit_alarm:0
>>>>>>>>> in3_max:255996
>>>>>>>>> in3_max_alarm:0
>>>>>>>>> in3_min:255996
>>>>>>>>> in3_min_alarm:0
>>>>>>>>> in3_rated_max:56136
>>>>>>>>> in3_rated_min:52863
>>>>>>>>> name:dps920ab
>>>>>>>>> grep: of_node: Is a directory
>>>>>>>>> grep: power: Is a directory
>>>>>>>>> power1_alarm:0
>>>>>>>>> power1_input:33250000
>>>>>>>>> power1_label:pin
>>>>>>>>> power1_max:-500000
>>>>>>>>> power1_rated_max:-500000
>>>>>>>>> power2_cap:-500000
>>>>>>>>> power2_cap_alarm:0
>>>>>>>>> power2_crit:-500000
>>>>>>>>> power2_crit_alarm:0
>>>>>>>>> power2_input:17750000
>>>>>>>>> power2_label:pout1
>>>>>>>>> power2_max:-500000
>>>>>>>>> power2_max_alarm:0
>>>>>>>>> power2_rated_max:920000000
>>>>>>>>> grep: subsystem: Is a directory
>>>>>>>>> temp1_crit:-500
>>>>>>>>> temp1_crit_alarm:0
>>>>>>>>> temp1_input:23000
>>>>>>>>> temp1_lcrit:-500
>>>>>>>>> temp1_lcrit_alarm:0
>>>>>>>>> temp1_max:-500
>>>>>>>>> temp1_max_alarm:0
>>>>>>>>> temp1_min:-500
>>>>>>>>> temp1_min_alarm:0
>>>>>>>>> temp1_rated_max:-500
>>>>>>>>> temp2_crit:-500
>>>>>>>>> temp2_crit_alarm:0
>>>>>>>>> temp2_input:26000
>>>>>>>>> temp2_lcrit:-500
>>>>>>>>> temp2_lcrit_alarm:0
>>>>>>>>> temp2_max:-500
>>>>>>>>> temp2_max_alarm:0
>>>>>>>>> temp2_min:-500
>>>>>>>>> temp2_min_alarm:0
>>>>>>>>> temp2_rated_max:-500
>>>>>>>>> temp3_crit:-500
>>>>>>>>> temp3_crit_alarm:0
>>>>>>>>> temp3_input:30000
>>>>>>>>> temp3_lcrit:-500
>>>>>>>>> temp3_lcrit_alarm:0
>>>>>>>>> temp3_max:-500
>>>>>>>>> temp3_max_alarm:0
>>>>>>>>> temp3_min:-500
>>>>>>>>> temp3_min_alarm:0
>>>>>>>>> temp3_rated_max:-500
>>>>>>>>> uevent:OF_NAME=psu
>>>>>>>>> uevent:OF_FULLNAME=/ap806/config-space@...00000/i2c@...000/psu@5a
>>>>>>>>> uevent:OF_COMPATIBLE_0=delta,dps920ab
>>>>>>>>> uevent:OF_COMPATIBLE_N=1
>>>>>>>>
>>>>>>> Ok, good enough. It looks like the PSU reports values for pretty much everything,
>>>>>>> including registers which don't exist. With that in mind, please check
>>>>>>> the attributes generated by your driver - I suspect that some of the limit
>>>>>>> attributes are not really supported (maybe none of them is supported).
>>>>>>
>>>>>> Yeah, I also think that none of those limits are actually supported.
>>>>>> Does the core expose a way to not register those?
>>>>>>
>>>>>
>>>>> Have the read_word function return -ENXIO for unsupported registers
>>>>> (and add a comment to the code explaining why you do that).
>>>>> See drivers/hwmon/pmbus/fsp-3y.c for an example.
>>>>
>>>> Thanks, will implement that.
>>>> In the meantime I finally got the PMBus command list that
>>>> the PSU supports.
>>>> It implements PMBus 1.2, but it also claims that MFR_ID,
>>>> MFR_MODEL and MFR_REVISION are supported.
>>>>
>>>> Block read returns what looks like a correct length, but the buffer
>>>> is empty.
>>>>>
>>>>> [ 195.246464] dps920ab 0-005a: PMBUS_MFR_ID length: 5
>>>>> [ 195.251495] dps920ab 0-005a: PMBUS_MFR_ID:
>>>>> [ 195.300789] dps920ab 0-005b: PMBUS_MFR_ID length: 5
>>>>> [ 195.305762] dps920ab 0-005b: PMBUS_MFR_ID:
>>>>> [ 272.795222] dps920ab 0-005a: PMBUS_MFR_ID length: 5
>>>>> [ 272.800190] dps920ab 0-005a: PMBUS_MFR_ID:
>>>>> [ 272.804862] dps920ab 0-005a: PMBUS_MFR_MODEL length: 11
>>>>> [ 272.810172] dps920ab 0-005a: PMBUS_MFR_MODEL:
>>>>> [ 272.815098] dps920ab 0-005a: PMBUS_MFR_REVISION length: 2
>>>>> [ 272.820600] dps920ab 0-005a: PMBUS_MFR_REVISION:
>>>>> [ 272.874060] dps920ab 0-005b: PMBUS_MFR_ID length: 5
>>>>> [ 272.879102] dps920ab 0-005b: PMBUS_MFR_ID:
>>>>> [ 272.883833] dps920ab 0-005b: PMBUS_MFR_MODEL length: 11
>>>>> [ 272.889151] dps920ab 0-005b: PMBUS_MFR_MODEL:
>>>>> [ 272.894097] dps920ab 0-005b: PMBUS_MFR_REVISION length: 2
>>>>> [ 272.899548] dps920ab 0-005b: PMBUS_MFR_REVISION:
>>>>
>>>>
>>>> However, manually reading using i2cget in word mode returns
>>>> something that looks ok.
>>>> i2cget -y 0 0x5a 0x9a w
>>>> 0x440b
>>>>
>>>> This would be D is ASCII, it looks like any kind of block read fails actually.
>>>
>>> Ok, so after using i2c_smbus_read_i2c_block_data() I can actually read
>>> the model kind of OK.
>>> There actually are 10 bytes of valid data, no idea why
>>> i2c_smbus_read_block_data() does not work.
>>>>
>>>> [ 721.194706] dps920ab 0-005a: MFR MODEL:
>>>> DPS-920AB
>>>> [ 721.245502] dps920ab 0-005b: MFR MODEL:
>>>> DPS-920AB
>>>
>>> It behaves weirdly when printing by creating a newline before and
>>> stuff like that.
>>>
>>
>> I suspect it prints the first byte, which should be the length.
>> I also suspect that the i2c controller driver has a bug and doesn't
>> support SMBus block data correctly. Did you try i2cdump with i and s
>> options ?
>
> That could be the case, I just wanted to see whether the controller or
> PSU are at fault.
> I tried using s with i2cdump and it will error out on the controller
> not supporting block reads.
> The controller most likely has a bug in the driver.
>>
>>>> I tried applying the block support for mv64xx as well:
>>>> https://patchwork.ozlabs.org/project/linux-i2c/patch/20200118115820.9080-1-fuga@studiofuga.com/
>>
>> That patch would be needed, but it looks buggy to me. This chunk:
>>
>> + drv_data->effective_length = data+1;
>> + drv_data->bytes_left = data+1;
>> + drv_data->msg->len = data+1;
>>
>> should be:
>>
>> + drv_data->effective_length = data+1;
>> + drv_data->bytes_left = data;
>> + drv_data->msg->len = data+1;
>>
>> It should also make sure that 'data' is not larger than I2C_SMBUS_BLOCK_MAX,
>> and bail out if it isn't.
>
> Yeah, I did not check the contents, I just saw 2 reviews and tested it
> since it can't hurt.
That patch doesn't work at all. Make the above change, and also change
the type of effective_length from u32 to int, and try again.
Guenter
>>
>> Do you see a difference with the patch applied ?
>
> No, unfortunately not, i2cdump in s mode returns all zeroes.
> I can see that it gets the correct length but returns all zeroes.
>
> I did some development on the driver, added whitelisting for
> word-based registers.
> Found that this thing actually has the third temperature sensor after
> all and a lot of warnings
> and stuff are supported.
>
> I need to review the byte-based registers and whitelist those if needed.
>
> Tried adding PWM/DC control for the fan as it supports it, but it was
> a bit confusing so I
> gave up on that for now.
>
> Regards,
> Robert
>>
>> Guenter
>
>
>
Powered by blists - more mailing lists