linux-kernel - Re: [PATCH v3 4/6] iio: frequency: adf41513: features on frequency change

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] [day] [month] [year] [list]

Message-ID: <aW4vPpE8CRL5yI2u@smile.fi.intel.com>
Date: Mon, 19 Jan 2026 15:18:54 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
	Rodrigo Alencar <455.rodrigo.alencar@...il.com>,
	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 v3 4/6] iio: frequency: adf41513: features on frequency
 change

On Mon, Jan 19, 2026 at 10:41:59AM +0000, Jonathan Cameron wrote:
> On Mon, 19 Jan 2026 09:38:09 +0200
> Andy Shevchenko <andriy.shevchenko@...el.com> wrote:
> > On Fri, Jan 16, 2026 at 05:57:43PM +0000, Jonathan Cameron wrote:
> > > On Mon, 12 Jan 2026 12:54:50 +0200
> > > Andy Shevchenko <andriy.shevchenko@...el.com> wrote:  
> > > > On Mon, Jan 12, 2026 at 09:45:49AM +0000, Rodrigo Alencar wrote:  
> > > > > On 26/01/09 09:07PM, Andy Shevchenko wrote:    
> > > > > > On Thu, Jan 08, 2026 at 12:14:53PM +0000, Rodrigo Alencar via B4 Relay wrote:    

...

> > > > > > > +	bleed_value = div64_u64(st->settings.pfd_frequency_uhz * bleed_value,
> > > > > > > +				1600ULL * HZ_PER_MHZ * MICROHZ_PER_HZ);    
> > > > 
> > > > You multiply Hz * Hz. One of them should be simply SI multiplier.
> > > > To me it sounds like one of
> > > > 
> > > > 				1600ULL * MEGA * MICROHZ_PER_HZ);
> > > > 				1600ULL * HZ_PER_MHZ * MICRO);
> > > > 
> > > > will be the correct one (and I lean towards the first one as you want units
> > > > to match).  
> > > 
> > > I don't really care, but... They are Hz * Hz / Hz * Hz / Hz = HZ
> > > if we assume the first number is in Hz.  The others are all ratios.
> > >  
> > > So original is fine as far as I can tell.  
> > 
> > I don't see it like this. I consider that we should have only one meaningful
> > units as the rest is just a value. What you wrote above has a little sense
> > to me, sorry.
> > 
> 
> I agree, but none of those XHZ PER HZ is mathematically valid way of applying a unit.
> This is because the per means divide so the units cancel out.
> Literally it's  (0.0000001Hz / 1Hz) 
> So using them to assign a unit is meaningless.  All they are doing is hinting
> that we are manipulating values already in some scaling of Hz.

My understanding is that they give a hint about units and used scale (which is
also provided by the unit suffix in the respective variable name in this case).
In some cases the variables do not have suffixes and having a named multiplier
helps that.

> Personally I'm not sure there is value in the unit specific defines given
> this. They kind of hint we are dealing with frequencies, but that's it.


-- 
With Best Regards,
Andy Shevchenko