All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/3] staging:iio: allow channels to be set up using a table of iio_channel_spec structures.
Date: Fri, 25 Mar 2011 15:37:01 +0100	[thread overview]
Message-ID: <201103251537.02030.arnd@arndb.de> (raw)
In-Reply-To: <1300997125-2896-2-git-send-email-jic23@cam.ac.uk>

On Thursday 24 March 2011, Jonathan Cameron wrote:
> +	
> +/**
> + * struct iio_chan_spec - specification of a single channel
> + * @type:	what type of measurement is the channel making
> + * @channel:	what number or name do we wish to asign the channel
> + * @channel2:	if there is a second number for a differential
> + *		channel then this is it.
> + * @address:	driver specific identifier.

Better make it "unsigned long" instead of int when it's driver specific.
That way, a driver can store a pointer here if necessary.

> +#define IIO_ST(si, rb, sb, sh)						\
> +	{ .sign = si, .realbits = rb, .storagebits = sb, .shift = sh }
> +
> +#define IIO_CHAN(_type, _chan, _inf_mask, _address, _si, _stype)		\
> +	{ .type = _type, .channel = _chan, .info_mask = _inf_mask,	\
> +			.address = _address,				\
> +			.scan_index = _si, .scan_type = _stype }
> +
> +#define IIO_CHAN_EV(_type, _chan, _inf_mask, _address, _si,		\
> +		    _stype, _event_mask, _shared_h)			\
> +	{ .type = _type,						\
> +			.channel = _chan,				\
> +			.info_mask = _inf_mask,				\
> +			.address = _address,				\
> +			.scan_index = _si, .scan_type = _stype,		\
> +			.event_mask = _event_mask,			\
> +			.shared_handler = _shared_h }
> +
> +#define IIO_CHAN_COMPOUND(_type, _chan1, _chan2, _inf_mask,_address, _si, _stype) \
> +	{ .type = _type, .channel = _chan1, .channel2 = _chan2,		\
> +			.info_mask = _inf_mask,				\
> +			.address = _address,				\
> +			.scan_index = _si, .scan_type = _stype }
> +
> +#define IIO_CHAN_COMPOUND_EV(_type, _chan1, _chan2, _inf_mask,		\
> +			     _address, _si, _stype, _event_mask, _shared_h) \
> +	{ .type = _type,						\
> +			.channel = _chan1, .channel2 = _chan2,		\
> +			.info_mask = _inf_mask,				\
> +			.address = _address,				\
> +			.scan_index = _si, .scan_type = _stype,		\
> +			.event_mask = _event_mask,			\
> +			.shared_handler = _shared_h}
> +
> +#define IIO_CHAN_SOFT_TIMESTAMP(_si)					\
> +	{ .type = IIO_TIMESTAMP, .channel = -1,				\
> +			.scan_index = _si, .scan_type = IIO_ST('s', 64, 64, 0) }

Maybe try to reduce the number of macros here. In many cases, doing the
assignment manually would be more readable than calling the macro with
unspecified arguments, IMHO.

> @@ -116,6 +248,31 @@ struct iio_dev {
>  	u32				*available_scan_masks;
>  	struct iio_trigger		*trig;
>  	struct iio_poll_func		*pollfunc;
> +
> +	struct iio_chan_spec *channels;
> +	int num_channels;
> +	struct list_head channel_attr_list;
> +
> +	char *name; /*device name - IMPLEMENT */
> +	int (*read_raw)(struct iio_dev *indio_dev, 
> +			struct iio_chan_spec *chan,
> +			int *val,
> +			long mask);
> +
> +	int (*read_event_config)(struct iio_dev *indio_dev,
> +				 int event_code);
> +
> +	int (*write_event_config)(struct iio_dev *indio_dev,
> +				  int event_code,
> +				  struct iio_event_handler_list *listel,
> +				  int state);
> +
> +	int (*read_event_value)(struct iio_dev *indio_dev,
> +				int event_code,
> +				int *val);
> +	int (*write_event_value)(struct iio_dev *indio_dev,
> +				 int event_code,
> +				 int val);
>  };

As mentioned in the comment for 2/3, a number of the members here are
constant, so you could split the structure into a per-driver constant
part and a per-device part, like most other subsystems do.

	Arnd

  reply	other threads:[~2011-03-25 14:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-24 20:05 [RFC PATCH 0/3] Experimenting with channel specification structures Jonathan Cameron
2011-03-24 20:05 ` [PATCH 1/3] staging:iio: allow channels to be set up using a table of iio_channel_spec structures Jonathan Cameron
2011-03-25 14:37   ` Arnd Bergmann [this message]
2011-03-25 15:15     ` Jonathan Cameron
2011-03-25 15:26       ` Arnd Bergmann
2011-03-24 20:05 ` [PATCH 2/3] staging:iio:lis3l02dq - experimental move to new channel_spec approach Jonathan Cameron
2011-03-25 14:26   ` Arnd Bergmann
2011-03-25 15:38     ` Jonathan Cameron
2011-03-25 16:02       ` Arnd Bergmann
2011-03-24 20:05 ` [PATCH 3/3] staging:iio:max1363 - experimental move to channel_spec registration Jonathan Cameron
2011-03-25 15:03 ` [RFC PATCH 0/3] Experimenting with channel specification structures Arnd Bergmann
2011-03-25 15:19   ` Jonathan Cameron

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=201103251537.02030.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=jic23@cam.ac.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.