linux-kernel - [PATCH 0/2] ADPD188 linux 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]

Date:   Fri, 8 Oct 2021 14:27:45 +0300
From:   <andrei.drimbarean@...log.com>
To:     <linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC:     <devicetree@...r.kernel.org>, <fazilyildiran@...il.com>,
        <andrei.drimbarean@...log.com>, <robh+dt@...nel.org>,
        <jic23@...nel.org>, <Michael.Hennerich@...log.com>,
        <lars@...afoo.de>
Subject: [PATCH 0/2] ADPD188 linux driver

From: Andrei Drimbarean <andrei.drimbarean@...log.com>

The ADPD188BI is a complete photometric system for smoke 
detection using optical dual wavelength technology. The module 
integrates an efficient photometric front end, two light 
emitting diodes (LEDs), and two photodiodes (PDs). 

The front end of the application specific integrated circuit 
(ASIC) consists of a control block, a 14-bit analog-to-digital 
converter (ADC) with a 20-bit burst accumulator, and three 
flexible, independently configurable LED drivers.

Datasheet information here: https://www.analog.com/media/en/technical-documentation/data-sheets/adpd188bi.pdf

The device is controlled via either SPI or I2C interface.

The first implementation used adpd188_spi/i2c.c to initialize regmap that
was then used in the core driver source. But the I2C implementation needed
to work with multiple daisy-chained devices. The properties of the
daisy-chained devices is that only one of them sets the sampling rate
automatically while the others sample when they receive a sample ready
signal from the previous device and only the last of the chain forwards and
interrupt to the host, which needs to read data from all devices at that
point.

Moreover, all devices start on power-up with the same I2C address, which is
not configurable in the hardware. It needs to be configured in software by
changing a register. To differentiate between devices that need to change
address and those that don't we set devices to change only when their GPIO1
is held high. Each device has its GPIO1 tied to GPIO0 of the previous
device, except the first device, which has its GPIO1 tied low.

So the way to change the addresses is as follows:
 1. Set all GPIO1 to high.
 2. Change devices that have GPIO1 tied high to a new address.
 3. Change GPIO1 to low for devices of the old address.
 4. Go to new address and repeat from step 1.

Because of this, a single driver instance ends up controlling multiple
physical devices that are daisy-chained at the same time.

Andrei Drimbarean (2):
  dt-bindings: add adpd188 schema
  drivers:iio:light: add ADPD188 driver support

 .../bindings/iio/light/adi,adpd188.yaml       |   72 +
 drivers/iio/light/Kconfig                     |   30 +
 drivers/iio/light/Makefile                    |    3 +
 drivers/iio/light/adpd188.c                   | 1389 +++++++++++++++++
 drivers/iio/light/adpd188.h                   |   64 +
 drivers/iio/light/adpd188_i2c.c               |  243 +++
 drivers/iio/light/adpd188_spi.c               |   97 ++
 7 files changed, 1898 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/adi,adpd188.yaml
 create mode 100644 drivers/iio/light/adpd188.c
 create mode 100644 drivers/iio/light/adpd188.h
 create mode 100644 drivers/iio/light/adpd188_i2c.c
 create mode 100644 drivers/iio/light/adpd188_spi.c

-- 
2.25.1