Linux Hardware Monitor development
 help / color / mirror / Atom feed
From: Naresh Solanki <naresh.solanki@9elements.com>
To: Guenter Roeck <linux@roeck-us.net>,
	linux-hwmon@vger.kernel.org, Jean Delvare <jdelvare@suse.com>
Cc: Patrick Rudolph <patrick.rudolph@9elements.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] hwmon: (pmbus/core): Update regulator flag map
Date: Tue, 29 Nov 2022 13:25:20 +0530	[thread overview]
Message-ID: <32b17cb1-754f-684b-a7d2-583d2e32030f@9elements.com> (raw)
In-Reply-To: <bbba5774-b886-df08-1263-7e3489b84a8e@roeck-us.net>

Hi Guenter,

On 29-11-2022 04:11 am, Guenter Roeck wrote:
> On 11/28/22 09:47, Naresh Solanki wrote:
>> Add regulator flag map for PMBUS status byte & status input.
>>
>> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
> 
> You are adding a lot of input errors here. The regulator documentation
> only covers output errors. I am not sure if this set of changes is
> really appropriate. You'll have to make a much better case for those 
> changes;
> from what I can see they are all controversial and were originally left out
> on purpose.
I felt it may be worth to monitor status input, but you feel otherwise 
then shall I remove this in next revision ?
> 
>> ---
>>   drivers/hwmon/pmbus/pmbus_core.c | 30 ++++++++++++++++++++++--------
>>   1 file changed, 22 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/hwmon/pmbus/pmbus_core.c 
>> b/drivers/hwmon/pmbus/pmbus_core.c
>> index 95e95783972a..f5caceaaef2a 100644
>> --- a/drivers/hwmon/pmbus/pmbus_core.c
>> +++ b/drivers/hwmon/pmbus/pmbus_core.c
>> @@ -2752,6 +2752,15 @@ struct pmbus_regulator_status_category {
>>   static const struct pmbus_regulator_status_category 
>> pmbus_regulator_flag_map[] = {
>>       {
>> +        .func = -1,
> 
> This would need a comment. I don't really see the benefit over the original
> code.
I pulled that in so as to handle it in same way as other status register.
> 
>> +        .reg = PMBUS_STATUS_BYTE,
>> +        .bits = (const struct pmbus_regulator_status_assoc[]) {
>> +            { PB_STATUS_IOUT_OC,   REGULATOR_ERROR_OVER_CURRENT },
>> +            { PB_STATUS_VOUT_OV,   REGULATOR_ERROR_REGULATION_OUT },
>> +            { PB_STATUS_VIN_UV,    REGULATOR_ERROR_UNDER_VOLTAGE },
>> +            { },
>> +        },
>> +    }, {
>>           .func = PMBUS_HAVE_STATUS_VOUT,
>>           .reg = PMBUS_STATUS_VOUT,
>>           .bits = (const struct pmbus_regulator_status_assoc[]) {
>> @@ -2768,6 +2777,7 @@ static const struct 
>> pmbus_regulator_status_category pmbus_regulator_flag_map[] =
>>               { PB_IOUT_OC_WARNING,    
>> REGULATOR_ERROR_OVER_CURRENT_WARN },
>>               { PB_IOUT_OC_FAULT,      REGULATOR_ERROR_OVER_CURRENT },
>>               { PB_IOUT_OC_LV_FAULT,   REGULATOR_ERROR_OVER_CURRENT },
>> +            { PB_POUT_OP_FAULT,      REGULATOR_ERROR_OVER_CURRENT },
> 
> OP_FAULT (power fault) and over current are really not the same thing.
> 
I agree. But thats best I could think of. Not sure if there is better 
REGULATOR_ERROR_* code for this scenario. Suggestions?
>>               { },
>>           },
>>       }, {
>> @@ -2778,6 +2788,18 @@ static const struct 
>> pmbus_regulator_status_category pmbus_regulator_flag_map[] =
>>               { PB_TEMP_OT_FAULT,      REGULATOR_ERROR_OVER_TEMP },
>>               { },
>>           },
>> +    }, {
>> +        .func = PMBUS_HAVE_STATUS_INPUT,
>> +        .reg = PMBUS_STATUS_INPUT,
>> +        .bits = (const struct pmbus_regulator_status_assoc[]) {
>> +            { PB_IIN_OC_FAULT,       REGULATOR_ERROR_OVER_CURRENT },
>> +            { PB_IIN_OC_WARNING,     
>> REGULATOR_ERROR_OVER_CURRENT_WARN },
>> +            { PB_VOLTAGE_UV_FAULT,   REGULATOR_ERROR_UNDER_VOLTAGE },
>> +            { PB_VOLTAGE_UV_WARNING, 
>> REGULATOR_ERROR_UNDER_VOLTAGE_WARN },
>> +            { PB_VOLTAGE_OV_WARNING, 
>> REGULATOR_ERROR_OVER_VOLTAGE_WARN },
>> +            { PB_VOLTAGE_OV_FAULT,   
>> REGULATOR_ERROR_OVER_VOLTAGE_WARN },
> 
> fault -> warning ? Shouldn't this be REGULATOR_ERROR_FAIL (Regulator
> output has failed) ?
> 
Yes. REGULATOR_ERROR_FAIL is best fit here. Will update in next revision.
>> +            { },
>> +        },
>>       },
>>   };
>> @@ -2834,14 +2856,6 @@ static int 
>> pmbus_regulator_get_error_flags(struct regulator_dev *rdev, unsigned
>>           if (status & PB_STATUS_POWER_GOOD_N)
>>               *flags |= REGULATOR_ERROR_REGULATION_OUT;
>>       }
>> -    /*
>> -     * Unlike most other status bits, PB_STATUS_{IOUT_OC,VOUT_OV} are
>> -     * defined strictly as fault indicators (not warnings).
>> -     */
>> -    if (status & PB_STATUS_IOUT_OC)
>> -        *flags |= REGULATOR_ERROR_OVER_CURRENT;
>> -    if (status & PB_STATUS_VOUT_OV)
>> -        *flags |= REGULATOR_ERROR_REGULATION_OUT;
>>       /*
>>        * If we haven't discovered any thermal faults or warnings via
>>
>> base-commit: 9494c53e1389b120ba461899207ac8a3aab2632c
> 

  reply	other threads:[~2022-11-29  7:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 17:47 [PATCH v2 1/3] hwmon: (pmbus/core): Update regulator flag map Naresh Solanki
2022-11-28 17:47 ` [PATCH v2 2/3] hwmon: (pmbus/core): Add events to " Naresh Solanki
2022-11-28 17:47 ` [PATCH v2 3/3] hwmon: (pmbus/core): Implement irq support Naresh Solanki
2022-11-28 23:09   ` Guenter Roeck
2022-11-29  8:16     ` Naresh Solanki
2022-11-29 15:29       ` Guenter Roeck
2022-11-30 16:54         ` Naresh Solanki
2022-11-28 22:41 ` [PATCH v2 1/3] hwmon: (pmbus/core): Update regulator flag map Guenter Roeck
2022-11-29  7:55   ` Naresh Solanki [this message]
2022-11-29 15:24     ` Guenter Roeck
2022-11-30 16:52       ` Naresh Solanki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32b17cb1-754f-684b-a7d2-583d2e32030f@9elements.com \
    --to=naresh.solanki@9elements.com \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=patrick.rudolph@9elements.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox