linux-kernel - Re: [PATCH 7/8] iio: adc: ad7476: Support ROHM BD79105

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f33a391b-e7b1-422d-b265-4f00db3b9634@gmail.com>
Date: Thu, 7 Aug 2025 10:27:45 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: David Lechner <dlechner@...libre.com>,
 Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Jonathan Cameron <jic23@...nel.org>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/8] iio: adc: ad7476: Support ROHM BD79105

Thanks again David.

On 06/08/2025 18:23, David Lechner wrote:
> On 8/6/25 2:04 AM, Matti Vaittinen wrote:
>> The ROHM BD79105 is a simple 16-bit ADC accessible via SPI*.
>>
>> The BD79105 has a CONVSTART pin, which must be set high to start the ADC
>> conversion. Unlike with the ad7091 and ad7091r which also have a
>> CONVSTART pin, the BD79105 requires that the pin must remain high also
>> for the duration of the SPI access.
>>
>> (*) Couple of words about the SPI. The BD79105 has pins named as
>> CONVSTART, SCLK, DIN and DOUT. For the curious reader, DIN is not SPI
>> ISO.
>>
>> DIN is a signal which can be used as a chip-select. When DIN is pulled
>> low, the ADC will output the completed measurement via DOUT as SCLK is
>> clocked. According to the data-sheet, the DIN can also be used for
>> daisy-chaining multiple ADCs. Also, DOUT can be used also for a
> 
> Leave out one of the "also"s.
> 
>> 'data-ready' -IRQ. These modes aren't supported by this driver.
>>
>> Support reading ADC scale and data from the BD79105 using SPI, when DIN
>> is used as a chip-select.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
>> ---
>>   drivers/iio/adc/ad7476.c | 36 +++++++++++++++++++++++++++++++++++-
>>   1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
>> index 1f736be09663..fc98aadc4077 100644
>> --- a/drivers/iio/adc/ad7476.c
>> +++ b/drivers/iio/adc/ad7476.c

...

>> +
>> +static void bd79105_convst_enable(struct ad7476_state *st)
>> +{
>> +	if (!st->convst_gpio)
>> +		return;
>> +
>> +	gpiod_set_value(st->convst_gpio, 1);
>> +	udelay(1); /* 10ns required for conversion */
> 
> So ndelay(10)?

Thanks for pointing this out. This delay was something I thought I must 
clarify! This 10nS comment got just copied from the existing convstart, 
it probably is wrong for the bd79105.

...
  >>   	st->xfer.rx_buf = &st->data;
>>   	st->xfer.len = indio_dev->channels[0].scan_type.storagebits / 8;
>>   
>> @@ -393,6 +426,7 @@ static const struct spi_device_id ad7476_id[] = {
>>   	{ "ads7866", (kernel_ulong_t)&ads7866_chip_info },
>>   	{ "ads7867", (kernel_ulong_t)&ads7867_chip_info },
>>   	{ "ads7868", (kernel_ulong_t)&ads7868_chip_info },
>> +	{ "bd79105", (kernel_ulong_t)&bd79105_chip_info },
>>   	/*
>>   	 * The ROHM BU79100G is identical to the TI's ADS7866 from the software
>>   	 * point of view. The binding document mandates the ADS7866 to be
> 
> Unrelated to this patch, but interesting that we don't also have
> an of_ lookup table.

I am not sure what is the value of having the of_match table with the 
SPI devices. The SPI-ID will in any case be required for the module 
loading, and it can be built based on the DT compatible.

I admit I don't really know all the dirty details but, from what I can 
say, the only potential use would be if this driver supported two 
variants (which needed to be distinguished) with identical 
chip-compatible but different vendor part. I accept all education (also) 
on this matter though :)

Yours,
	-- Matti