[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220819113548.GB3106213@roeck-us.net>
Date: Fri, 19 Aug 2022 04:35:48 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: "Farber, Eliav" <farbere@...zon.com>
Cc: jdelvare@...e.com, robh+dt@...nel.org, mark.rutland@....com,
linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, talel@...zon.com, hhhawa@...zon.com,
jonnyc@...zon.com, hanochu@...zon.com, ronenk@...zon.com,
itamark@...zon.com, shellykz@...zon.com, shorer@...zon.com,
amitlavi@...zon.com, almogbs@...zon.com, dwmw@...zon.co.uk,
rtanwar@...linear.com
Subject: Re: [PATCH v2 12/16] hwmon: (mr75203) modify the temperature equation
On Fri, Aug 19, 2022 at 10:44:06AM +0300, Farber, Eliav wrote:
> On 8/18/2022 11:23 PM, Guenter Roeck wrote:
> > On Wed, Aug 17, 2022 at 05:43:17AM +0000, Eliav Farber wrote:
> > > Modify the equation and coefficients to convert the digital output to
> > > temperature according to series 5 of the Moortec Embedded Temperature
> > > Sensor (METS) datasheet:
> > > T = G + H * (n / cal5 - 0.5) + J * F
> > >
> > > The G, H and J coefficients are multiplied by 1000 to get the
> > > temperature
> > > in milli-Celsius.
> > >
> >
> > This is, at the very least, confusing. It doesn't explain the discrepancy
> > to the old code nor the change in constant values. I have no idea if this
> > change would result in erroneous readings on some other system where
> > the existing calculation may be the correct one.
>
> When I tested the driver it was also not clear to me why the equation
> and coefficients in the code don't match the specifications in the data
> sheet.
> I reached out to Maxlinear engineers (@rtanwar) and they also couldn't
> explain the discrepancy.
> After further correspondence I aligned both the equation and coefficients
> in the driver code to the equation and coefficients defined in series 5
> of the Moortec Embedded Temperature Sensor (METS) datasheet which they
> provided.
>
At least some of the discrepancy is because the original code is more
optimized and avoids overflow. Either case, the above needs to be explained
in the commit description.
> > On top of that, it seems overflow-prune in 32 bit systems.
>
> I'll check if it can overflow, and if it can I'll fix in next version.
>
> --
> Regards, Eliav
>
Powered by blists - more mailing lists