Received-SPF: pass (google.com: domain of linux-kernel+bounces-60446-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 10 Feb 2024 16:11:17 +0000
From: Jonathan Cameron <jic23@kernel.org>
To: Dimitri Fedrau <dima.fedrau@gmail.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>, Javier Carrasco
 <javier.carrasco.cruz@gmail.com>, Li peiyu <579lpy@gmail.com>, Lars-Peter
 Clausen <lars@metafoo.de>, linux-iio@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iio: humidity: hdc3020: add threshold events support
Message-ID: <20240210161117.1bb3dd7f@jic23-huawei>
In-Reply-To: <20240205095323.GA2323766@debian>
References: <20240204103710.19212-1-dima.fedrau@gmail.com>
	<20240204144347.7f0eb822@jic23-huawei>
	<20240205070421.GA2264419@debian>
	<20240205093349.00003e10@Huawei.com>
	<20240205095323.GA2323766@debian>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


> > >   
> > > > As I mention below, I'm unconvinced that it makes sense to handle
> > > > these as pairs.
> > > >    
> > > For the threshold I could convert it as it is for the heater registers:
> > > 
> > > #define HDC3020_S_T_RH_THRESH_MSB	0x61
> > > #define HDC3020_S_T_RH_THRESH_LOW	0x00
> > > #define HDC3020_S_T_RH_THRESH_LOW_CLR	0x0B
> > > #define HDC3020_S_T_RH_THRESH_HIGH_CLR	0x16
> > > #define HDC3020_S_T_RH_THRESH_HIGH	0x1D
> > > 
> > > #define HDC3020_R_T_RH_THRESH_MSB	0xE1
> > > #define HDC3020_R_T_RH_THRESH_LOW	0x02
> > > #define HDC3020_R_T_RH_THRESH_LOW_CLR	0x09
> > > #define HDC3020_R_T_RH_THRESH_HIGH_CLR	0x14
> > > #define HDC3020_R_T_RH_THRESH_HIGH	0x1F
> > > 
> > > or:
> > > 
> > > #define HDC3020_S_T_RH_THRESH_LOW       0x6100
> > > #define HDC3020_S_T_RH_THRESH_LOW_CLR   0x610B
> > > #define HDC3020_S_T_RH_THRESH_HIGH_CLR  0x6116
> > > #define HDC3020_S_T_RH_THRESH_HIGH      0x611D
> > > 
> > > #define HDC3020_R_T_RH_THRESH_LOW       0x6102
> > > #define HDC3020_R_T_RH_THRESH_LOW_CLR   0x6109
> > > #define HDC3020_R_T_RH_THRESH_HIGH_CLR  0x6114
> > > #define HDC3020_R_T_RH_THRESH_HIGH      0x611F
> > > 
> > > I don't know if it's a good idea, as we would need to make sure it is
> > > big endian in the buffer. Probably with a function that handles this.  
> > I think this is the best plan with a
> > put_unaligned_be16() to deal with the endianness.
> > The compiler should be able to optimize that heavily.
> >  
> I think that would require some refactoring. I would add patches that
> are fixing this. Have there been reasons for using the pairs ? I'm just
> curious.

Not that I can think of. Maybe how they are represented on the
dataheet?  Often people just copy that stuff without thinking
about it (I know I've been guilty of this ;)

Jonathan