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: Wed, 30 Nov 2022 22:22:42 +0530 [thread overview]
Message-ID: <75f01776-a95f-d0a7-4803-0b3d17f19800@9elements.com> (raw)
In-Reply-To: <6366dfd8-9e81-1ada-f41d-a687b4ab8e5a@roeck-us.net>
Hi Guenter,
On 29-11-2022 08:54 pm, Guenter Roeck wrote:
> On 11/28/22 23:55, Naresh Solanki wrote:
>> 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 ?
>
> It is a set of changes which needs input from regulator subsystem
> maintainers.
> Maybe it even needs changes on the regulator side, for example to report
> input and/or power failures properly.
>
> It isn't something I would have expected as part of a patch or patch series
> series which is supposed to add interrupt support to pmbus drivers.
> Since it is the first patch in your series, in may hold up the series
> for some period of time until the questions around it are resolved.
> Your call, really, how to handle it. Just don't be surprised if it takes
> a while to resolve the issues.
I'll check with regulator subsystem maintainer on input error & based on
feedback will post separate patch.
>
>>>
>>>> ---
>>>> 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.
>
> That would have to be a separate patch. It took me a while to understand
> how .func = -1 is handled, so without comment it just adds confusion.
Yes. Will make separate patch & add comment here.
>
>>>
>>>> + .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?
>
> Options are REGULATOR_ERROR_OVER_CURRENT or REGULATOR_ERROR_FAIL or
> a new failure code or doing nothing. Personally I think
> REGULATOR_ERROR_FAIL
> would be better if adding a new failure code is not an option.
Will update to REGULATOR_ERROR_FAIL.
>
> Anyway, clarify on the regulator subsystem mailing list how to handle input
> errors, and how to handle power failures. If they say it is acceptable to
> report input errors as output errors, and to report power failures as
> current failures, resubmit. Say in comments that this is what you are
> doing,
> and in the commit description that this is how input errors and power
> failures are handled in the regulator subsystem. Copy regulator subsystem
> maintainers on your patch.
Sure. Will hold back input errors for now & after checking with
regulator maintainer, will make separate patch accordingly.
>
> Thanks,
> Guenter
>
>>>> { },
>>>> },
>>>> }, {
>>>> @@ -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
>>>
>
Regards,
Naresh
prev parent reply other threads:[~2022-11-30 16:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 17:47 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
2022-11-29 15:24 ` Guenter Roeck
2022-11-30 16:52 ` Naresh Solanki [this message]
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=75f01776-a95f-d0a7-4803-0b3d17f19800@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
all inboxes | Powered by JetHome®