Re: [PATCH] hwmon: (pmbus/lm25066) Default coefficients for low current limit

On 11/27/2017 04:28 PM, Robert Lippert wrote: There seems to be no way to detect the value of the CL/GAIN pin from the device using PMBus. Low current mode seems to be recommended (from LM5066 datasheet) for improved current reporting accuracy in a typical design. Assume the device is in low

Re: [v3] hwmon: (pmbus) Use 64bit math for DIRECT format values

On Mon, Nov 27, 2017 at 03:51:55PM -0800, Robert Lippert wrote: > Power values in the 100s of watt range can easily blow past > 32bit math limits when processing everything in microwatts. > > Use 64bit math instead to avoid these issues on common 32bit ARM > BMC platforms. > > Signed-off-by:

Re: [PATCH] hwmon: (pmbus/lm25066) Swap low/high current coefficients for LM5066(i)

On Mon, Nov 27, 2017 at 2:08 PM, Guenter Roeck wrote: > On Mon, Nov 27, 2017 at 01:51:35PM -0800, Rob Lippert wrote: >> On Wed, Nov 22, 2017 at 5:17 PM, Guenter Roeck wrote: >> > Hi Rob, >> > >> > On 11/22/2017 03:39 PM, Rob Lippert wrote: >> >> >> >> On

[PATCH] hwmon: (pmbus/lm25066) Default coefficients for low current limit

There seems to be no way to detect the value of the CL/GAIN pin from the device using PMBus. Low current mode seems to be recommended (from LM5066 datasheet) for improved current reporting accuracy in a typical design. Assume the device is in low current mode unless the register override bit is

[PATCH v3] hwmon: (pmbus) Use 64bit math for DIRECT format values

Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Signed-off-by: Robert Lippert --- drivers/hwmon/pmbus/pmbus_core.c | 21

Re: [PATCH v2] hwmon: (pmbus) Use 64bit math for DIRECT format values

On Mon, Nov 27, 2017 at 2:11 PM, Guenter Roeck wrote: > On Mon, Nov 27, 2017 at 01:39:14PM -0800, Robert Lippert wrote: >> Power values in the 100s of watt range can easily blow past >> 32bit math limits when processing everything in microwatts. >> >> Use 64bit math instead to

Re: [PATCH v2] hwmon: (pmbus) Use 64bit math for DIRECT format values

On Mon, Nov 27, 2017 at 01:39:14PM -0800, Robert Lippert wrote: > Power values in the 100s of watt range can easily blow past > 32bit math limits when processing everything in microwatts. > > Use 64bit math instead to avoid these issues on common 32bit ARM > BMC platforms. > > Signed-off-by:

Re: [PATCH] hwmon: (pmbus/lm25066) Swap low/high current coefficients for LM5066(i)

On Mon, Nov 27, 2017 at 01:51:35PM -0800, Rob Lippert wrote: > On Wed, Nov 22, 2017 at 5:17 PM, Guenter Roeck wrote: > > Hi Rob, > > > > On 11/22/2017 03:39 PM, Rob Lippert wrote: > >> > >> On Wed, Nov 22, 2017 at 3:28 PM, Guenter Roeck wrote: > >>> > >>>

Re: [PATCH] hwmon: (pmbus/lm25066) Swap low/high current coefficients for LM5066(i)

On Wed, Nov 22, 2017 at 5:17 PM, Guenter Roeck wrote: > Hi Rob, > > On 11/22/2017 03:39 PM, Rob Lippert wrote: >> >> On Wed, Nov 22, 2017 at 3:28 PM, Guenter Roeck wrote: >>> >>> >>> On Wed, Nov 22, 2017 at 02:07:28PM -0800, Robert Lippert wrote:

[PATCH v2] hwmon: (pmbus) Use 64bit math for DIRECT format values

Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Signed-off-by: Robert Lippert --- drivers/hwmon/pmbus/pmbus_core.c | 23

Re: [PATCH] hwmon: (pmbus) Use 64bit math for DIRECT format values

On Wed, Nov 22, 2017 at 2:28 PM, Guenter Roeck wrote: > On Wed, Nov 22, 2017 at 02:08:43PM -0800, Robert Lippert wrote: >> Power values in the 100s of watt range can easily blow past >> 32bit math limits when processing everything in microwatts. >> >> Use 64bit math instead to

Re: [PATCH v2 1/2] hwmon: (jc42) optionally try to disable the SMBUS timeout

On Mon, Nov 27, 2017 at 05:31:00PM +0100, Peter Rosin wrote: > With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver > is not always capable of avoiding the 25-35 ms timeout as specified by > the SMBUS protocol. This may cause silent corruption of the last bit of > any transfer,

[PATCH v2 1/2] hwmon: (jc42) optionally try to disable the SMBUS timeout

With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out.

[PATCH v2 2/2] ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850

The I2C adapter driver is sometimes slow, causing the SCL line to be stuck low for more than the stipulated SMBUS timeout of 25-35 ms. This causes the client device to give up which in turn causes silent corruption of data. So, disable the SMBUS timeout in the client device. Signed-off-by: Peter

[PATCH v2 0/2] Sluggish AT91 I2C driver causes SMBus timeouts

Hi! [I was waiting for a comment from Rob for the initial submission, but that never came and I nearly forgot. Instead of pinging again, I'm resubmitting with the review comment from Guenter fixed, hoping that Rob will react this time.] This is a workaround for a problem in the AT91 I2C

Re: Overflow the hwmon API restricted to 32 bit signed integers

On Mon, Nov 27, 2017 at 09:54:44AM -0600, Eddie James wrote: > Hi Guenter, > > We're having a problem with overflowing signed 32 bit integers for reading > some hwmon attributes: > > struct hwmon_ops { umode_t (*is_visible)(const void *drvdata, enum > hwmon_sensor_types type, u32 attr, int

Overflow the hwmon API restricted to 32 bit signed integers

Hi Guenter, We're having a problem with overflowing signed 32 bit integers for reading some hwmon attributes: struct hwmon_ops { umode_t (*is_visible)(const void *drvdata, enum hwmon_sensor_types type, u32 attr, int channel); int (*read)(struct device *dev, enum hwmon_sensor_types type, u32