[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200424135011.GA3255@icarus>
Date: Fri, 24 Apr 2020 09:50:33 -0400
From: William Breathitt Gray <vilhelm.gray@...il.com>
To: akpm@...ux-foundation.org
Cc: Syed Nayyar Waris <syednwaris@...il.com>,
andriy.shevchenko@...ux.intel.com, michal.simek@...inx.com,
arnd@...db.de, rrichter@...vell.com, linus.walleij@...aro.org,
bgolaszewski@...libre.com, yamada.masahiro@...ionext.com,
rui.zhang@...el.com, daniel.lezcano@...aro.org,
amit.kucheria@...durent.com, linux-arch@...r.kernel.org,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/6] Introduce the for_each_set_clump macro
On Fri, Apr 24, 2020 at 05:54:07PM +0530, Syed Nayyar Waris wrote:
> This patchset introduces a new generic version of for_each_set_clump.
> The previous version of for_each_set_clump8 used a fixed size 8-bit
> clump, but the new generic version can work with clump of any size but
> less than or equal to BITS_PER_LONG. The patchset utilizes the new macro
> in several GPIO drivers.
Regarding the nomenclature, I created the term "clump" to represent an
8-bit value that was not necessarily a byte yet was a contiguous
grouping of bits. With this patchset, we now have a more generic
for_each_set_clump macro that can handle values larger and smaller than
8-bits.
Would it make sense to retire the term "clump" and instead use "nbits"
where applicable, in order to match the existing convention used by the
bitmap functions; for instance, would it be better to name this macro
for_each_set_nbits?
William Breathitt Gray
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists