Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14

[Conor Dooley]

On Tue, Jun 16, 2026 at 02:54:55PM -0500, David Lechner wrote:
> On 6/16/26 11:07 AM, Conor Dooley wrote:
> > On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
> >> Add new bindings for ti,ads122c14 and similar devices.
> >>
> >> This is an ADC that is primarily intended for use with temperature
> >> sensors. There are a few unusual properties because of this. In
> >> particular, the reference voltage source and current output requirements
> >> can be different for each measurement, so these are included in the
> >> channel bindings.
> >>
> >> The REFP/REFN reference voltage is usually just connected to a resistor
> >> that is being driven by the ADC's current outputs, so there is special
> >> property for this case rather than requiring a regulator to be defined
> >> to represent that.
> >>
> >> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> >> have preferred an enum of strings).
> >>
> >> Signed-off-by: David Lechner (TI) <dlechner@xxxxxxxxxxxx>
> >> ---
> >>  .../devicetree/bindings/iio/adc/ti,ads112c14.yaml  | 224 +++++++++++++++++++++
> >>  MAINTAINERS                                        |   7 +
> >>  include/dt-bindings/iio/adc/ti,ads112c14.h         |  11 +
> >>  3 files changed, 242 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> new file mode 100644
> >> index 000000000000..dc7f37cad772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> @@ -0,0 +1,224 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments' ADS112C14 and similar ADC chips
> >> +
> >> +description: |
> >> +  Supports the following Texas Instruments' ADC chips:
> >> +  - ADS112C14 (16-bit)
> >> +  - ADS122C14 (24-bit)
> >> +
> >> +  https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> >> +
> >> +  These chips are primarily designed for use with temperature sensors such as
> >> +  RTDs and thermocouples. The channel bindings reflect this in that each channel
> >> +  represents the conditions required to make a measurement rather than strictly
> >> +  just the physical input channels.
> >> +
> >> +maintainers:
> >> +  - David Lechner <dlechner@xxxxxxxxxxxx>
> >> +
> >> +unevaluatedProperties: false
> > 
> > Weird positioning of this.
> 
> IIRC, Rob asked that I do it in this order on another binding a while
> ago (the reasoning being that it was too far away from properties:
> otherwise), so I've done it like this on a few bindings now. It doesn't
> make much difference to me though.

Too far away because it refers to properties in the "main" node, but
appears conventionally after a rake of properties belonging to the
children?

> 
> > 
> >> +
> >> +properties:
> >> +  compatible:
> >> +    enum:
> >> +      - ti,ads112c14
> >> +      - ti,ads122c14
> >> +
> >> +  reg:
> >> +    items:
> >> +      - minimum: 0x40
> >> +        maximum: 0x47
> >> +
> >> +  clocks:
> >> +    maxItems: 1
> >> +    description: Optional external clock connected to GPIO3 pin.
> >> +
> >> +  avdd-supply: true
> >> +  dvdd-supply: true
> >> +
> >> +  refp-supply: true
> >> +  refn-supply: true
> >> +
> >> +  refp-refn-resistor-ohms:
> > 
> > Missing prefix here and elsewhere.
> 
> I thought we didn't need a prefix when using standard units.

You don't need a ref to a typedef, but you still need a prefix if it is
some random resistor that's specific to this device etc.

> >> +      ti,vref-source:
> >> +        description: |
> >> +          Indicates the source for the reference voltage for this channel.
> >> +          0 - Internal 2.5V reference
> >> +          1 - Internal 1.25V reference
> >> +          2 - External reference (REFP-REFN)
> >> +          3 - AVDD as reference
> > 
> > My usual complaint here about things you have to make macros for, could
> > these just be strings from the get-go?
> 
> As in the commit message, this is an existing property name, so I didn't want
> to change the type. But I agree that strings are better for this kind of thing
> so perhaps I should just use a different property name instead so we can do
> it better.

I wouldn't get too hung up on that sound adc, particularly since it
seems to have been added without an ack from a devicetree maintainer.
If you were trying to share a driver or something then I'd consider it
differently but these seem to be unrelated devices.

Attachment: signature.asc
Description: PGP signature