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
next prev 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®