linux-kernel - Re: [PATCH v1 1/3] dt-bindings: iio: adc: Add AD4134

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: <aRZUCtYzZCY9IQ5U@debian-BULLSEYE-live-builder-AMD64>
Date: Thu, 13 Nov 2025 18:56:26 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Conor Dooley <conor@...nel.org>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, jic23@...nel.org, nuno.sa@...log.com,
	dlechner@...libre.com, andy@...nel.org,
	Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, corbet@....net, cosmin.tanislav@...log.com
Subject: Re: [PATCH v1 1/3] dt-bindings: iio: adc: Add AD4134

On 11/10, Conor Dooley wrote:
> On Mon, Nov 10, 2025 at 09:45:18AM -0300, Marcelo Schmitt wrote:
> 
> > +  adi,control-mode:
> > +    $ref: /schemas/types.yaml#/definitions/string
> > +    description:
> > +      Describes whether the device is wired to an SPI interface or not. The
> 
> Can you explain how you don't automagically know this from what bus
> you're on?

No. I mean, I should have realized we can imply SPI control mode from the bus node.
That's one fewer dt property :)

> 
> > +      PIN/SPI pin on the device must be set accordingly, i.e., PIN/SPI must be
> > +      set to logic high for SPI Control Mode, low for Pin Control Mode. When
> > +      absent, implies the SPI interface configuration.
> > +    enum: [ spi-control-mode, pin-control-mode ]
> > +    default: spi-control-mode
> > +
> > +  adi,asrc-mode:
> > +    $ref: /schemas/types.yaml#/definitions/string
> > +    description:
> > +      Asynchronous Sample Rate Converter (ASRC) operation mode control input.
> > +      Describes whether the MODE pin is set to a high level (for master mode
> > +      operation) or to a low level (for slave mode operation).
> 
> I don't really get this one. If this is an input to the device that
> controls behaviour (master v slave) why is an option needed too? Clearly
> this is not a gpio but it seems like it could be one, in which case you'd
> need some sort of asrc-gpios property. Is it not possible to read the
> value of this setting out of the device's registers (maybe it's not when
> there's no spi interface connected?)?
> It's not used in your driver, so I can't look there easily to see what's
> going on.

The MODE pin defines whether the ODR pin will behave as input or output.
Currently, there are no plans for supporting ODR as output but, software would
need to do different things to control the output data rate in that case.
Though, the MODE pin state can indeed be read from a register. Same for DCLK pin
I/O direction and DCLK mode. They are also readable from device's registers.
So, that would be 4 fewer dt props total. Well, yeah, if the device is not
connected to an SPI host (pin control mode) then we can't read those. There are
no plans for supporting this device outside an SPI bus, but we would then
need these properties (or a separate binding). Not sure what to do here. 
Do I drop or keep adi,asrc-mode?

The MODE pin is sampled only when the AD4134 is powered on so I don't think we
would benefit from having a GPIO connected to that (if we keep a property to
describe the MODE pin state).

> 
> > +    enum: [ high, low ]
> > +    default: low

Thanks,
Marcelo