Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Hennerich, Michael" <Michael.Hennerich@analog.com>
To:     Jonathan Cameron <jic23@kernel.org>,
        "zzzzArdelean, zzzzAlexandru" <alexandru.Ardelean@analog.com>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "lars@metafoo.de" <lars@metafoo.de>,
        "Sa, Nuno" <Nuno.Sa@analog.com>,
        "Bogdan, Dragos" <Dragos.Bogdan@analog.com>
Subject: RE: [PATCH v3 0/6] iio: Add output buffer support
Thread-Topic: [PATCH v3 0/6] iio: Add output buffer support
Thread-Index: AQHXBrxjYGT6Yhi/UU6po2kwD27epKpihP4AgBKjMjA=
Date:   Fri, 5 Mar 2021 08:57:08 +0000
Message-ID: <BN8PR03MB497724AAAFA43E6555554DC98E969@BN8PR03MB4977.namprd03.prod.outlook.com>
References: <20210219124012.92897-1-alexandru.ardelean@analog.com>
 <20210221120106.00ae1078@archlinux>
In-Reply-To: <20210221120106.00ae1078@archlinux>
Accept-Language: de-DE, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 539005b5-bfa9-4208-0171-08d8dfb4a8b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 08:57:08.9563
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eaa689b4-8f87-40e0-9c6f-7228de4d754a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FahSl3zMGrP/rlJr0qpvcXHSHrQtGQW5TNwX5JPNJ8ni4J3UuDYa8ilConQjeecjA8btL0hXd9LxGCNh5rUfUyZtIpzR5qgAZiq1co9Jdts=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR03MB3668
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.761
 definitions=2021-03-05_04:2021-03-03,2021-03-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0
 mlxlogscore=999 clxscore=1011 mlxscore=0 suspectscore=0 phishscore=0
 impostorscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2103050043
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Jonathan and others,

With output/dac buffer support the semantics of the scan_element type may c=
hange.

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 m=
asking out unused bits.

So far so good and it sounds universal.=20

However, we use the right shift (operator) for that, which makes sense for =
capture devices.
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

le:s12/16>>4

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

Thoughts?

Best Regards,
Michael

Analog Devices GmbH
Michael Hennerich=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=20
Otl-Aicher Strasse 60-64
D-80807 Muenchen; Germany

Sitz der Gesellschaft M=FCnchen, Registergericht M=FCnchen HRB 40368,
Gesch=E4ftsf=FChrer: Stefan Steyerl, Michael Paul Sondel, Yoon Ah Oh