Re: [PATCH v2 2/4] dt-bindings: iio: dac: add adi,ad5710r.yaml
Conor Dooley <[email protected]> Wed, 29 Jul 2026 18:11:14 +0100
| Newsgroups | org.kernel.vger.linux-iio,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260729-empower-suitcase-bca517bf113e@spud> |
On Tue, Jul 28, 2026 at 09:44:50PM +0100, Jonathan Cameron wrote: > On Tue, 28 Jul 2026 16:41:26 +0100 > Conor Dooley <[email protected]> wrote: > > > On Fri, Jul 24, 2026 at 10:57:38PM +0100, Jonathan Cameron wrote: > > > On Tue, 21 Jul 2026 16:52:10 +0100 > > > Conor Dooley <[email protected]> wrote: > > > > > > > On Tue, Jul 21, 2026 at 04:47:11PM +0800, Kim Seer Paller wrote: > > > > > Add device tree bindings for the Analog Devices AD5710R/AD5711R > > > > > 8-channel 12-/16-bit Configurable IDAC/VDAC. > > > > > > > > > > Signed-off-by: Kim Seer Paller <[email protected]> > > > > > --- > > > > > .../devicetree/bindings/iio/dac/adi,ad5710r.yaml | 143 +++++++++++++++++++++ > > > > > > > > > +patternProperties: > > > > > + "^channel@[0-7]$": > > > > > + $ref: /schemas/iio/dac/dac.yaml# > > > > > + type: object > > > > > + description: > > > > > + Represents the external channels which are connected to the DAC. > > > > > + > > > > > + properties: > > > > > + reg: > > > > > + description: Channel number > > > > > + items: > > > > > + minimum: 0 > > > > > + maximum: 7 > > > > > + > > > > > + adi,ch-func: > > > > > + description: > > > > > + Channel output type. Use CH_FUNC_VOLTAGE_OUTPUT for voltage > > > > > + output or CH_FUNC_CURRENT_OUTPUT for current output. > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > > + enum: [1, 2] > > > > > > > > Please make this property a string. > > > > > > It's an existing binding. I guess it is generic enough that perhaps we > > > should make it a generic channel property and as part of that we can > > > flip over to a string. > > > > Ah, if it is something already established then it can stay as-is. > > > > > We may need to create a top level channels.yaml to cover both ADC and DAC > > > channels though and reference that from both files. > > > > I mean yeah, that was one thought I had originally about the > > spi-device-address property. I'm surprised there's already not more > > commonality to begin with. > > > > Just how common is some sort of "channel function" property and how > > many devices are bastardising other properties like diff-channel with a > > virtual channel to achieve the same result? > > I don't think it is that common to mix different things that can be > read on the same pin beyond a simple ADC / GPIO that we tend to > handle by just not having the ADC channel specified. Still there > is clearly a non zero number of devices that do. > > I can't immediately recall the virtual channel trick you suggest > being used except when it is routing from a different place > in a SoC which to me is a different input via a mux, rather than > mode of the channel. It may be my lack of understanding of the devices, I just recall there being use made of diff-channels to map to different internal references, which felt like the kind of thing that someone might see a generic "channel mode" property and use to achieve that goal instead. I think the current approach using diff-channels is fine, even if it isn't a real "channel" represented by a pin, I just don't want to see two approaches for the same result (not that this particular binding is doing that at all)
signature.asc
(application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCamo0MQAKCRB4tDGHoIJi 0t1IAQCK5TG2TzJwkgyLhjLEp8WPPLff6z6lHtL06dxokCExrQD+KaaObozNfhLK DX+jr9aUjLtOgtIJtYR2Npjv511u6Qc= =KTuR -----END PGP SIGNATURE-----