Hello Jonathan: > > With hwmon, we would have inX_input, inX_lowest, inX_highest (in fact, we > > had, as Xilinx XADC used to be hwmon -- just to explain where I'm coming > > from). So it made sense to me to use .extended_name = "lowest" to have > > in_voltageX_lowest_raw/_scale in addition to in_voltageX_raw/_scale (same > > index X). I understand that I may have read too much into the IIO code > > here, though, and if there's a better way to do this, I will gladly use > > it. > Hmm, we could as new info_mask elements (like _raw, _scale etc). > The nasty corner case is that we might also read them as part of a buffer > read. To do that they will need to be separate 'channels' in their own > right. > > I'm not entirely sure right now if you can distinguish channels purely on > the basis of extended name (and different scan index values), but that > might work, though would be a bit ugly. There is certainly no fundamental > reason you can't do this.. Oh my, it seems I have been a bit unclear here. In my implementation, lowest/highest *are* actually separate channels, with their own _raw and _scale. The Xilinx XADC controller has separate registers such as MIN_VCCINT and MAX_VCCINT in addition to VCCINT, and it was fairly straightforward to extend the existing channel set this way. So lowest/highest is orthogonal to raw/scale (which made it tempting to use .extend_name). lowest/highest use the same .channel index as the standard channel (so we have a group in_temp0_raw/_scale, in_temp0_lowest_raw/_scale, in_temp0_highest_raw/_scale), but their own .scan_index (as that has to be unique). Perhaps we should just use .extend_name = "vccint", "vccint_lowest", "vccint_highest"? (And NULL, "lowest", "highest" for channels which do not have a hard-wired purpose.) Best regards, Thomas Betker -- 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
