public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
Cc: Eugene Zalkonnikov <ez@norphonic.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	"development@norphonic.com" <development@norphonic.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] Driver for TI HDC20x0 humidity and temperature sensors
Date: Fri, 6 Dec 2019 17:20:33 +0000	[thread overview]
Message-ID: <20191206172033.278503b6@archlinux> (raw)
In-Reply-To: <221cc09d-340c-b5b5-7af6-0608588598a1@norphonic.com>

On Tue, 3 Dec 2019 09:10:49 +0000
Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com> wrote:

> On 01.12.2019 13:36, Jonathan Cameron wrote:
> >  
> >> Heater out has been converted to IIO_CHAN_INFO_ENABLE, hope it is
> >> idiomatic use.  
> > Hmm. This is one of those cases where we are probably better off
> > matching existing drivers even if they are a bit illogical.
> >
> > The enable element is mainly used for counting type sensors (start
> > counting steps etc) where there is a clear difference between it
> > being on and taking a measurement.  
> OK, will revert that to prior.
> > +static const struct iio_chan_spec hdc2010_channels[] = {  
> >> +	{
> >> +		.type = IIO_TEMP,
> >> +		.address = HDC2010_REG_TEMP_LOW,
> >> +		.info_mask_shared_by_type =
> >> BIT(IIO_CHAN_INFO_OFFSET) |
> >> +			BIT(IIO_CHAN_INFO_SCALE),
> >> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> >> +	},
> >> +	{
> >> +		.type = IIO_TEMP,
> >> +		.address = HDC2010_REG_TEMP_MAX,
> >> +		.info_mask_separate = BIT(IIO_CHAN_INFO_PEAK),  
> > Not sure I like this approach of a separate channel.  The intent of
> > my previous review as to suggest we used a single channel. Here
> > we are really just adding one to get an address.  Whilst it works
> > today, this sort of unusual structure can make it harder to refactor
> > core elements of the code in the future.
> >
> > I'd rather see a bit of indirection where address actually gives
> > an enum value from which the data and _MAX registers can be
> > established via a lookup in an associated array.  
> 
> I see what you mean now. Was taking the name of .address field
> literally, but if anything goes there, sure.
> 

> While we are at it, there are four r/w threshold registers on the
> device for rh/temp. Should one implement them in the future, are they
> going to be also mixed into these somehow or can they be own event
> channels?

Look at the datasheet, that is one high and one low for each of
rh and temp?  Initially I thought you meant 2 in each direction for
each channel which we don't support (there is no means of
encoding it in the event code to userspace).

That can be handled just fine using the event setup for each channel
as one channel can have multiple event specs.

Thanks,

Jonathan



> 
> 
> --
> 
>   Eugene
> 


      parent reply	other threads:[~2019-12-06 17:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28 20:06 [PATCH v2 1/2] Driver for TI HDC20x0 humidity and temperature sensors Eugene Zalkonnikov
2019-11-28 20:12 ` [PATCH v2 2/2] " Eugene Zalkonnikov
2019-12-01 12:38   ` Jonathan Cameron
     [not found]     ` <EF648C3D-28B1-4509-AE3D-F24668A6849B@norphonic.com>
2019-12-03 11:41       ` Eugene Zalkonnikov
2019-12-06 17:14         ` Jonathan Cameron
2019-12-01 12:36 ` [PATCH v2 1/2] " Jonathan Cameron
2019-12-03  9:10   ` Eugene Zaikonnikov
2019-12-03 11:07     ` Eugene Zalkonnikov
2019-12-06 17:27       ` Jonathan Cameron
2019-12-06 17:20     ` Jonathan Cameron [this message]

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=20191206172033.278503b6@archlinux \
    --to=jic23@kernel.org \
    --cc=development@norphonic.com \
    --cc=eugene.zaikonnikov@norphonic.com \
    --cc=ez@norphonic.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@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