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
Date: Sat, 10 Feb 2024 16:11:17 +0000 [thread overview]
Message-ID: <20240210161117.1bb3dd7f@jic23-huawei> (raw)
In-Reply-To: <20240205095323.GA2323766@debian>
> > >
> > > > 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
next prev parent reply other threads:[~2024-02-10 16:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-04 10:37 [PATCH v2] iio: humidity: hdc3020: add threshold events support Dimitri Fedrau
2024-02-04 11:26 ` Javier Carrasco
2024-02-04 12:38 ` Dimitri Fedrau
2024-02-04 14:43 ` Jonathan Cameron
2024-02-05 7:04 ` Dimitri Fedrau
2024-02-05 9:33 ` Jonathan Cameron
2024-02-05 9:53 ` Dimitri Fedrau
2024-02-10 16:11 ` Jonathan Cameron [this message]
2024-02-12 15:20 ` Dimitri Fedrau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240210161117.1bb3dd7f@jic23-huawei \
--to=jic23@kernel.org \
--cc=579lpy@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=dima.fedrau@gmail.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox