mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexey Dobriyan <adobriyan@gmail.com>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, adobriyan@gmail.com
Subject: [PATCH 4/8] auto: promote DIV64_U64_ROUND_UP macro to function
Date: Thu, 18 May 2023 18:46:45 +0300	[thread overview]
Message-ID: <20230518154648.581643-4-adobriyan@gmail.com> (raw)
In-Reply-To: <20230518154648.581643-1-adobriyan@gmail.com>

so that people don't convert it to "auto".

Second argument is cast to u64:

	u64 _tmp = (d);

so it's safe to make it function argument of type u64.

First argument is used like this:

	(ll) + _tmp - 1

which is

	typeof(ll) + u64 - int

If u64 is "unsigned long long" then everything will be promoted to it,
so making promotion earlier in function argument is OK.

If u64 is "unsigned long" and typeof(ll) is ranked lower than
"unsigned long" then it will be promoted to "unsigned long",
then it is OK to promote to u64 earlier as function argument.

If u64 is "unsigned long" and typeof(ll) is "long long" or
"unsigned long long" then expression will be promoted to typeof(ll)
but then everything will be truncated to "u64" when passed to
div64_u64(). Thus having type wider that "u64" doesn't really matter.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
 include/linux/math64.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/math64.h b/include/linux/math64.h
index 8b9191a2849e..7e0e2625dc35 100644
--- a/include/linux/math64.h
+++ b/include/linux/math64.h
@@ -298,8 +298,10 @@ u64 mul_u64_u64_div_u64(u64 a, u64 mul, u64 div);
  *
  * Return: dividend / divisor rounded up
  */
-#define DIV64_U64_ROUND_UP(ll, d)	\
-	({ u64 _tmp = (d); div64_u64((ll) + _tmp - 1, _tmp); })
+static inline u64 DIV64_U64_ROUND_UP(u64 ll, u64 d)
+{
+	return div64_u64(ll + d - 1, d);
+}
 
 /**
  * DIV64_U64_ROUND_CLOSEST - unsigned 64bit divide with 64bit divisor rounded to nearest integer
-- 
2.40.1


  parent reply	other threads:[~2023-05-18 15:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 15:46 [PATCH 1/8] auto, kbuild: flatten KBUILD_CFLAGS Alexey Dobriyan
2023-05-18 15:46 ` [PATCH 2/8] auto: add "auto" keyword as alias for __auto_type Alexey Dobriyan
2023-05-18 15:46 ` [PATCH 3/8] auto, proc: use "auto" instead of quite chatty macros Alexey Dobriyan
2023-05-18 15:46 ` Alexey Dobriyan [this message]
2023-05-18 15:46 ` [PATCH 5/8] auto: promote DIV64_U64_ROUND_CLOSEST macro to function Alexey Dobriyan
2023-05-18 15:46 ` [PATCH 6/8] auto: promote DIV_U64_ROUND_CLOSEST " Alexey Dobriyan
2023-05-18 15:46 ` [PATCH 7/8] auto: promote DIV_S64_ROUND_CLOSEST " Alexey Dobriyan
2023-05-18 20:37 ` [PATCH 1/8] auto, kbuild: flatten KBUILD_CFLAGS Andrew Morton
2023-05-19 11:15   ` Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230518154648.581643-4-adobriyan@gmail.com \
    --to=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®