> > > > > > * Programmable quiescent current (optional) > > Could probably figure out a suitable control for this, but I'm not entirely sure > > what it is :) > > Thinking about it, wouldn't the raw attribute be a suitable control for this? This > Value is relative to nominal supply current and acts as a "monotonic but nonlinear" > multiplier. > A register value maps to a current level from 0 to 2 times the nominal > current supplied. I also thought that it could be hardware gain but the gain > computation wasn't explicitly indicated in the datasheet and there is not yet > "current_hardwaregain" attribute available in the ABI. So I settled with raw. I don't entirely understand what is actually for, but a raw current output might be appropriate. >I > Think there would only be an issue of we expose the "processed" attribute > Because it has a particular computation. But I'm not planning to expose the > Processed attribute Is there any reason someone might in future though? > > > > > * Thermal monitoring is done by measuring voltage on TMP pin > > > > (unlikely to be included) > > > > If you did want to, the usual trick for these is to include an optional use as a > > consumer of an IIO provider which would be a separate ADC. > > I included this in my current revision, thanks for the idea. Although the optional use > Isn’t yet available in the consumer API. My question is, in case the ADC channel to read > The TMP pin is not available, should I still make the temp raw value available and > Set to 0? Or should the temp raw attribute be unavailable or unlisted completely from > IIO Info. If no ADC channel then remove it from the chan_spec. That probably means you need separate arrays of struct iio_chan_spec for the two case. Jonathan > > > > > > > > > > Adding myself to the cc: here since I'm interested to see what > > > Jonathan (or anyone else) has to say about the fault monitoring. > > > > Jonathan
