linux-kernel - Re: [PATCH v3 2/2] iio: adc: Add ti-ads1018 driver

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: <CAHp75Vc3Reh2OzbEzKk7P+wG40Ys+jfsejZdwQZD90sJcv6skQ@mail.gmail.com>
Date: Sun, 30 Nov 2025 18:45:05 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Kurt Borja <kuurtb@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Jonathan Cameron <jic23@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Tobias Sperling <tobias.sperling@...ting.com>, David Lechner <dlechner@...libre.com>, 
	Nuno Sá <nuno.sa@...log.com>, 
	Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v3 2/2] iio: adc: Add ti-ads1018 driver

On Sun, Nov 30, 2025 at 5:31 AM Kurt Borja <kuurtb@...il.com> wrote:
> On Sat Nov 29, 2025 at 9:21 AM -05, Andy Shevchenko wrote:

...

> >> + * @ad1018: Device data
> >> + *
> >> + * Calculates an appropriate delay for a single shot reading, assuming the
> >> + * device's maximum data-rate is used.
> >> + *
> >> + * Context: Expects iio_device_claim_direct() is held.
> >> + *
> >> + * Return: Delay in microseconds.
> >
> > Does 0 have any special meaning?
>
> This function is never 0.

Would be nice to mention this in the Return section.

...

> >> +    /* We subtract 10% data-rate error */
> >> +    hz -= DIV_ROUND_UP(hz, 10);
> >
> > Hmm... For delays I expect to see adding 10% to have a good margin.
>
> hz goes in the denomitor bellow, so less hz is more delay. Makes sense
> because worst case sample rate is less sample rate.

Please, rephrase or amend the comment to point this out. Because at
the first glance it's not obvious that subtract means delay increase.

...

> If no one prefers to do it, I can submit a patch implementing this. Same
> for the lockdep issue above.

If you are motivated to do so, please do!

> > * The macro is crafted to avoid potential overflows on 32-bit machines.
> > * This imposes restrictions to the possible values for @_fsr (less

s/to the/on the/

(in case you stick with my text)

> > * than 274878), and @_res (great or equal to 6 bits).

-- 
With Best Regards,
Andy Shevchenko