linux-kernel - [PATCH v2 0/2] Add ADXL367 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211207094337.59300-1-cosmin.tanislav@analog.com>
Date:   Tue,  7 Dec 2021 11:43:35 +0200
From:   Cosmin Tanislav <demonsingur@...il.com>
To:     unlisted-recipients:; (no To-header on input)
Cc:     cosmin.tanislav@...log.com, demonsingur@...il.com,
        Lars-Peter Clausen <lars@...afoo.de>,
        Michael Hennerich <Michael.Hennerich@...log.com>,
        Rob Herring <robh+dt@...nel.org>, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v2 0/2] Add ADXL367 driver

The ADXL367 is an ultralow power, 3-axis MEMS accelerometer.

The ADXL367 does not alias input signals to achieve ultralow power
consumption, it samples the full bandwidth of the sensor at all
data rates. Measurement ranges of +-2g, +-4g, and +-8g are available,
with a resolution of 0.25mg/LSB on the +-2 g range.

In addition to its ultralow power consumption, the ADXL367
has many features to enable true system level power reduction.
It includes a deep multimode output FIFO, a built-in micropower
temperature sensor, and an internal ADC for synchronous conversion
of an additional analog input.

V1 -> V2
 * add support for vdd and vddio supplies
 * lock fifo_watermark retrieval
 * fix indentation of sysfs_emit for fifo_mode
 * dt-bindings: add spi-max-frequency: true
 * dt-bindings: remove cs-gpios property
 * dt-bindings: remove status property
 * dt-bindings: add support for vdd

I have one question that is not actually specific to this driver but would
help me clear up some issues.

I used mutex_lock and mutex_unlock when accessing anything in driver's
state that could potentially be written by another process in parallel.

I heard mixed opinions about this. Some people said that it is not
necessary to lock everywhere because loads and stores for data with size
smaller or equal than register size would be done in one single atomic
instruction.

On the other hand, I also heard that this is not true unless WRITE_ONCE
and READ_ONCE is used.

It felt weird using WRITE_ONCE and READ_ONCE in this driver, so I kept
using mutexes.

Could I get some opinions on this matter?

Cosmin Tanislav (2):
  dt-bindings: iio: accel: add ADXL367
  iio: accel: add ADXL367 driver

 .../bindings/iio/accel/adi,adxl367.yaml       |   79 +
 MAINTAINERS                                   |   11 +
 drivers/iio/accel/Kconfig                     |   27 +
 drivers/iio/accel/Makefile                    |    3 +
 drivers/iio/accel/adxl367.c                   | 1696 +++++++++++++++++
 drivers/iio/accel/adxl367.h                   |   24 +
 drivers/iio/accel/adxl367_i2c.c               |   89 +
 drivers/iio/accel/adxl367_spi.c               |  151 ++
 8 files changed, 2080 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml
 create mode 100644 drivers/iio/accel/adxl367.c
 create mode 100644 drivers/iio/accel/adxl367.h
 create mode 100644 drivers/iio/accel/adxl367_i2c.c
 create mode 100644 drivers/iio/accel/adxl367_spi.c

-- 
2.34.1