On 23/08/16 09:43, Matt Ranostay wrote:
> 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
This first one could indeed be done if anyone wanted to.
It not being present and getting to a submission would rather signal
a lack of testing with standard tools, but I guess this could happen
by 'accident' if someone adds something like a temperature channel
and only ever checks the sysfs interface.
>> scan_index == -1 and scan_type must NOT be provided
Not so keen on this one.
>>
>> 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..
It's fine to use it for this. Quite a few drivers IIRC have
done this in the past.
>
>>
>> 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
