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
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
