On Thu, Apr 10, 2025 at 02:56:41AM +0800, Kuan-Wei Chiu wrote:
> On Wed, Apr 09, 2025 at 02:41:03PM -0400, Yury Norov wrote:
> > On Thu, Apr 10, 2025 at 02:23:09AM +0800, Kuan-Wei Chiu wrote:
> > > On Wed, Apr 09, 2025 at 01:03:42PM -0400, Yury Norov wrote:
> > > >
On Thu, Apr 10, 2025 at 02:23:09AM +0800, Kuan-Wei Chiu wrote:
> On Wed, Apr 09, 2025 at 01:03:42PM -0400, Yury Norov wrote:
> > On Wed, Apr 09, 2025 at 11:43:45PM +0800, Kuan-Wei Chiu wrote:
> > > Refactor parity calculations to use the standard parity_odd() helper.
> >
On Thu, Apr 10, 2025 at 02:15:30AM +0800, Kuan-Wei Chiu wrote:
> On Wed, Apr 09, 2025 at 12:54:35PM -0400, Yury Norov wrote:
> > On Wed, Apr 09, 2025 at 11:43:43PM +0800, Kuan-Wei Chiu wrote:
> > > Several parts of the kernel contain open-coded and redundant
> > >
e
> c &= 0xff;
>
> - parity = parity ^ (hweight8(c) & 1);
> + parity = parity ^ parity_odd(c);
This can be simplified for more unless I misunderstand something...
From: Yury Norov
Date: Wed Apr 9 13:22:04 2025 -0400
serial: max3100: Replace op
On Wed, Apr 09, 2025 at 11:43:45PM +0800, Kuan-Wei Chiu wrote:
> Refactor parity calculations to use the standard parity_odd() helper.
> This change eliminates redundant implementations.
>
> Co-developed-by: Yu-Chun Lin
> Signed-off-by: Yu-Chun Lin
> Signed-off-by: Kuan-Wei Chiu
> ---
> driver
On Wed, Apr 09, 2025 at 11:43:43PM +0800, Kuan-Wei Chiu wrote:
> Several parts of the kernel contain open-coded and redundant
> implementations of parity calculation. This patch series introduces
> a unified helper, parity_odd(), to simplify and standardize these
> cases.
>
> The first patch renam
On Wed, Apr 09, 2025 at 11:43:44PM +0800, Kuan-Wei Chiu wrote:
> Redesign the parity8() helper as parity_odd(), changing its input type
> from u8 to u64 to support broader use cases and its return type from
> int to bool to clearly reflect the function's binary output. The
> function now returns tr
+ Anshuman Khandual, Catalin Marinas, linux-arm-ker...@lists.infradead.org
This series moves GENMASK_U128 out of uapi. ARM is the only proposed
user. Add ARM people for visibility.
Thanks,
Yury
On Sat, Mar 22, 2025 at 07:39:35PM +0900, Vincent Mailhol via B4 Relay wrote:
> This is a subset of be
On Wed, Mar 19, 2025 at 02:39:03PM +0900, Vincent Mailhol wrote:
> On 19/03/2025 at 01:45, Yury Norov wrote:
> > On Sat, Mar 08, 2025 at 01:48:49AM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> From: Yury Norov
>
> (...)
>
> >> +#define GENMA
On Thu, Apr 03, 2025 at 10:39:03PM +0800, Kuan-Wei Chiu wrote:
> On Tue, Mar 25, 2025 at 12:43:25PM -0700, H. Peter Anvin wrote:
> > On 3/23/25 08:16, Kuan-Wei Chiu wrote:
> > >
> > > Interface 3: Multiple Functions
> > > Description: bool parity_odd8/16/32/64()
> > > Pros: No need for explicit ca
On Wed, Mar 26, 2025 at 12:59:55AM +0900, Vincent Mailhol via B4 Relay wrote:
> Introduce some fixed width variant of the GENMASK() and the BIT()
> macros in bits.h. For example:
>
> GENMASK_U16(16, 0)
>
> will raise a build bug.
>
> This series is a continuation of:
>
>
> https://lore.ker
On Wed, Mar 26, 2025 at 01:13:28AM +0900, Vincent Mailhol wrote:
> On 26/03/2025 at 00:23, Yury Norov wrote:
> > On Tue, Mar 25, 2025 at 01:23:22AM +0900, Vincent Mailhol wrote:
>
> (...)
>
> > This series doesn't apply on 6.15-rc1 because test_bits.c has moved to
On Tue, Mar 25, 2025 at 01:23:22AM +0900, Vincent Mailhol wrote:
> On 24/03/2025 at 23:28, Yury Norov wrote:
> > On Sat, Mar 22, 2025 at 06:23:11PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> Introduce some fixed width variant of the GENMASK() and the BIT()
>
ed, Mar 12, 2025 at 11:51:12AM -0400, Yury Norov wrote:
> >> > > On Tue, Mar 11, 2025 at 03:24:14PM -0700, H. Peter Anvin wrote:
> >> > > > On March 11, 2025 3:01:30 PM PDT, Yury Norov
> >> > > > wrote:
> >> > > > >On Sun, M
On Sat, Mar 22, 2025 at 06:23:11PM +0900, Vincent Mailhol via B4 Relay wrote:
> Introduce some fixed width variant of the GENMASK() and the BIT()
> macros in bits.h. Note that the main goal is not to get the correct
> type, but rather to enforce more checks at compile time. For example:
You say th
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,
> >
> > He
On Wed, Mar 19, 2025 at 01:37:32PM +0900, Vincent Mailhol wrote:
> On 19/03/2025 at 07:32, Jani Nikula wrote:
> > On Tue, 18 Mar 2025, Yury Norov wrote:
> >> On Sat, Mar 08, 2025 at 01:48:51AM +0900, Vincent Mailhol via B4 Relay
> >> wrote:
> >>> From
hat. There's no users,
and no feedback from Anshuman.
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.
Thanks,
Yury
On Wed, Mar 05, 2025 at
On Sat, Mar 08, 2025 at 01:48:51AM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Lucas De Marchi
>
> Now that include/linux/bits.h implements fixed-width GENMASK_U*(), use
> them to implement the i915/xe specific macros. Converting each driver
> to use the generic macros are left for later,
On Sat, Mar 08, 2025 at 01:48:49AM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Yury Norov
>
> Add GENMASK_TYPE() which generalizes __GENMASK() to support different
> types, and implement fixed-types versions of GENMASK() based on it.
> The fixed-type version allows more s
On Sat, Mar 08, 2025 at 06:10:25PM +0900, Vincent Mailhol wrote:
> On 08/03/2025 at 02:42, Andy Shevchenko wrote:
> > On Sat, Mar 08, 2025 at 01:48:48AM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> From: Vincent Mailhol
> >>
> >> In an upcoming change, GENMASK() and its friends will indire
On Fri, Mar 07, 2025 at 11:33:40AM -0800, H. Peter Anvin wrote:
> On March 7, 2025 11:30:08 AM PST, Yury Norov wrote:
[...]
> >> Instead of "bool" think of it as "bit" and it makes more sense
> >
> >So, to help people thinking that
On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
> wrote:
[...]
> >This is really a question of whether you expect odd or even parity as
> >the "true" value. I think that would depend on context, and we may not
> >reach a good cons
On Tue, Mar 11, 2025 at 03:24:14PM -0700, H. Peter Anvin wrote:
> On March 11, 2025 3:01:30 PM PDT, Yury Norov wrote:
> >On Sun, Mar 09, 2025 at 11:48:26PM +0800, Kuan-Wei Chiu wrote:
> >> On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
> >> > On
On Fri, Mar 07, 2025 at 04:14:34AM -0800, H. Peter Anvin wrote:
> On March 7, 2025 4:13:26 AM PST, Ingo Molnar wrote:
> >
> >* Jiri Slaby wrote:
> >
> >> On 07. 03. 25, 12:38, Ingo Molnar wrote:
> >> >
> >> > * Jiri Slaby wrote:
> >> >
> >> > > On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:
> >> >
On Sun, Mar 09, 2025 at 11:48:26PM +0800, Kuan-Wei Chiu wrote:
> On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
> > On March 7, 2025 11:53:10 AM PST, David Laight
> > wrote:
> > >On Fri, 07 Mar 2025 11:30:35 -0800
> > >"H. Peter Anvin" wrote:
> > >
> > >> On March 7, 2025 10:49:
On Fri, Mar 07, 2025 at 07:43:57PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 07, 2025 at 12:18:02PM -0500, Yury Norov wrote:
> > No rush, please allow your reviewers a week or two before submitting
> > a new iteration unless you want to disregard the previous version for
>
lid params.
>
> - Link to v2:
> https://lore.kernel.org/intel-xe/20240124050205.3646390-1-lucas.demar...@intel.com
>
> Link to v1:
> https://lore.kernel.org/intel-xe/20230509051403.2748545-1-lucas.demar...@intel.com
>
> ---
> Lucas De Marchi
On Fri, Mar 07, 2025 at 07:57:48AM +0100, Jiri Slaby wrote:
> On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:
> > Several parts of the kernel contain redundant implementations of parity
> > calculations for 16/32/64-bit values. Introduces generic
> > parity16/32/64() helpers in bitops.h, providing a sta
On Wed, Mar 05, 2025 at 10:00:15PM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Yury Norov
>
> Add __GENMASK_t() which generalizes __GENMASK() to support different
> types, and implement fixed-types versions of GENMASK() based on it.
> The fixed-type version allows more s
o you need this macro to be exported to
userspace? Can you show how and where it is used there?
Thanks,
Yury
On Wed, Mar 05, 2025 at 10:00:15PM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Yury Norov
>
> Add __GENMASK_t() which generalizes __GENMASK() to support different
>
On Wed, Mar 05, 2025 at 04:36:12PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 05, 2025 at 09:30:20AM -0500, Yury Norov wrote:
> > On Wed, Mar 05, 2025 at 10:00:13PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> > > From: Vincent Mailhol
> > >
> &
Hi Vincent!
On Wed, Mar 05, 2025 at 10:00:13PM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Vincent Mailhol
>
> "int" was misspelled as "init" in GENMASK_U128() comments. Fix the typo.
>
> Signed-off-by: Vincent Mailhol
Thanks for respinning the series. I'll take this fix in bitmap-for-
On Mon, Mar 03, 2025 at 10:47:20AM +0800, Kuan-Wei Chiu wrote:
> > > #define parity(val) \
> > > ({\
> > > __auto_type __v = (val);\
> > > bool __ret;
On Sun, Mar 02, 2025 at 07:09:54PM +, David Laight wrote:
> > #define parity(val) \
> > ({ \
> > __auto_type __v = (val);\
> > bool __ret; \
> >
On Mon, Mar 03, 2025 at 01:29:19AM +0800, Kuan-Wei Chiu wrote:
> Hi Yury,
>
> On Sun, Mar 02, 2025 at 11:02:12AM -0500, Yury Norov wrote:
> > On Sun, Mar 02, 2025 at 04:20:02PM +0800, Kuan-Wei Chiu wrote:
> > > Hi Yury,
> > >
> > > On Sat, Mar 01,
On Sun, Mar 02, 2025 at 04:20:02PM +0800, Kuan-Wei Chiu wrote:
> Hi Yury,
>
> On Sat, Mar 01, 2025 at 10:10:20PM -0500, Yury Norov wrote:
> > On Sat, Mar 01, 2025 at 10:23:52PM +0800, Kuan-Wei Chiu wrote:
> > > Add generic C implementations of __paritysi2(), __paritydi2(
On Thu, Feb 27, 2025 at 09:57:41PM +, David Laight wrote:
> > It's still unclear to me that this parity thing is used in hot paths.
> > If that holds, it's unclear that your hand-made version is better than
> > what's generated by GCC.
>
> I wasn't seriously considering doing that optimisation
On Sat, Mar 01, 2025 at 10:23:52PM +0800, Kuan-Wei Chiu wrote:
> Add generic C implementations of __paritysi2(), __paritydi2(), and
> __parityti2() as fallback functions in lib/parity.c. These functions
> compute the parity of a given integer using a bitwise approach and are
> marked with __weak, a
On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
> On Mon, 24 Feb 2025 14:27:03 -0500
> Yury Norov wrote:
>
> > +#define parity(val)\
> > +({ \
&
On Thu, Feb 27, 2025 at 07:38:58AM +0100, Jiri Slaby wrote:
> On 26. 02. 25, 19:33, Yury Norov wrote:
> > > Not in cases where macros are inevitable. I mean, do we need parityXX()
> > > for
> > > XX in (8, 16, 32, 64) at all? Isn't the parity() above enough
On Wed, Feb 26, 2025 at 08:14:14AM +0100, Jiri Slaby wrote:
> On 25. 02. 25, 14:29, Kuan-Wei Chiu wrote:
> > > +#define parity(val) \
> > > +({ \
> > > + u64 __v = (val);\
> >
On Mon, Feb 24, 2025 at 02:21:13PM -0800, H. Peter Anvin wrote:
> On February 24, 2025 2:17:29 PM PST, Yury Norov wrote:
> >On Mon, Feb 24, 2025 at 01:55:28PM -0800, H. Peter Anvin wrote:
> >> On 2/24/25 07:24, Uros Bizjak wrote:
> >> >
> >> >
>
On Mon, Feb 24, 2025 at 01:55:28PM -0800, H. Peter Anvin wrote:
> On 2/24/25 07:24, Uros Bizjak wrote:
> >
> >
> > On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
> > > Refactor parity calculations to use the standard parity8() helper. This
> > > change eliminates redundant implementations and improves
4;
> + return (0x6996 >> (val & 0xf)) & 1;
It's better to avoid duplicating the same logic again and again.
> +}
> +
So maybe make it a macro?
>From f17a28ae3429f49825d65ebc0f7717c6a191a3e2 Mon Sep 17 00:00:00 2001
From: Yury Norov
Date: Mon, 24 Feb 2025 14
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index
> > a2a56a50dd85227a4fdc62236a2710ca37c5ba52..30ce06df4153cfdc0fad9bc7bffab9097f8b0450
> > 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -316,6 +316,47 @@ static inline void *offse
On Thu, Feb 22, 2024 at 05:04:10PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 22, 2024 at 06:49:59AM -0800, Yury Norov wrote:
> > On Wed, Feb 21, 2024 at 03:59:06PM -0600, Lucas De Marchi wrote:
>
> ...
>
> > +#define __GENMASK(t, h, l) \
> > + ((~0 - (1 <&l
On Mon, Feb 19, 2024 at 11:13:57PM -0600, Lucas De Marchi wrote:
> On Fri, Feb 09, 2024 at 08:53:25AM -0800, Yury Norov wrote:
> > On Wed, Feb 07, 2024 at 11:45:20PM -0800, Lucas De Marchi wrote:
> > > Implement fixed-type BIT() to help drivers add stricter checks, like was
>
; > > -#define GENMASK_ULL(h, l) \
> > > > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l))
> >
> > Ditto.
>
> problem here seems actually because of the cast to the final type. My
> previous impl was avoiding that, but was too verbose compare
On Wed, Feb 07, 2024 at 11:45:20PM -0800, Lucas De Marchi wrote:
> Implement fixed-type BIT() to help drivers add stricter checks, like was
> done for GENMASK.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Jani Nikula
So I get v1 from Jan.23 in my mailbox, and this one is v3. Did I miss
a v2?
On Tue, Jan 23, 2024 at 09:02:04PM -0800, Lucas De Marchi wrote:
> Implement fixed-type BIT() to help drivers add stricter checks, like was
> done for GENMASK.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Yury Norov
> ---
> include/linux/bits.h | 9 +
&g
On Mon, Jan 29, 2024 at 08:49:35AM -0600, Lucas De Marchi wrote:
> On Wed, Jan 24, 2024 at 07:27:58AM -0800, Yury Norov wrote:
> > On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
> > > On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
> > > &
On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
> On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
> > On Tue, 23 Jan 2024, Lucas De Marchi wrote:
> > > From: Yury Norov
> > >
> > > Generalize __GENMASK() to support different ty
On Thu, Jan 18, 2024 at 05:25:00PM -0600, Lucas De Marchi wrote:
> SA2PR11MB4874
> X-OriginatorOrg: intel.com
> Status: RO
> Content-Length: 6257
> Lines: 150
>
> On Thu, Jan 18, 2024 at 01:48:43PM -0800, Yury Norov wrote:
> > On Thu, Jan 18, 2024 at 02:42:12PM -
On Thu, Jan 18, 2024 at 02:42:12PM -0600, Lucas De Marchi wrote:
> Hi,
>
> Reviving this thread as now with xe driver merged we have 2 users for
> a fixed-width BIT/GENMASK.
Can you point where and why?
> On Wed, Jun 21, 2023 at 07:20:59PM -0700, Yury Norov wrote:
&g
+ Rasmus Villemoes
> > -#define __GENMASK(h, l) \
> > - (((~UL(0)) - (UL(1) << (l)) + 1) & \
> > -(~UL(0) >> (BITS_PER_LONG - 1 - (h
> > -#define GENMASK(h, l) \
> > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> > +#define __GENMASK(t, h, l) \
> > + (GENMASK_INPUT_CHECK(h, l) +
se in commit message mention
the exact patch(es) that added a bug related to GENMASK() misuse? It
would be easier to advocate the purpose of new API with that in mind.
Regarding implementation - we should avoid copy-pasting in cases
like this. Below is the patch that I boot-tested for x86_64 and
comp
ome treewide-cleanup
> experience might share some wisdom about what the best timing usually
> winds up being, I'm all ears.
>
> Please take a look! The number of lines touched is quite small, so this
> should be reviewable, and as much as is possible has been pushed into
>
The smu_v1X_0_set_allowed_mask() uses bitmap_copy() to convert
bitmap to 32-bit array. This may be wrong due to endianness issues.
Fix it by switching to bitmap_{from,to}_arr32.
Signed-off-by: Yury Norov
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +-
drivers/gpu/drm/amd/pm/swsmu
-by: Yury Norov
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index cfc21042499d..7299ed9937dd 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b
s all bits unconditionally.
Signed-off-by: Yury Norov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
index d7fa2c49e741..56a3063545ec 100644
On Tue, Jan 25, 2022 at 1:28 AM Tvrtko Ursulin
wrote:
>
>
> On 23/01/2022 18:38, Yury Norov wrote:
> > i915_pmu_cpu_online() calls cpumask_weight() to check if any bit of a
> > given cpumask is set. We can do it more efficiently with cpumask_empty()
> > because cpuma
-by: Yury Norov
---
drivers/gpu/drm/i915/i915_pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index ea655161793e..1894c876b31d 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915
s all bits unconditionally.
Signed-off-by: Yury Norov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
index d7fa2c49e741..56a3063545ec 100644
Ping?
On Fri, Jun 18, 2021 at 12:57:32PM -0700, Yury Norov wrote:
> for_each_bit() macro family uses find_bit() functions, so it's better
> to have for_each_bit() and find_bit() functions in the same header.
>
> This series puts for_each_bit() to a proper place and optimizes
On Sat, Jun 19, 2021 at 10:28:07AM -0700, Yury Norov wrote:
> On Sat, Jun 19, 2021 at 05:24:15PM +0100, Marc Zyngier wrote:
> > On Fri, 18 Jun 2021 20:57:34 +0100,
> > Yury Norov wrote:
> > >
> > > The macros iterate thru all set/clear bits in a bitmap. Th
On Mon, Jun 21, 2021 at 01:17:11PM -0700, Guenter Roeck wrote:
> On Fri, Jun 18, 2021 at 12:57:35PM -0700, Yury Norov wrote:
> > A couple of kernel functions call for_each_*_bit_from() with start
> > bit equal to 0. Replace them with for_each_*_bit().
> >
> > No fu
On Sat, Jun 19, 2021 at 05:24:15PM +0100, Marc Zyngier wrote:
> On Fri, 18 Jun 2021 20:57:34 +0100,
> Yury Norov wrote:
> >
> > The macros iterate thru all set/clear bits in a bitmap. They search a
> > first bit using find_first_bit(), and the rest bits using find_ne
A couple of kernel functions call for_each_*_bit_from() with start
bit equal to 0. Replace them with for_each_*_bit().
No functional changes, but might improve on readability.
Signed-off-by: Yury Norov
---
arch/x86/kernel/apic/vector.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gpu.c
The macros iterate thru all set/clear bits in a bitmap. They search a
first bit using find_first_bit(), and the rest bits using find_next_bit().
Since find_next_bit() is called shortly after find_first_bit(), we can
save few lines of I-cache by not using find_first_bit().
Signed-off-by: Yury
for_each_bit() macros depend on find_bit() machinery, and so the
proper place for them is the find.h header.
Signed-off-by: Yury Norov
---
include/linux/bitops.h | 34 --
include/linux/find.h | 34 ++
2 files changed, 34
-arch/20210612123639.329047-1-yury.no...@gmail.com/
The full series can be found here:
https://github.com/norov/linux/commits/bm-final
Yury Norov (3):
include/linux: move for_each_bit() macros from bitops.h to find.h
find: micro-optimize for_each_{set,clear}_bit()
Replace for_each_*_bit_from()
72 matches
Mail list logo
