On Wed, Nov 01, 2023 at 08:16:32AM +0200, Matti Vaittinen wrote: > 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. Welcome to the club of the div overflow in macros discussion: https://lore.kernel.org/linux-clk/20231024161931.78567-1-sebastian.reichel@xxxxxxxxxxxxx/T/#t -- With Best Regards, Andy Shevchenko
