Re: [PATCH v3 4/4] iio: cdc: add Texas Instruments FDC1004 driver

[Victor Chernyakin]

> > I don't like the duplication either, but I think the real problem here is
> > that read_avail is just a somewhat awkward interface that doesn't allow me
> > to return s64 values directly. To me, having this separate decomposed table
> > just for read_avail and otherwise working with s64 values is the least bad
> > approach.
> 
> What about adding .read_avail64() (in a separate change)? Problem solved!

If Jonathan is open to such a new API, I could work on that! I think
if we're going to add it, instead of just changing the two int* parameters
to one s64*, we could add a union for the function to write into. That way,
not everything needs to be represented as raw s64's; we could introduce
a proper range type for example:

struct iio_range {
    s64 min;
    s64 step;
    s64 max;
};

struct iio_available_value {
    enum iio_available_type type; /* IIO_AVAIL_RANGE, etc. */
    union {
        const struct iio_range *range;
        struct {
            const s64 *vals;
            int num_vals;
        } list;
    };
};

/* Used like so: */

static const struct iio_range fdc1004_calibbias = {
	.min  = -0x8000 * 488281250UL,
	.step = +0x0001 * 488281250UL,
	.max  = +0x7FFF * 488281250UL,
};

static int fdc1004_read_avail_ext(struct iio_dev *indio_dev,
			                      const struct iio_chan_spec *chan,
			                      iio_available_value *out, long info)
{
	switch (info) {
	case IIO_CHAN_INFO_CALIBBIAS:
        out->range = &fdc1004_calibbias; /* No casts! */
        out->type = IIO_AVAIL_RANGE;
		return IIO_VAL_DECIMAL64_FEMTO;
    }
}