Re: [PATCH 1/5] dt-bindings: iio: adc: Add TI ADS126x ADC family

[David Lechner <dlechner@baylibre.com>]

On 6/14/26 3:53 PM, Kurt Borja wrote:

...

>> Not a separate device node. Fold into the parent... or explain in
>> commit msg. You have entire commit msg to explain odd things.
>>
>> In that binding description you call it "independent", so it should have
>> its own SPI chip select? Why "independent" and part of this binding?
>> Maybe not independent, so basically part of this device?
> 
> It's independent in the sense that it is a proper subdevice on the same
> chip. It shares the serial interface but operates completely in
> parallel.
> 
> I decided to add a subnode because other devices might request their
> io-channels and most importantly a different voltage reference might be
> connected to it.
> 
> I'll clarify this in the commmit message on the next version. Although
> after seeing this submitted bindings [1], I wonder if it's a better
> approach to do something like
> 
> 	spi@0 {
> 		mydevice@0 {
> 			...
> 			adc@0 { ... };
> 			adc@1 { ... };
> 		};
> 	};
> 
> Any thoughts?

I don't see how this relates to the linked patch at all. The linked
patch looks just like a normal DAC binding.

What is the point of the 2nd ADC in this chip? Is it just to be able
to do simultaneous sampling of two different measurements at the same
time? We have other simultaneous sampling ADC chips and just model them
as a single device.

Since everything can be muxed to either ADC at runtime, I don't see
any reason the devicetree should care about it. Forcing certain pins
to be assigned to a certain ADC seems overly restrictive.

And unless you have an application that specifically needs it, I
wouldn't bother trying to implement the 2nd ADC in the IIO driver.
I didn't see any hints in the datasheet as to when it would actually
make sense to use this 2nd ADC. My first thought is that it might
make sense to use the 2nd ADC for a 2nd buffer so that you can do
2 buffered reads at the same time. But without knowing why this chip
was designed this way, I don't know if that is the right idea or not.


> Ack to the rest of comments.
> 
> [1] https://lore.kernel.org/linux-iio/20260519-ad5529r-driver-v3-1-267c0731aa68@analog.com/
>