linux-kernel - Re: pmbus: dealing with unsigned mantissa in linear reading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 16 Jun 2021 01:57:50 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Guenter Roeck <linux@...ck-us.net>
CC:     Jean Delvare <jdelvare@...e.com>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: pmbus: dealing with unsigned mantissa in linear reading


On 16/06/21 1:46 pm, Guenter Roeck wrote:
> On Tue, Jun 15, 2021 at 11:34:53PM +0000, Chris Packham wrote:
>> Hi Guenter,
>>
>> I've had a report from someone testing the BPA-RS600.
>>
>> When they have the input voltage set to >= 256V (apparently the PSU can
>> handle input up to 264V). The Vin reading goes negative.
>>
>> CMD 0x88, VAL=0xf3f8, Vin=254
>> CMD 0x88, VAL=0xf3fc, Vin=255
>> CMD 0x88, VAL=0xf400, Vin=-256
>>
>> Looking at pmbus_reg2data_linear() the mantissa is cast to s16 which is
>> correct according to section 7.1 of the PMBUS spec which says that the
>> mantissa is an 11-bit two's complement value.
>>
>> It seems that the BPA-RS600 is using a non-standard format for the
>> mantissa (probably because the range of the standard linear encoding
>> can't support values >255V). Does the pmbus infrastructure provide a way
>> for me to define a custom format/conversion for a given sensor?
> Essentially you'll have to implement a custom read word function and
> convert the value reported by the power supply to a valid linear11
> value. In this case, you may have to shift the reported value by 1 bit
> and increase the exponent by one.

OK I'll look at doing that. I already have bpa_rs600_read_word_data() so 
I can hook in there.

> Not sure what you mean with "standard linear encoding can't support values
Yeah I figured that out after I sent the email. There are a few ways of 
representing >256V in a standard conforming way.
>> 255V". Why not ? That is what the exponent is for, after all. It rather
> seems to me that the PS vendor decided to violate the standard to get
> another bit of accuracy.

Indeed that seems to be the case.

> Guenter