From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: Yury Norov <yury.norov@gmail.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
Andi Shyti <andi.shyti@linux.intel.com>,
David Laight <David.Laight@aculab.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v4 3/8] bits: introduce fixed-type genmasks
Date: Wed, 5 Mar 2025 21:45:02 +0200 [thread overview]
Message-ID: <Z8ipvnURG_iejzSX@smile.fi.intel.com> (raw)
In-Reply-To: <8301ecbc-d035-4257-9b04-c6ef9be4ce32@wanadoo.fr>
On Thu, Mar 06, 2025 at 01:48:49AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 00:47, Yury Norov wrote:
> > On Wed, Mar 05, 2025 at 10:00:15PM +0900, Vincent Mailhol via B4 Relay wrote:
...
> > Having, in fact, different implementations of the same macro for kernel
> > and userspace is a source of problems. Can we move GENMASK_TYPE() to uapi,
> > and implement __GENMASK() on top of them? If not, I'd prefer to keep
> > GENMASK and GENMASK_ULL untouched.
>
> This is something which I tried to explain in the cover letter. I am not
> confident to declare GENMASK_TYPE() in the uapi and expose it to the
> userland. If we do so, any future change in the parameters would be a
> user breaking change. __GENMASK_U128() looks already too much to me for
> the uapi, I am not keen to bloat it even more with GENMASK_TYPE().
>
> This plus the fact that if we use GENMASK_TYPE() to generate the asm
> variant, then we can not rely on sizeof() in the definition which makes
> everything over complicated.
I am with you here. The less we done in uAPI the better.
uAPI is something carved in stone, once done it's impossible to change.
> I acknowledge that not having a common denominator is not best, but I
> see this as an acceptable tradeoff.
...
> >> +#define GENMASK_U8(h, l) ((unsigned int)GENMASK_t(u8, h, l))
> >> +#define GENMASK_U16(h, l) ((unsigned int)GENMASK_t(u16, h, l))
> >
> > Typecast to the type that user provides explicitly? And maybe do
> > in GENMASK_TYPE()
>
> I have a slight preference for the cast to unsigned int for the reason
> explained above. But that is not a deal breaker. If you believe that the
> u8/u16 casts are better, let me know, I will be happy to change it :)
At least can you provide an existing use case (or use cases) that need
this castings? Also still a big question what will happen with it on asm.
Can it cope with 0x000000f0 passed as imm8, for example?
> >> +#define GENMASK_U32(h, l) GENMASK_t(u32, h, l)
> >> +#define GENMASK_U64(h, l) GENMASK_t(u64, h, l)
...
> > But GENMASK_U128() becomes a special case now.
> > The 128-bit GENMASK is unsued, but it's exported in uapi. Is there any
> > simple way to end up with a common implementation for all fixed-type
> > GENMASKs?
>
> What bothers me is that the 128 bit types are not something available on
> all architectures, c.f. the CONFIG_ARCH_SUPPORTS_INT128. So, I would
> need a U128() equivalent to the ULL() but which does not break on
> architectures which do not support 128 bits integers.
>
> This is where I am stuck. If someone can guide me on how to write a
> robust U128() macro, then I think the common implementation could be
> feasible.
I think we may leave that U128 stuff alone for now.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-03-05 19:45 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 13:00 [PATCH v4 0/8] bits: Fixed-type GENMASK()/BIT() Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 1/8] bits: fix typo 'unsigned __init128' -> 'unsigned __int128' Vincent Mailhol via B4 Relay
2025-03-05 14:30 ` Yury Norov
2025-03-05 14:36 ` Andy Shevchenko
2025-03-05 14:38 ` Yury Norov
2025-03-05 16:09 ` Vincent Mailhol
2025-03-05 14:34 ` Andy Shevchenko
2025-03-05 13:00 ` [PATCH v4 2/8] bits: split the definition of the asm and non-asm GENMASK() Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 3/8] bits: introduce fixed-type genmasks Vincent Mailhol via B4 Relay
2025-03-05 14:30 ` Andy Shevchenko
2025-03-05 14:38 ` Vincent Mailhol
2025-03-05 14:41 ` Andy Shevchenko
2025-03-06 14:48 ` Lucas De Marchi
2025-03-05 15:22 ` Yury Norov
2025-03-05 15:50 ` Andy Shevchenko
2025-03-19 1:46 ` Yury Norov
2025-03-19 3:34 ` Anshuman Khandual
2025-03-19 4:13 ` Anshuman Khandual
2025-03-21 17:05 ` Yury Norov
2025-03-22 11:46 ` Vincent Mailhol
2025-03-05 15:47 ` Yury Norov
2025-03-05 15:52 ` Jani Nikula
2025-03-05 16:48 ` Vincent Mailhol
2025-03-05 19:45 ` Andy Shevchenko [this message]
2025-03-06 9:22 ` Vincent Mailhol
2025-03-06 9:28 ` Andy Shevchenko
2025-03-05 13:00 ` [PATCH v4 4/8] bits: introduce fixed-type BIT Vincent Mailhol via B4 Relay
2025-03-05 14:33 ` Andy Shevchenko
2025-03-05 14:48 ` Vincent Mailhol
2025-03-05 15:48 ` Andy Shevchenko
2025-03-05 17:17 ` Vincent Mailhol
2025-03-05 19:56 ` Andy Shevchenko
2025-03-05 21:50 ` David Laight
2025-03-06 8:12 ` Jani Nikula
2025-03-06 9:12 ` Andy Shevchenko
2025-03-06 9:38 ` Vincent Mailhol
2025-03-05 21:13 ` David Laight
2025-03-05 13:00 ` [PATCH v4 5/8] drm/i915: Convert REG_GENMASK* to fixed-width GENMASK_* Vincent Mailhol via B4 Relay
2025-03-05 14:37 ` Andy Shevchenko
2025-03-05 13:00 ` [PATCH v4 6/8] test_bits: add tests for __GENMASK() and __GENMASK_ULL() Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 7/8] test_bits: add tests for fixed-type genmasks Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 8/8] test_bits: add tests for fixed-type BIT Vincent Mailhol via B4 Relay
2025-03-05 15:59 ` [PATCH v4 0/8] bits: Fixed-type GENMASK()/BIT() Jani Nikula
2025-03-07 16:07 ` ✗ Fi.CI.CHECKPATCH: warning for bits: Fixed-type GENMASK()/BIT() (rev2) Patchwork
2025-03-07 16:07 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-03-07 16:32 ` ✓ i915.CI.BAT: success " Patchwork
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=Z8ipvnURG_iejzSX@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=David.Laight@aculab.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@linux.intel.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lucas.demarchi@intel.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
--cc=yury.norov@gmail.com \
/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