On 10/31/23 15:42, Andy Shevchenko wrote:
On Tue, Oct 31, 2023 at 02:07:46PM +0200, Matti Vaittinen wrote:
On 10/31/23 12:38, Andy Shevchenko wrote:
On Tue, Oct 31, 2023 at 09:11:37AM +0200, Matti Vaittinen wrote:
On 10/30/23 12:21, Matti Vaittinen wrote:
On 10/29/23 17:51, Matti Vaittinen wrote:
On 10/28/23 18:20, Jonathan Cameron wrote:
...
tmp = gts->max_scale;
rem = do_div(tmp, total_gain);
if (total_gain > 1 && rem >= total_gain / 2)
tmp += 1ULL;
...which is NIH DIV_ROUND_CLOSEST_ULL()
There is a difference though. The DIV_ROUND_CLOSEST_ULL() does
tmp + total_gain / 2;
before division - which in theory may overflow.
Then you can fix it there for everybody, no?
Now that I know of this macro - Maybe. It's just always scary to touch
things which seem like fundamental building blocks and which may be used
by many. Odds are something breaks, so I tend to be very conservative
when suggesting changes to widely used stuff. Especially when I have no
idea when and why the API has been added - and if the thing I'm trying
to "fix" has been a deliberate choice.
Yours,
-- Matti.
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
