Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Date:   Mon, 22 Aug 2022 09:28:05 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     "Farber, Eliav" <farbere@amazon.com>
Cc:     jdelvare@suse.com, robh+dt@kernel.org, mark.rutland@arm.com,
        linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, talel@amazon.com, hhhawa@amazon.com,
        jonnyc@amazon.com, hanochu@amazon.com, ronenk@amazon.com,
        itamark@amazon.com, shellykz@amazon.com, shorer@amazon.com,
        amitlavi@amazon.com, almogbs@amazon.com, dwmw@amazon.co.uk,
        rtanwar@maxlinear.com
Subject: Re: [PATCH v2 16/16] hwmon: (mr75203) add debugfs to read and write
 temperature coefficients
Message-ID: <20220822162805.GD4098765@roeck-us.net>
References: <20220817054321.6519-1-farbere@amazon.com>
 <20220817054321.6519-17-farbere@amazon.com>
 <20220818231106.GA3505191@roeck-us.net>
 <75165e58-8601-1fe5-7bdb-98761a73701f@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <75165e58-8601-1fe5-7bdb-98761a73701f@amazon.com>
Precedence: bulk

On Mon, Aug 22, 2022 at 04:59:43PM +0300, Farber, Eliav wrote:
> On 8/19/2022 2:11 AM, Guenter Roeck wrote:
> > On Wed, Aug 17, 2022 at 05:43:21AM +0000, Eliav Farber wrote:
> > > This change adds debugfs to read and write TS coefficients - g, h, j and
> > > cal5.
> > > 
> > > The coefficients can vary between product and product, so to calibrate
> > > them it can be very useful to to be able to modify them on the fly.
> > > 
> > > e.g.
> > > 
> > > cat /sys/kernel/debug/940f23d0000.pvt/ts_coeff_cal5
> > > 4096
> > > 
> > > echo 83000 > sys/kernel/debug/940f23d0000.pvt/ts_coeff_g
> > > 
> > 
> > What happens if you write 0 into all those attributes, or 0xffffffff ?
> The driver equation is:
> T = G + H * (n / cal5 - 0.5) + J * F
> So I added protection for cal5 not being 0.
> Besides that there is no limitation on what these values can be.
> I can't really think of any other logical limitation I can apply.
> 
There needs to be an overflow protection. I am quite sure that 0xffffffff
would result in overflows and thus in quite random reported values.

Thanks,
Guenter

> --
> Regards, Eliav