linux-kernel - Re: [PATCH v3 3/4] iio: adc: ad7124: add external clock support

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: <a20356ca-05ca-4c99-819b-4b278e799f2a@baylibre.com>
Date: Fri, 29 Aug 2025 12:19:05 -0500
From: David Lechner <dlechner@...libre.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>,
 Jonathan Cameron <jic23@...nel.org>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/4] iio: adc: ad7124: add external clock support

On 8/29/25 10:53 AM, Andy Shevchenko wrote:
> On Fri, Aug 29, 2025 at 12:55 AM David Lechner <dlechner@...libre.com> wrote:
>>
>> Add support for an external clock source to the AD7124 ADC driver.
>>
>> Previously, the driver only supported using the internal clock and had
>> bad devicetree bindings that used a fake clock to essentially select
>> the power mode. This is preserved for backwards compatibility.
>>
>> If the clock is not named "mclk", then we know that the devicetree is
>> using the correct bindings and we can configure the chip to use an
>> external clock source rather than internal.
>>
>> Also drop a redundant comment when configuring the register fields
>> instead of adding more.
> 
> ...
> 
>> +                       if (clk_hz > MEGA) {
> 
> I read your answer, but maybe I missed something?  Can we use (1 *
> HZ_PER_MHZ) here?

I suppose we can. But it doesn't add any additional information.
We already know we are dealing with Hz because of clk_hz and 1
is implicit. So it is just a matter of style preference. Since I
read a lot of code, I tend to prefer the minimal approach - it is
less to read and still has the same meaning.

> 
>> +                               clk_sel = AD7124_ADC_CONTROL_CLK_SEL_EXT_DIV4;
>> +                               st->clk_hz = clk_hz / 4;
>> +                       } else {
>> +                               clk_sel = AD7124_ADC_CONTROL_CLK_SEL_EXT;
>> +                               st->clk_hz = clk_hz;
>> +                       }
> 
>