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

[Jonathan Cameron <jonathan.cameron@huawei.com>]

On Mon, 19 Jan 2026 09:38:09 +0200
Andy Shevchenko <andriy.shevchenko@intel.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@intel.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.

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.

Jonathan