linux-kernel - Re: [PATCH v4 3/7] iio: frequency: adf41513: driver implementation

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: <fv4kgfxqgzrw2yaq3vv5g5douyer4ocqk5nloi5iwxc2aueby2@vswsu4jxz6xh>
Date: Mon, 19 Jan 2026 13:10:09 +0000
From: Rodrigo Alencar <455.rodrigo.alencar@...il.com>
To: Jonathan Cameron <jic23@...nel.org>, 
	Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@...nel.org>
Cc: rodrigo.alencar@...log.com, linux-kernel@...r.kernel.org, 
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org, linux-doc@...r.kernel.org, 
	David Lechner <dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>, 
	Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v4 3/7] iio: frequency: adf41513: driver implementation

On 26/01/16 07:29PM, Jonathan Cameron wrote:
> On Fri, 16 Jan 2026 14:32:22 +0000
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@...nel.org> wrote:
>

...
 
> > +
> > +	cp_resistance = ADF41513_DEFAULT_R_SET;
> > +	device_property_read_u32(dev, "adi,charge-pump-resistor-ohms", &cp_resistance);
> > +	if (cp_resistance < ADF41513_MIN_R_SET || cp_resistance > ADF41513_MAX_R_SET)
> > +		return dev_err_probe(dev, -ERANGE, "R_SET %u Ohms out of range\n", cp_resistance);
> > +
> > +	st->data.charge_pump_voltage_mv = ADF41513_DEFAULT_CP_VOLTAGE_mV;
> 
> This leaves some odd corner cases.
> If DT defines cp_resistance but not cp_current then we ignore the cp_resitance.
> If you want to insist it is either both or nothing, that needs enforcing in the dt-binding.
> I think I slightly prefer this option..
> 
> Alternative is define a default current such that the maths works to give the DEFAULT_CP_VOLTAGE_mV
> if both properties use defaults and use that here + document in the dt-binding as the default
> for this property.   That may mean if only one property is set we reject the pair and fail
> to probe.  You have comment about valid combinations in the dt-binding so that's fine.

Understood. I suppose the following in the dt-binding would be enough:

dependencies:
  adi,charge-pump-resistor-ohms: ["adi,charge-pump-current-microamp"]

as current can be defined alone (it would use the default resistor value).

Kind regards,

Rodrigo Alencar