Message-ID: <503521e1-f702-cefd-918a-cca2131272c2@roeck-us.net>
Date:   Sun, 4 Oct 2020 22:24:33 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Chu Lin <linchuyuan@...gle.com>
Cc:     jdelvare@...e.com, robh+dt@...nel.org, linux-hwmon@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] hwmon: pmbus: max20730: adjust the vout reading
 given voltage divider

On 10/4/20 8:07 PM, Chu Lin wrote:
> On Sun, Oct 4, 2020 at 8:43 AM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On Sun, Oct 04, 2020 at 03:14:45AM +0000, Chu Lin wrote:
>>> Problem:
>>> We use voltage dividers so that the voltage presented at the voltage
>>> sense pins is confusing. We might need to convert these readings to more
>>> meaningful readings given the voltage divider.
>>>
>>> Solution:
>>> Read the voltage divider resistance from dts and convert the voltage
>>> reading to a more meaningful reading.
>>>
>>> Testing:
>>> max20730 with voltage divider
>>>
>>> Signed-off-by: Chu Lin <linchuyuan@...gle.com>
>>> ---
>>> ChangeLog v1 -> v2
>>>   hwmon: pmbus: max20730:
>>>   - Don't do anything to the ret if an error is returned from pmbus_read_word
>>>   - avoid overflow when doing multiplication
>>>
>>> ChangeLog v2 -> v3
>>>   dt-bindings: hwmon: max20730:
>>>   - Provide the binding documentation in yaml format
>>>   hwmon: pmbus: max20730:
>>>   - No change
>>>
>>> ChangeLog v3 -> v4
>>>   dt-bindings: hwmon: max20730:
>>>   - Fix highefficiency to high efficiency in description
>>>   - Fix presents to present in vout-voltage-divider
>>>   - Add additionalProperties: false
>>>   hwmon: pmbus: max20730:
>>>   - No change
>>
>> You claim that there have been no changes since v2 of this patch,
>> yet you dropped my Reviewed-by: tag. Any reason ?
>>
>> Guenter
> Sorry for the confusion. I thought I can't tag the patch with the Review-by tag.
> Just to make sure I do correctly next time, once you tagged a certain
> patch in the batch
> If there is no change from version to version for this patch, I should
> carry the tags when
> submitting new revisions. Also, please let me know what is the best
> way to fix this revision?
> Should I submit a new V5 with the tag attached?
> 

Actually, if you did not make changes to a patch, you are _expected_
to carry tags forward. In many cases, submitters will even send a new
version of a patch with all new tags included (and no other changes).
This helps reviewers to keep track on what has been reviewed, acked,
or tested in a series. Dropping a tag means that you changed
a patch so substantially that the tag no longer applies (for example,
fixing a spelling error or some formatting does not normally warrant
dropping a tag). If you do drop a tag, you should explain the reason
in the change log.

That is, of course, a honor system that must not be abused
(unfortunately I have seen that abuse happen a couple of times
recently, but that is another story).

No need to re-send in this case - I'll just send another tag
to remind myself that I reviewed this patch.

Guenter

> Sincerely,
> Chu
> 
>>
>>>
>>>  drivers/hwmon/pmbus/max20730.c | 18 ++++++++++++++++++
>>>  1 file changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
>>> index a151a2b588a5..fbf2f1e6c969 100644
>>> --- a/drivers/hwmon/pmbus/max20730.c
>>> +++ b/drivers/hwmon/pmbus/max20730.c
>>> @@ -31,6 +31,7 @@ struct max20730_data {
>>>       struct pmbus_driver_info info;
>>>       struct mutex lock;      /* Used to protect against parallel writes */
>>>       u16 mfr_devset1;
>>> +     u32 vout_voltage_divider[2];
>>>  };
>>>
>>>  #define to_max20730_data(x)  container_of(x, struct max20730_data, info)
>>> @@ -114,6 +115,14 @@ static int max20730_read_word_data(struct i2c_client *client, int page,
>>>               max_c = max_current[data->id][(data->mfr_devset1 >> 5) & 0x3];
>>>               ret = val_to_direct(max_c, PSC_CURRENT_OUT, info);
>>>               break;
>>> +     case PMBUS_READ_VOUT:
>>> +             ret = pmbus_read_word_data(client, page, phase, reg);
>>> +             if (ret > 0 && data->vout_voltage_divider[0] && data->vout_voltage_divider[1]) {
>>> +                     u64 temp = DIV_ROUND_CLOSEST_ULL((u64)ret * data->vout_voltage_divider[1],
>>> +                                                      data->vout_voltage_divider[0]);
>>> +                     ret = clamp_val(temp, 0, 0xffff);
>>> +             }
>>> +             break;
>>>       default:
>>>               ret = -ENODATA;
>>>               break;
>>> @@ -364,6 +373,15 @@ static int max20730_probe(struct i2c_client *client,
>>>       data->id = chip_id;
>>>       mutex_init(&data->lock);
>>>       memcpy(&data->info, &max20730_info[chip_id], sizeof(data->info));
>>> +     if (of_property_read_u32_array(client->dev.of_node, "vout-voltage-divider",
>>> +                                    data->vout_voltage_divider,
>>> +                                    ARRAY_SIZE(data->vout_voltage_divider)) != 0)
>>> +             memset(data->vout_voltage_divider, 0, sizeof(data->vout_voltage_divider));
>>> +     if (data->vout_voltage_divider[1] < data->vout_voltage_divider[0]) {
>>> +             dev_err(dev,
>>> +                     "The total resistance of voltage divider is less than output resistance\n");
>>> +             return -ENODEV;
>>> +     }
>>>
>>>       ret = i2c_smbus_read_word_data(client, MAX20730_MFR_DEVSET1);
>>>       if (ret < 0)
>>> --
>>> 2.28.0.806.g8561365e88-goog
>>>

Powered by blists - more mailing lists