On Fri, 2020-04-17 at 10:19 +0100, Jonathan Cameron wrote: > This is really a question to address in a userspace library, not > a the level of the kernel interfaces. Whilst it may look lovely and > elegant to do it down in the kernel, having two interfaces to the > same > basic controls is often a recipe for long term disaster. It's fine > for userspace to iterate through all the options of each control and > build up a set of range pairs complete with how to get to them. We > could > simplify this by putting precedence into the ABI description. Right > now > I'm fairly sure we don't say anything on that. Hi Jonathan, and thanks for the comments, I assume your refer to scale and offset as the basic controls. In this case, having a new range member in iio_chan_info_enum that controls both scale and offset at the same time would mean that the write_raw would not need to implement direct setting of scale and offset. It could probably even be ensured at compile time that write_raw for scale and offset are not implemented when the range is implemented. Thus, write_raw would implement only the range (setting both offset and scale in the background), and read_raw would implement offset and scale to be able to read them and do the transform to physical units of the raw value. > > Now, the additional problem you have here is that may you have to > transition > through non existent states which makes for a slightly odd userspace > interface. > If you enable the channel when not in a valid state then that enable > will > have to fail. Exactly, and I would like if possible to avoid that because it implies code in kernel to handle those situations, and code in userspace to handle it too. I thought of a range as a solution but please come with other suggestions if you think this is not fit, maybe see the chip requirements below first to get a better idea. > > One reason we have never gone there for DACs in particular is that > its > not unheard of for changing the range to result in burnt tracks. > Hence > this is normally considered a board configuration question and pushed > to devicetree or similar. Devicetree should at least provide a list > of > 'safe' limits. > > What is the requirement driving this flexibility? Please check AD5770R datasheet, page 29, you may see where this requirement comes from. But this is definitely not the only chip requiring this, it is just a good fitting example. https://www.analog.com/media/en/technical-documentation/data-sheets/AD5770R.pdf Thanks and best regards, Darius Berghe
