On 2/24/25 12:33 PM, Matti Vaittinen wrote: > There are ADC ICs which may have some of the AIN pins usable for other > functions. These ICs may have some of the AIN pins wired so that they > should not be used for ADC. > > (Preferred?) way for marking pins which can be used as ADC inputs is to > add corresponding channels@N nodes in the device tree as described in > the ADC binding yaml. I think "preferred?" is the key question here. Currently, it is assumed that basically all IIO bindings have channels implicitly even if the binding doesn't call them out. It just means that there is nothing special about the channel that needs to be documented, but the channel is still there. Similarly, on several drivers we added recently that make use of adc.yaml (adi,ad7380, adi,ad4695) we wrote the bindings with the intention that if a channel was wired in the default configuration, then you would just omit the channel node for that input pin. Therefore, this helper couldn't be used by these drivers since we always have a fixed number of channels used in the driver regardless of if there are explicit channel nodes in the devicetree or not. In my experience, the only time we don't populate all available channels on an ADC, even if not used, is in cases like differential chips where any two inputs can be mixed and matched to form a channel. Some of these, like adi,ad7173-8 would have 100s or 1000s of channels if we tried to include all possible channels. In those cases, we make an exception and use a dynamic number of channels based on the devicetree. But for chips that have less than 20 total possible channels or so we've always provided all possible channels to userspace. It makes writing userspace software for a specific chip easier if we can always assume that chip has the same number of channels. > > Add couple of helper functions which can be used to retrieve the channel > information from the device node. > > Signed-off-by: Matti Vaittinen <mazziesaccount@xxxxxxxxx> >
