On Mon, 8 Mar 2021 10:07:05 +0000
"Sa, Nuno" [off-list ref] wrote:

quoted

-----Original Message-----
From: Jonathan Cameron <jic23@kernel.org>
Sent: Saturday, March 6, 2021 6:35 PM
To: Hennerich, Michael <Michael.Hennerich@analog.com>
Cc: zzzzArdelean, zzzzAlexandru <redacted>;
linux-kernel@vger.kernel.org; linux-iio@vger.kernel.org;
lars@metafoo.de; Sa, Nuno [off-list ref]; Bogdan, Dragos
[off-list ref]
Subject: Re: [PATCH v3 0/6] iio: Add output buffer support

On Fri, 5 Mar 2021 08:57:08 +0000
"Hennerich, Michael" [off-list ref] wrote:
  

quoted

Hi Jonathan and others,

With output/dac buffer support the semantics of the scan_element  

type may change.  

quoted

Today the Format is [be|le]:[s|u]bits/storagebitsXrepeat[>>shift].

While shift (if specified) is the shift that needs to be applied prior to  

masking out unused bits.  

quoted

So far so good and it sounds universal.

However, we use the right shift (operator) for that, which makes  

sense for capture devices.  

quoted

For output devices the more logical operator would be the left shift.

I'm not proposing a new Format here. I just want to get some  

agreement that for an output device  

quoted

 
le:s12/16>>4  

is understood as a left shift of 4, since the unused bits are then on  

the LSB.

Good question. Guess I wasn't thinking ahead when I came up with
that :)

I'm not sure I'd mind if we did decide to define a new format for
output
buffers. Feels like it should be easy to do.

What do others think?
  

I guess the most straight forward thing would be just to add a 'shift_l' variable
to 'struct scan_type'' and make sure either 'shift_l' or 'shift' is defined and then
properly export either ">>" or "<<" to userspace?

Given we already know it's an output channel, can we not just use that
to make the decision?

Jonathan

- Nuno Sá