linux-kernel - Re: [PATCH v2] iio: humidity: hdc3020: add threshold events support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 10 Feb 2024 16:11:17 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Dimitri Fedrau <dima.fedrau@...il.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Javier Carrasco
 <javier.carrasco.cruz@...il.com>, Li peiyu <579lpy@...il.com>, Lars-Peter
 Clausen <lars@...afoo.de>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] iio: humidity: hdc3020: add threshold events support


> > >   
> > > > 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