It is quite common practice to make u16, u32 or u64 values from
smaller words. Add simple helpers for that.
Signed-off-by: Michal Wajdeczko <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Jani Nikula <[email protected]>
---
include/linux/make_type.h | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 include/linux/make_type.h
diff --git a/include/linux/make_type.h b/include/linux/make_type.h
new file mode 100644
index 000000000000..60e2e091ea3c
--- /dev/null
+++ b/include/linux/make_type.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_MAKE_TYPE_H
+#define _LINUX_MAKE_TYPE_H
+
+#include <linux/types.h>
+
+/**
+ * make_u16 - make u16 value from two u8 values
+ * @hi__: value representing upper 8 bits
+ * @lo__: value representing lower 8 bits
+ */
+#define make_u16(hi__, lo__) ((u16)(u8)(hi__) << 8 | (u8)(lo__))
+
+/**
+ * make_u32 - make u32 value from two u16 values
+ * @hi__: value representing upper 16 bits
+ * @lo__: value representing lower 16 bits
+ */
+#define make_u32(hi__, lo__) ((u32)(u16)(hi__) << 16 | (u16)(lo__))
+
+/**
+ * make_u64 - make u64 value from two u32 values
+ * @hi__: value representing upper 32 bits
+ * @lo__: value representing lower 32 bits
+ */
+#define make_u64(hi__, lo__) ((u64)(hi__) << 32 | (u32)(lo__))
+
+#endif
--
2.43.0
On Wed, Feb 14, 2024 at 04:54:08PM +0100, Michal Wajdeczko wrote:
> It is quite common practice to make u16, u32 or u64 values from
> smaller words. Add simple helpers for that.
..
> +++ b/include/linux/make_type.h
If we go with this, please make better name so we can combine this with
upper/lower_*_bits() helpers which seems related semantically to this.
Also _type suffix is a bit confusing as we use _types in the headers
that provide just data type(s).
--
With Best Regards,
Andy Shevchenko
On 14.02.2024 17:04, Andy Shevchenko wrote:
> On Wed, Feb 14, 2024 at 04:54:08PM +0100, Michal Wajdeczko wrote:
>> It is quite common practice to make u16, u32 or u64 values from
>> smaller words. Add simple helpers for that.
>
> ...
>
>> +++ b/include/linux/make_type.h
>
> If we go with this, please make better name so we can combine this with
> upper/lower_*_bits() helpers which seems related semantically to this.
>
what about "include/linux/uintops.h" like we have bitops.h ?
On Wed, Feb 14, 2024 at 06:02:01PM +0100, Michal Wajdeczko wrote:
> On 14.02.2024 17:04, Andy Shevchenko wrote:
> > On Wed, Feb 14, 2024 at 04:54:08PM +0100, Michal Wajdeczko wrote:
..
> >> +++ b/include/linux/make_type.h
> >
> > If we go with this, please make better name so we can combine this with
> > upper/lower_*_bits() helpers which seems related semantically to this.
>
> what about "include/linux/uintops.h" like we have bitops.h ?
We have wordpart.h, would it work?
--
With Best Regards,
Andy Shevchenko
> +#define make_u16(hi__, lo__) ((u16)(u8)(hi__) << 8 | (u8)(lo__))
Public Service Announcement
Identifiers representing macro arguments generally don't need to be
undescored. They are local to the macro, they don't leak outside.
End of Public Service Announcement
Firstly, make_u16() doesn't return u16.
Secondly,
#define make_u64(hi__, lo__) ((u64)(hi__) << 32 | (u32)(lo__))
doesn't truncate hi, why?
On Wed, Feb 14, 2024 at 08:20:55PM +0300, Alexey Dobriyan wrote:
..
> Secondly,
>
> #define make_u64(hi__, lo__) ((u64)(hi__) << 32 | (u32)(lo__))
>
> doesn't truncate hi, why?
Because it's not needed (the whole point AFAIU is to override promotion
to a _signed_ type (int) and here it makes no difference)?
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 14, 2024 at 08:39:35PM +0300, Alexey Dobriyan wrote:
> On Wed, Feb 14, 2024 at 07:32:10PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 14, 2024 at 08:20:55PM +0300, Alexey Dobriyan wrote:
..
> > > Secondly,
> > >
> > > #define make_u64(hi__, lo__) ((u64)(hi__) << 32 | (u32)(lo__))
> > >
> > > doesn't truncate hi, why?
> >
> > Because it's not needed (the whole point AFAIU is to override promotion
> > to a _signed_ type (int) and here it makes no difference)?
>
> Well,
>
> make_u64((u64)-1, 0)
>
> will return (u64)-1 unlike
How? It's shifted by 32 bits. Am I missing something?
> BTW, I'm for truncation, but it should be done everywhere.
I'm not against this.
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 14, 2024 at 07:32:10PM +0200, Andy Shevchenko wrote:
> On Wed, Feb 14, 2024 at 08:20:55PM +0300, Alexey Dobriyan wrote:
>
> ...
>
> > Secondly,
> >
> > #define make_u64(hi__, lo__) ((u64)(hi__) << 32 | (u32)(lo__))
> >
> > doesn't truncate hi, why?
>
> Because it's not needed (the whole point AFAIU is to override promotion
> to a _signed_ type (int) and here it makes no difference)?
Well,
make_u64((u64)-1, 0)
will return (u64)-1 unlike
make_u16((u64)-1, 0)
which will return 0xff00.
BTW, I'm for truncation, but it should be done everywhere.
Thirdly, there were no users posted.
On 14.02.2024 18:39, Alexey Dobriyan wrote:
> On Wed, Feb 14, 2024 at 07:32:10PM +0200, Andy Shevchenko wrote:
>> On Wed, Feb 14, 2024 at 08:20:55PM +0300, Alexey Dobriyan wrote:
..
>
> Thirdly, there were no users posted.
for make_u64() there is already one at [1]
and Jani pointed other potential candidates [2]
[1]
https://elixir.bootlin.com/linux/v6.8-rc4/source/drivers/gpu/drm/xe/xe_gt_pagefault.c#L555
[2]
https://lore.kernel.org/intel-xe/[email protected]/T/#md6577722f9226258c8eb99119707e12db4dd3b79
On Wed, Feb 14, 2024 at 06:55:38PM +0100, Michal Wajdeczko wrote:
>
>
> On 14.02.2024 18:39, Alexey Dobriyan wrote:
> > On Wed, Feb 14, 2024 at 07:32:10PM +0200, Andy Shevchenko wrote:
> >> On Wed, Feb 14, 2024 at 08:20:55PM +0300, Alexey Dobriyan wrote:
>
> ...
>
> >
> > Thirdly, there were no users posted.
>
> for make_u64() there is already one at [1]
> [1]
> https://elixir.bootlin.com/linux/v6.8-rc4/source/drivers/gpu/drm/xe/xe_gt_pagefault.c#L555
OK, this one doesn't truncate too.
Honestly wordpath.h _sucks_ as a name.
I'd go with stdint.h, at least this name is known from userspace.