All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vikash Chandola <vikash.chandola@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>,
	iwona.winiarska@intel.com, jdelvare@suse.com,
	linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hwmon: (pmbus) Clear pmbus fault/warning bits before read
Date: Thu, 10 Feb 2022 23:59:31 +0530	[thread overview]
Message-ID: <56283791-4b82-ad66-174b-49f717d224eb@linux.intel.com> (raw)
In-Reply-To: <91104ef8-de89-aeb3-91ef-8925260e8782@roeck-us.net>



On 2/10/2022 10:55 PM, Guenter Roeck wrote:
> On 2/10/22 07:57, Vikash Chandola wrote:
>>
>>
>> On 2/10/2022 8:14 PM, Guenter Roeck wrote:
>>> On 2/10/22 04:41, Vikash Chandola wrote:
>>>> pmbus fault and warning bits are not cleared by itself once 
>>>> fault/warning
>>>> condition is not valid anymore. As per pmbus datasheet faults must be
>>>> cleared by user.
>>>> Modify hwmon behavior to clear latched status bytes if any bit in 
>>>> status
>>>> register is high prior to returning fresh data to userspace. If
>>>> fault/warning conditions are still applicable fault/warning bits 
>>>> will be
>>>> set and we will get updated data in second read.
>>>>
>>>> Hwmon behavior is changed here. Now sysfs reads will reflect latest
>>>> values from pmbus slave, not latched values.
>>>> In case a transient warning/fault has happened in the past, it will no
>>>> longer be reported to userspace.
>>>>
>>>
>>>
>>> NACK.
>>>
>>> Reporting that information is exactly the point of the current code.
>>> We _do_ want to report at least once that a problem occurred in the 
>>> past,
>>> and only clear the warning flag(s) afterwards.
>>>
>>> Guenter
>>>
>> But as per current implementation we will continue to report fault 
>> even after fault condition is cleared. I could not find sysfs entry or 
>> any other means by which user/kernel can clear the faults/warnings 
>> after it is reported. Please point if I am missing anything.
>>
> 
> Normally a chip should clear the status after the fault condition cleared
> and the register was read. At least that was my experience so far.
> What chip (or chips) don't do that ?
> 
> Guenter

I see that pmbus spec says that once fault/warning bits are set
they won't be cleared by itself. Section 10.2.3 of
"PMBus Specification Rev. 1.3.1 Part II 2015-03-13" from
https://pmbus.org/specification-archives/   says

"
Almost all of the warning or fault bits set in the status registers 
remain set, even if the fault or warning condition is removed
or corrected, until one of the following occur:
* The bit is individually cleared (Section 10.2.4),
* The device receives a CLEAR_FAULTS command (Section 15.1),
* A RESET signal (if one exists) is asserted,
* The output is commanded through the CONTROL pin, the OPERATION 
command, or the combined action of the CONTROL pin and OPERATION
command, to turn off and then to turn back on, or
* Bias power is removed from the PMBus device...
"

 From this I concluded that slave(PSU) following pmbus spec will not
clear the fault/warning in status registers.
I don't have exact chip details handy but I can get it by tomorrow.
However this looks to be issue not related to specific chip ?

If this is a problem, how should I approach this ? Shall I create a new
sysfs entry that user space application can invoke and clear all faults
or provide sysfs entry to clear individual fault/warning bits or
something else ?

> 
>>>> Signed-off-by: Vikash Chandola <vikash.chandola@linux.intel.com>
>>>> ---
>>>>   drivers/hwmon/pmbus/pmbus_core.c | 9 +++++++++
>>>>   1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/drivers/hwmon/pmbus/pmbus_core.c 
>>>> b/drivers/hwmon/pmbus/pmbus_core.c
>>>> index 776ee2237be2..1cc82d644079 100644
>>>> --- a/drivers/hwmon/pmbus/pmbus_core.c
>>>> +++ b/drivers/hwmon/pmbus/pmbus_core.c
>>>> @@ -577,6 +577,15 @@ static int pmbus_get_status(struct i2c_client 
>>>> *client, int page, int reg)
>>>>           break;
>>>>       default:
>>>>           status = _pmbus_read_byte_data(client, page, reg);
>>>> +        if (status > 0) {
>>>> +            /*
>>>> +             * Status greater than 0 could mean that there was a 
>>>> fault/warning.
>>>> +             * Clear faults and do a second read to make sure we 
>>>> are not getting
>>>> +             * stale values.
>>>> +             */
>>>> +            pmbus_clear_fault_page(client, page);
>>>> +            status = _pmbus_read_byte_data(client, page, reg);
>>>> +        }
>>>>           break;
>>>>       }
>>>>       if (status < 0)
>>>
> 

-- 
Vikash

  reply	other threads:[~2022-02-10 18:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 12:41 [PATCH] hwmon: (pmbus) Clear pmbus fault/warning bits before read Vikash Chandola
2022-02-10 14:44 ` Guenter Roeck
2022-02-10 15:57   ` Vikash Chandola
2022-02-10 17:25     ` Guenter Roeck
2022-02-10 18:29       ` Vikash Chandola [this message]
2022-02-10 19:55         ` Guenter Roeck
2022-02-10 19:57           ` Guenter Roeck
2022-02-22 13:20             ` Vikash Chandola

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=56283791-4b82-ad66-174b-49f717d224eb@linux.intel.com \
    --to=vikash.chandola@linux.intel.com \
    --cc=iwona.winiarska@intel.com \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.