On Tue, Aug 23, 2016 at 1:10 AM, Peter Meerwald-Stadler
<pmeerw@xxxxxxxxxx> wrote:
>
>> >> struct vz89x_data {
>> >> @@ -79,6 +92,40 @@ static const struct iio_chan_spec vz89x_channels[] = {
>> >> .info_mask_separate =
>> >> BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
>> >> .address = VZ89X_VOC_RESISTANCE_IDX,
>> >> + .scan_index = -1,
>> >> + .scan_type = {
>> >
>> > scan_type with a scan_index of -1 is unexpected
>>
>> Isn't that the typical usage to signal a non bufffered channel?.
>> But guess the lack of storage, real bits, and buffered trigger
>> register would signal that anyway.
>
> scan_index == -1 signals that scan_type is not used for buffered reads,
> but then scan_type is used to store endianness
>
> one *could* want a check/invariant that either
> scan_index >= 0 and scan_type must be provided, and
> scan_index == -1 and scan_type must NOT be provided
>
> no bit deal, maybe there is an easy way to store the channel endianness
> elsewhere; maybe a chip_info struct?
>
> I haven't checked (yet) what other drivers do in this regards...
No real reason to do it here but since the struct already exists to
store this bit of information... maybe Jonathan has feedback either
way..
>
> p.
>
> --
>
> Peter Meerwald-Stadler
> +43-664-2444418 (mobile)
--
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
