openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Brandon Wyman <bjwyman@gmail.com>
Cc: linux-hwmon@vger.kernel.org, Jean Delvare <jdelvare@suse.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Eddie James <eajames@linux.ibm.com>,
	linux-kernel@vger.kernel.org, Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH v2] hwmon: (pmbus/ibm-cffps) Add clear_faults debugfs entry
Date: Wed, 16 Mar 2022 13:11:59 -0700	[thread overview]
Message-ID: <582086fe-1cc3-d161-a866-f4726d04a254@roeck-us.net> (raw)
In-Reply-To: <CAK_vbW2S07+S8+PrQnBLjvXYnLBXU06FHBvfM2zaT6RYx9HO+g@mail.gmail.com>

On 3/16/22 13:03, Brandon Wyman wrote:
> On Sun, Mar 13, 2022 at 11:36 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 3/11/22 10:10, Brandon Wyman wrote:
>>> Add a clear_faults write-only debugfs entry for the ibm-cffps device
>>> driver.
>>>
>>> Certain IBM power supplies require clearing some latched faults in order
>>> to indicate that the fault has indeed been observed/noticed.
>>>
>>
>> That is insufficient, sorry. Please provide the affected power supplies as
>> well as the affected faults, and confirm that the problem still exists
>> in v5.17-rc6 or later kernels - or, more specifically, in any kernel which
>> includes commit 35f165f08950 ("hwmon: (pmbus) Clear pmbus fault/warning
>> bits after read").
>>
>> Thanks,
>> Guenter
> 
> Sorry for the delay in responding. I did some testing with commit
> 35f165f08950. I could not get that code to send the CLEAR_FAULTS
> command to the power supplies.
> 
> I can update the commit message to be more specific about which power
> supplies need this CLEAR_FAULTS sent, and which faults. It is observed
> with the 1600W power supplies (2B1E model). The faults that latch are
> the VIN_UV and INPUT faults in the STATUS_WORD. The corresponding
> STATUS_INPUT fault bits are VIN_UV_FAULT and Unit is Off.
> 

The point is that the respective fault bits should be reset when the
corresponding alarm attributes are read. This isn't about executing
a CLEAR_FAULTS command, but about selectively resetting fault bits
while ensuring that faults are reported at least once. Executing
CLEAR_FAULTS is a big hammer.

With the patch I pointed to in place, input (and other) faults should
be reset after the corresponding alarm attributes are read, assuming
that the condition no longer exists. If that does not happen, we should
fix the problem instead of deploying the big hammer.

Thanks,
Guenter

>>
>>> Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
>>> ---
>>> V1 -> V2: Explain why this change is needed
>>>
>>>    drivers/hwmon/pmbus/ibm-cffps.c | 11 +++++++++++
>>>    1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/hwmon/pmbus/ibm-cffps.c b/drivers/hwmon/pmbus/ibm-cffps.c
>>> index e3294a1a54bb..3f02dde02a4b 100644
>>> --- a/drivers/hwmon/pmbus/ibm-cffps.c
>>> +++ b/drivers/hwmon/pmbus/ibm-cffps.c
>>> @@ -67,6 +67,7 @@ enum {
>>>        CFFPS_DEBUGFS_CCIN,
>>>        CFFPS_DEBUGFS_FW,
>>>        CFFPS_DEBUGFS_ON_OFF_CONFIG,
>>> +     CFFPS_DEBUGFS_CLEAR_FAULTS,
>>>        CFFPS_DEBUGFS_NUM_ENTRIES
>>>    };
>>>
>>> @@ -274,6 +275,13 @@ static ssize_t ibm_cffps_debugfs_write(struct file *file,
>>>                if (rc)
>>>                        return rc;
>>>
>>> +             rc = 1;
>>> +             break;
>>> +     case CFFPS_DEBUGFS_CLEAR_FAULTS:
>>> +             rc = i2c_smbus_write_byte(psu->client, PMBUS_CLEAR_FAULTS);
>>> +             if (rc < 0)
>>> +                     return rc;
>>> +
>>>                rc = 1;
>>>                break;
>>>        default:
>>> @@ -607,6 +615,9 @@ static int ibm_cffps_probe(struct i2c_client *client)
>>>        debugfs_create_file("on_off_config", 0644, ibm_cffps_dir,
>>>                            &psu->debugfs_entries[CFFPS_DEBUGFS_ON_OFF_CONFIG],
>>>                            &ibm_cffps_fops);
>>> +     debugfs_create_file("clear_faults", 0200, ibm_cffps_dir,
>>> +                         &psu->debugfs_entries[CFFPS_DEBUGFS_CLEAR_FAULTS],
>>> +                         &ibm_cffps_fops);
>>>
>>>        return 0;
>>>    }
>>


  reply	other threads:[~2022-03-16 21:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 18:10 [PATCH v2] hwmon: (pmbus/ibm-cffps) Add clear_faults debugfs entry Brandon Wyman
2022-03-14  4:36 ` Guenter Roeck
2022-03-16 20:03   ` Brandon Wyman
2022-03-16 20:11     ` Guenter Roeck [this message]
2022-03-17 16:12       ` Brandon Wyman
2022-03-17 18:50         ` Guenter Roeck
2022-03-17 23:30           ` Brandon Wyman

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=582086fe-1cc3-d161-a866-f4726d04a254@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=bjwyman@gmail.com \
    --cc=eajames@linux.ibm.com \
    --cc=jdelvare@suse.com \
    --cc=joel@jms.id.au \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    /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).