On Fri, Sep 5, 2025 at 9:42 AM Matti Vaittinen [off-list ref] wrote:

The ROHM BD79112 is an ADC/GPIO with 32 channels. The channel inputs can
be used as ADC or GPIO. Using the GPIOs as IRQ sources isn't supported.

The ADC is 12-bit, supporting input voltages up to 5.7V, and separate I/O
voltage supply. Maximum SPI clock rate is 20 MHz (10 MHz with
daisy-chain configuration) and maximum sampling rate is 1MSPS.

The IC does also support CRC but it is not implemented in the driver.

...

+config ROHM_BD79112
+       tristate "Rohm BD79112 ADC driver"
+       depends on I2C && GPIOLIB

Still I2C?

+       select REGMAP_SPI
+       select IIO_ADC_HELPER
+       help
+         Say yes here to build support for the ROHM BD79112 ADC. The
+         ROHM BD79112 is a 12-bit, 32-channel, SAR ADC, which analog

which --> where

+         inputs can also be used for GPIO.

...

+/*
+ * The data-sheet explains register I/O communication as follows:
+ *
+ * Read, two 16-bit sequences separated by CSB:
+ * MOSI:
+ * SCK:        | 1 | 2 | 3   | 4      | 5 .. 8 | 9 .. 16 |
+ * data:| 0 | 0 |IOSET| RW (1) | ADDR   | 8'b0    |
+ *
+ * MISO:
+ * SCK:        | 1 .. 8 | 9 .. 16 |
+ * data:| 8'b0   | data    |
+ *
+ * Note, CSB is shown to be released between writing the address (MOSI) and
+ * reading the register data (MISO).
+ *
+ * Write, single 16-bit sequence:
+ * MOSI:
+ * SCK:        | 1 | 2 | 3   | 4     | 5 .. 8 |
+ * data:| 0 | 0 |IOSET| RW(0) | ADDR   |
+ *
+ * MISO:
+ * SCK:        | 1 .. 8 |
+ * data:| data   |
+ */

What I meant in previous reviews is that the | are not aligned (in the
same columns). Is it on purpose? If so, I can't read that as I don't
understand the meaning of | in each case. For example, the data starts
with 0, followed by 0, and the latter one is when SCL is #1? Okay, but
how to read IOSET that overlaps 2 SCK cycles and is unaligned with
times... I'm really quite confused by these charts.

...

+        * Ouch. Seems the pin is ADC input - shouldn't happen as changing mux
+        * at runtime is not supported and non GPIO pins should be invalidated
+        * by the valid_mask at probe. Maybe someone wrote register bypassing

wrote a

+        * the driver?

-- 
With Best Regards,
Andy Shevchenko