On Sat, May 11, 2024 at 11:11:14PM +0530, Devarsh Thakkar wrote: > On 10/05/24 20:45, Jani Nikula wrote: [...] > > Moreover, I think the naming of round_up() and round_down() should have > > reflected the fact that they operate on powers of 2. It's unfortunate > > that the difference to roundup() and rounddown() is just the underscore! > > That's just a trap. > > > > So let's perhaps not repeat the same with round_closest_up() and > > round_closest_down()? > > Yes the naming is inspired by existing macros i.e. round_up, round_down > (which round up/down to next pow of 2) and DIV_ROUND_CLOSEST (which > round the divided value to closest value) and there are already a lot of > users for these API's : > > linux-next git:(heads/next-20240509) ✗ grep -nr round_up drivers | wc > 730 4261 74775 > > linux-next git:(heads/next-20240509) ✗ grep -nr round_down drivers | wc > 226 1293 22194 > > linux-next git:(heads/next-20240509) ✗ grep -nr DIV_ROUND_CLOSEST > drivers | wc > 1207 7461 111822 Side note, discover `git grep ...`: it's much much faster on Git index, than classic one on a working copy. > so I thought to align with existing naming convention assuming > developers are already familiar with this. > > But if a wider consensus is to go with a newer naming convention then I > am open to it, although a challenge there would be to keep it short. For > e.g. this one is already 3 words, if we go with more explicit > "round_closest_up_pow_2" it looks quite long in my opinion :) . You need properly name the macros. Again, round_up() / roundup() and roundup_pow_of_two() are three _different_ macros, and it's not clear why you can't use one of them in your case. The patch that changes those to a new one are doubtful to begin with. I.e. need a careful review on the arithmetics side of the change including HW capabilities of handling "closest" results. -- With Best Regards, Andy Shevchenko