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;
Date:   Mon, 7 Feb 2022 11:24:20 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     "Sa, Nuno" <Nuno.Sa@analog.com>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH v1 2/2] iio: temperature: ltc2983: Make use of device
 properties
Message-ID: <YgDlRFmiys/Djgdx@smile.fi.intel.com>
References: <20220203114506.53904-1-andriy.shevchenko@linux.intel.com>
 <20220203114506.53904-2-andriy.shevchenko@linux.intel.com>
 <20220205171454.49a7225c@jic23-huawei>
 <Yf7ArwPrN34drkcv@smile.fi.intel.com>
 <PH0PR03MB6786C5F8E528249EBA938070992B9@PH0PR03MB6786.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <PH0PR03MB6786C5F8E528249EBA938070992B9@PH0PR03MB6786.namprd03.prod.outlook.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Sun, Feb 06, 2022 at 12:51:00PM +0000, Sa, Nuno wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Sent: Saturday, February 5, 2022 7:24 PM
> > On Sat, Feb 05, 2022 at 05:14:54PM +0000, Jonathan Cameron wrote:
> > > On Thu,  3 Feb 2022 13:45:06 +0200
> > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

...

> > > > +#include <asm/byteorder.h>
> > > > +#include <asm/unaligned.h>
> > 
> > > This may well be a valid addition but it's not called out in the patch
> > > description.
> > 
> > This is a side effect of the change. Below I will try to explain, tell me if
> > that is what you want to be added to the commit message (feel free to
> > correct
> > my English).
> > 
> > The conversion slightly changes the logic behind property reading for
> > the
> > configuration values. Original code allocates just as much memory as
> > needed.
> > Then for each separate 32- or 64-bit value it reads it from the property
> > and converts to a raw one which will be fed to the sensor. In the new
> > code
> > we allocated the amount of memory needed to retrieve all values at
> > once from
> > the property and then convert them as required.
> 
> Yeah, I understood what you are doing... We allocate some extra bytes so
> that we can simplify a lot the logic to get, convert and put back the properties
> in the table... And since we are only writing the __real__ table size into the device
> I'm fairly positive this works. However, I do agree with Jonathan and I would
> be more confident to give this a test before being applied...
> 
> That said, I'm off till the end of the month (just doing minor stuff like replying
> to emails :)), so if we can hold this one, I will test it first thing I'm back in the
> office.

Will wait for your testing. Meanwhile I address all other comments and send v3
for further review.

-- 
With Best Regards,
Andy Shevchenko