From: Yury Norov <yury.norov@gmail.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
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>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v4 3/8] bits: introduce fixed-type genmasks
Date: Fri, 21 Mar 2025 13:05:18 -0400 [thread overview]
Message-ID: <Z92cThxAyXu9JJdk@thinkpad> (raw)
In-Reply-To: <1aba17f1-0cd2-429c-8338-28387ec16314@arm.com>
On Wed, Mar 19, 2025 at 09:43:06AM +0530, Anshuman Khandual wrote:
>
>
> On 3/19/25 09:04, Anshuman Khandual wrote:
> > On 3/19/25 07:16, Yury Norov wrote:
> >> + Catalin Marinas, ARM maillist
> >>
> >> Hi Catalin and everyone,
> >
> > Hello Yury,
> >
> >>
> >> Anshuman Khandual asked me to merge GENMASK_U128() saying it's
> >> important for ARM to stabilize API. While it's a dead code, I
> >> accepted his patch as he promised to add users shortly.
> >>
> >> Now it's more than half a year since that. There's no users,
> >> and no feedback from Anshuman.
> >
> > My apologies to have missed your email earlier. Please find response
> > for the earlier email below as well.
> >
> >>
> >> Can you please tell if you still need the macro? I don't want to
> >> undercut your development, but if you don't need 128-bit genmasks
> >> there's no reason to have a dead code in the uapi.
> >
> > The code base specifically using GENMASK_U128() has not been posted
> > upstream (probably in next couple of months or so) till now, except
> > the following patch which has been not been merged and still under
> > review and development.
> >
> > https://lore.kernel.org/lkml/20240801054436.612024-1-anshuman.khandual@arm.com/
> >
> >>
> >> Thanks,
> >> Yury
> >>
> >> On Wed, Mar 05, 2025 at 10:22:47AM -0500, Yury Norov wrote:
> >>> + Anshuman Khandual <anshuman.khandual@arm.com>
> >>>
> >>> Anshuman,
> >>>
> >>> I merged your GENMASK_U128() because you said it's important for your
> >>> projects, and that it will get used in the kernel soon.
> >>>
> >>> Now it's in the kernel for more than 6 month, but no users were added.
> >>> Can you clarify if you still need it, and if so why it's not used?
> >
> > We would need it but although the code using GENMASK_U128() has not been
> > posted upstream.
> >
> >>>
> >>> As you see, people add another fixed-types GENMASK() macros, and their
> >>> implementation differ from GENMASK_U128().
> >
> > I will take a look. Is GENMASK_U128() being problematic for the this new
> > scheme ?
> >
> >>>
> >>> My second concern is that __GENMASK_U128() is declared in uapi, while
> >>> the general understanding for other fixed-type genmasks is that they
> >>> are not exported to users. Do you need this macro to be exported to
> >>> userspace? Can you show how and where it is used there?
> >
> > No, not atleast right now.
Ok, thanks.
> > These were moved into uapi subsequently via the following commit.
> >
> > 21a3a3d015aee ("tools headers: Synchronize {uapi/}linux/bits.h with the kernel sources")
> >
> > But in general GENMASK_U128() is needed for generating 128 bit page table
> > entries, related flags and masks whether in kernel or in user space for
> > writing kernel test cases etc.
>
> In the commit 947697c6f0f7 ("uapi: Define GENMASK_U128"), GENMASK_U128() gets defined
> using __GENMASK_U128() which in turn calls __BIT128() - both of which are defined in
> UAPI headers inside (include/uapi/linux/).
>
> Just wondering - are you suggesting to move these helpers from include/uapi/linux/ to
> include/linux/bits.h instead ?
Vincent is working on fixed-width GENMASK_Uxx() based on GENMASK_TYPE().
https://lore.kernel.org/lkml/20250308-fixed-type-genmasks-v6-0-f59315e73c29@wanadoo.fr/T/
The series adds a general GENMASK_TYPE() in the linux/bits.h. I'd like
all fixed-widh genmasks to be based on it. The implementation doesn't
allow to move GENMASK_TYPE() the to uapi easily.
There was a discussion regarding that, and for now the general understanding
is that userspace doesn't need GENMASK_Uxx().
Are your proposed tests based on the in-kernel tools/ ? If so, linux/bits.h
will be available for you.
Vincent,
Can you please experiment with moving GENMASK_U128() to linux/bits.h
and switching it to GENMASK_TYPE()-based implementation?
If it works, we can do it after merging of GENMASK_TYPE() and
ancestors.
Thanks,
Yury
next prev parent reply other threads:[~2025-03-21 17:05 UTC|newest]
Thread overview: 56+ 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
2025-03-05 13:00 ` Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 1/8] bits: fix typo 'unsigned __init128' -> 'unsigned __int128' Vincent Mailhol
2025-03-05 13:00 ` 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
2025-03-05 13:00 ` Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 3/8] bits: introduce fixed-type genmasks Vincent Mailhol
2025-03-05 13:00 ` 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 [this message]
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
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
2025-03-05 13:00 ` 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
2025-03-05 13:00 ` 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
2025-03-05 13:00 ` Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 7/8] test_bits: add tests for fixed-type genmasks Vincent Mailhol
2025-03-05 13:00 ` Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 8/8] test_bits: add tests for fixed-type BIT Vincent Mailhol
2025-03-05 13:00 ` 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
-- strict thread matches above, loose matches on Subject: below --
2025-03-18 23:18 [PATCH v4 3/8] bits: introduce fixed-type genmasks kernel test robot
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=Z92cThxAyXu9JJdk@thinkpad \
--to=yury.norov@gmail.com \
--cc=David.Laight@aculab.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.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-arm-kernel@lists.infradead.org \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.