All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "jdelvare@suse.com" <jdelvare@suse.com>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] hwmon: (pmbus/bpa-rs600) Add workaround for incorrect Pin max
Date: Wed, 11 Aug 2021 17:41:03 -0700	[thread overview]
Message-ID: <e86b8a83-bb5d-6d9b-298f-67a772e17539@roeck-us.net> (raw)
In-Reply-To: <f6d3654f-c1b1-65d2-2593-392e2cc2f0d2@alliedtelesis.co.nz>

On 8/11/21 4:25 PM, Chris Packham wrote:
> 
> On 12/08/21 11:18 am, Guenter Roeck wrote:
>> On Wed, Aug 11, 2021 at 10:19:44PM +0000, Chris Packham wrote:
>>> On 12/08/21 7:53 am, Guenter Roeck wrote:
>>>> On Wed, Aug 11, 2021 at 04:17:38PM +1200, Chris Packham wrote:
>>>>> BPD-RS600 modules running firmware v5.70 misreport the MFR_PIN_MAX.
>>>>> The indicate a maximum of 1640W instead of 700W. Detect the invalid
>>>>> reading and return a sensible value instead.
>>>>>
>>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>>>> ---
>>>>>     drivers/hwmon/pmbus/bpa-rs600.c | 21 ++++++++++++++++++++-
>>>>>     1 file changed, 20 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/hwmon/pmbus/bpa-rs600.c b/drivers/hwmon/pmbus/bpa-rs600.c
>>>>> index d495faa89799..f4baed9ce8a4 100644
>>>>> --- a/drivers/hwmon/pmbus/bpa-rs600.c
>>>>> +++ b/drivers/hwmon/pmbus/bpa-rs600.c
>>>>> @@ -65,6 +65,24 @@ static int bpa_rs600_read_vin(struct i2c_client *client)
>>>>>     	return ret;
>>>>>     }
>>>>>     
>>>>> +/*
>>>>> + * The firmware on some BPD-RS600 models incorrectly reports 1640W
>>>>> + * for MFR_PIN_MAX. Deal with this by returning a sensible value.
>>>>> + */
>>>>> +static int bpa_rs600_read_pin_max(struct i2c_client *client)
>>>>> +{
>>>>> +	int ret;
>>>>> +
>>>>> +	ret = pmbus_read_word_data(client, 0, 0xff, PMBUS_MFR_PIN_MAX);
>>>>> +	if (ret < 0)
>>>>> +		return ret;
>>>>> +
>>>>> +	if (ret == 0x0b34)
>>>>> +		return 0x095e;
>>>> The comments from the descriotion need to be here.
>>> will update
>>>> Thanks,
>>>> Guenter
>>>>
>>>>> +
>>>>> +	return ret;
>>>>> +}
>>>>> +
>>>>>     static int bpa_rs600_read_word_data(struct i2c_client *client, int page, int phase, int reg)
>>>>>     {
>>>>>     	int ret;
>>>>> @@ -92,7 +110,8 @@ static int bpa_rs600_read_word_data(struct i2c_client *client, int page, int pha
>>>>>     		ret = pmbus_read_word_data(client, 0, 0xff, PMBUS_MFR_IOUT_MAX);
>>>>>     		break;
>>>>>     	case PMBUS_PIN_OP_WARN_LIMIT:
>>>>> -		ret = pmbus_read_word_data(client, 0, 0xff, PMBUS_MFR_PIN_MAX);
>>>>> +	case PMBUS_MFR_PIN_MAX:
>>>>> +		ret = bpa_rs600_read_pin_max(client);
>>>> So the idea is to return the same value for PMBUS_PIN_OP_WARN_LIMIT
>>>> (max_alarm) and PMBUS_MFR_PIN_MAX (rated_max) ? That doesn't really
>>>> make sense. The meaning of those limits is distinctly different.
>>> For the BPA-RS600/BPD-RS600 these appear to be treated the same.
>> What a mess.
> *sigh* I know. I've also got another 2 BluTek supplies I haven't got
> round to dealing with yet.
>> This needs to be documented in the driver, including the
>> behavior if any of those attributes is written into.
> 
> Mercifully these attributes are all read-only. So at least we don't have
> to deal with that.
> 
Ok.

> It's probably not too late to return -ENXIO for the WARN_LIMITs and have
> lm-sensors display the rated_max (we also have a custom consumer of the
> sysfs API that I'd need to sort out).
> 

That would indeed be much better if it works for you.

Thanks,
Guenter

>>
>> Guenter
>>
>>>> Guenter
>>>>
>>>>>     		break;
>>>>>     	case PMBUS_POUT_OP_WARN_LIMIT:
>>>>>     		ret = pmbus_read_word_data(client, 0, 0xff, PMBUS_MFR_POUT_MAX);
>>>>> -- 
>>>>> 2.32.0
>>>> >


  reply	other threads:[~2021-08-12  0:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11  4:17 [PATCH 0/2] hwmon: (pmbus/bpa-rs600) cleanup and workaround Chris Packham
2021-08-11  4:17 ` [PATCH 1/2] hwmon: (pmbus/bpa-rs600) Remove duplicate defininitions Chris Packham
2021-08-11 19:53   ` Guenter Roeck
2021-08-11 21:58     ` Chris Packham
2021-08-11  4:17 ` [PATCH 2/2] hwmon: (pmbus/bpa-rs600) Add workaround for incorrect Pin max Chris Packham
2021-08-11 19:53   ` Guenter Roeck
2021-08-11 22:19     ` Chris Packham
2021-08-11 23:18       ` Guenter Roeck
2021-08-11 23:25         ` Chris Packham
2021-08-12  0:41           ` Guenter Roeck [this message]
2021-08-12  3:15 ` [PATCH 0/2] hwmon: (pmbus/bpa-rs600) cleanup and workaround Chris Packham
2021-08-12  4:29   ` Guenter Roeck

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=e86b8a83-bb5d-6d9b-298f-67a772e17539@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 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.