The ROHM BD79104 ADC is a 12 bit, 8-channel ADC controlled via SPI.

The communication over SPI uses similar protocol as the ti-adc128s052.
In order to avoid code duplication, the support for the ROHM IC is
added in the same driver.

The driver side differencies between the ti-adc128s052 and the ROHM
BD79104 are related to the supply regulator handling. The BD79104
requires supplies for the VDD and IOVDD. The ti-adc128s052 driver
handles only the reference voltage supply, even though the TI data-sheet
indicates it can also have separate supplies.

Hardware vise the ROHM BD79104 requires SPI MODE 3, and has also some SPI
frequency limitations.

I decided to add own binding document for the ROHM BD79104 so it is
easier to document the SPI limitations. It also allows using the supply
names from the data sheet. And finally, it gives users of this IC a
better hint that it is supported.

Finally, I didn't find maintainer information for this driver from the
MAINTAINERS file. I would like to add myself as a reviewer for the
driver, so I can stay on track of the changes to it. AFAIR, having
R-entry without M-entry was not appreciated. Any suggestions how to
handle this?

This series was based on the v6.14, but it should apply cleanly on
iio/testing - please let me know if I should rebase.

Revision history:

v1 => v2:
 - Drop the claim that original driver is broken for BE and rename the
   patch 0001 accordingly
 - Fix race when filling the SPI message
 - Check return value for the devm_mutex_init()
 - Add a RFC patch for dropping the support for variable Vref.

---

Matti Vaittinen (7):
  dt-bindings: ROHM BD79104 ADC
  iio: adc: ti-adc128s052: Simplify using be16_to_cpu()
  iio: adc: ti-adc128s052: Be consistent with arrays
  iio: adc: ti-adc128s052: Use devm_mutex_init()
  iio: adc: ti-adc128s052: Simplify using guard(mutex)
  iio: adc: ti-adc128s052: Support ROHM BD79104
  iio: ti-adc128s052: Drop variable vref

 .../bindings/iio/adc/rohm,bd79104.yaml        | 69 +++++++++++++
 drivers/iio/adc/Kconfig                       |  2 +-
 drivers/iio/adc/ti-adc128s052.c               | 99 +++++++++++--------
 3 files changed, 130 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/rohm,bd79104.yaml


base-commit: 543da6252b48bbfe13e194fb980bdd2b161f6838
-- 
2.49.0

On 02/04/2025 09:07, Matti Vaittinen wrote:

> Finally, I didn't find maintainer information for this driver from the
> MAINTAINERS file. I would like to add myself as a reviewer for the
> driver, so I can stay on track of the changes to it. AFAIR, having
> R-entry without M-entry was not appreciated. Any suggestions how to
> handle this?

Jonathan, I suppose this, by default,  falls under the umbrella of your 
IIO maintainership. Are you Okay with it if I'll add a maintainer entry 
which sets you explicitly as a maintainer for this, and list myself as a 
reviewer?

I suppose I could also add myself as a maintainer for this, but I am 
unsure how well it would be received by the TI people ;)

> This series was based on the v6.14, but it should apply cleanly on
> iio/testing - please let me know if I should rebase.

Just realized I forgot to update this. The series is now based on 
543da6252b48 in the iio/testing. Nonetheless, I can still rebase if needed.

Yours,
	-- Matti

On Wed, 2 Apr 2025 09:19:19 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> On 02/04/2025 09:07, Matti Vaittinen wrote:
> 
> > Finally, I didn't find maintainer information for this driver from the
> > MAINTAINERS file. I would like to add myself as a reviewer for the
> > driver, so I can stay on track of the changes to it. AFAIR, having
> > R-entry without M-entry was not appreciated. Any suggestions how to
> > handle this?  
> 
> Jonathan, I suppose this, by default,  falls under the umbrella of your 
> IIO maintainership. Are you Okay with it if I'll add a maintainer entry 
> which sets you explicitly as a maintainer for this, and list myself as a 
> reviewer?

Absolutely.  I'm find with you adding yourself as either R or M.
If you go with M and anyone objects, we can have more maintainers ;)
If you go with R the catch all is fine. I've never insisted on everyone
adding entries to maintainers on basis the catch all means I get
them all anyway.

Jonathan


> 
> I suppose I could also add myself as a maintainer for this, but I am 
> unsure how well it would be received by the TI people ;)
> 
> > This series was based on the v6.14, but it should apply cleanly on
> > iio/testing - please let me know if I should rebase.  
> 
> Just realized I forgot to update this. The series is now based on 
> 543da6252b48 in the iio/testing. Nonetheless, I can still rebase if needed.
> 
> Yours,
> 	-- Matti