[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z3CLypNNqqlSsabo@surfacebook.localdomain>
Date: Sun, 29 Dec 2024 01:37:46 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Prabhakar <prabhakar.csengg@...il.com>
Cc: Chris Brandt <chris.brandt@...esas.com>,
Andi Shyti <andi.shyti@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>,
Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v3 7/8] i2c: riic: Use predefined macro and simplify
clock tick calculation
Fri, Dec 27, 2024 at 11:51:53AM +0000, Prabhakar kirjoitti:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
>
> Replace the hardcoded `1000000000` with the predefined `NANO` macro for
> clarity. Simplify the code by introducing a `ns_per_tick` variable to
> store `NANO / rate`, reducing redundancy and improving readability.
...
> - brl -= t->scl_fall_ns / (1000000000 / rate);
> - brh -= t->scl_rise_ns / (1000000000 / rate);
> + ns_per_tick = NANO / rate;
So, why NANO and not NSEC_PER_SEC?
> + brl -= t->scl_fall_ns / ns_per_tick;
> + brh -= t->scl_rise_ns / ns_per_tick;
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists