From: Guenter Roeck <linux@roeck-us.net>
To: Vikash Chandola <vikash.chandola@linux.intel.com>,
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 11:55:16 -0800 [thread overview]
Message-ID: <ea859778-92ba-ce22-7c17-4a891d5466e8@roeck-us.net> (raw)
In-Reply-To: <56283791-4b82-ad66-174b-49f717d224eb@linux.intel.com>
On 2/10/22 10:29, Vikash Chandola wrote:
>
>
> 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 ?
>
Good point. Interesting that I have not seen this before.
> 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 ?
>
No. What we need to do is to add code to pmbus_get_boolean() and selectively
write the reported status bit back into the status register. Something like
...
regval = status & mask;
if (regval) {
ret = pmbus_write_status(client, page, reg, regval);
^^^^^^^^^^^^^^^^^^ new function
if (ret)
goto unlock;
}
and that will need to be tested on a variety of real hardware.
Guenter
next prev parent reply other threads:[~2022-02-10 19:55 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
2022-02-10 19:55 ` Guenter Roeck [this message]
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=ea859778-92ba-ce22-7c17-4a891d5466e8@roeck-us.net \
--to=linux@roeck-us.net \
--cc=iwona.winiarska@intel.com \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vikash.chandola@linux.intel.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;
as well as URLs for NNTP newsgroup(s).