mbox series

[v1,0/5] bitmap: get rid of bitmap_remap() and bitmap_biremap() uses

Message ID 20230926052007.3917389-1-andriy.shevchenko@linux.intel.com (mailing list archive)
Headers show
Series bitmap: get rid of bitmap_remap() and bitmap_biremap() uses | expand

Message

Andy Shevchenko Sept. 26, 2023, 5:20 a.m. UTC
As Rasmus suggested [1], the bit remapping APIs should be local to NUMA.
However, they are being in use outside of that for a while. To make
above happen, introduces simplified APIs that can be used otherwise.

It seems we might have yet another user of the above mentioned APIs.

The last patch has not been tested anyhow (except compilation, so
all testing and comments are welcome).

The idea is to get an immutable tag (via my tree) that can be pulled
by bitmap and GPIO trees on the need (while usually I send PR to
the GPIO subsystem).

Link: https://lore.kernel.org/all/20230815235934.47782-1-yury.norov@gmail.com/ [1]

Andy Shevchenko (5):
  lib/test_bitmap: Excape space symbols when printing input string
  lib/bitmap: Introduce bitmap_scatter() and bitmap_gather() helpers
  gpio: xilinx: Switch to use new bitmap_scatter() helper
  gpio: xilinx: Replace bitmap_bitremap() calls
  gpiolib: cdev: Utilize more bitmap APIs

 drivers/gpio/gpio-xilinx.c  | 13 ++----
 drivers/gpio/gpiolib-cdev.c | 79 +++++++++++++++++--------------------
 include/linux/bitmap.h      |  9 +++++
 lib/bitmap.c                | 70 ++++++++++++++++++++++++++++++++
 lib/test_bitmap.c           | 25 +++++++++++-
 5 files changed, 143 insertions(+), 53 deletions(-)

Comments

Linus Walleij Sept. 26, 2023, 8:52 a.m. UTC | #1
On Tue, Sep 26, 2023 at 7:20 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> As Rasmus suggested [1], the bit remapping APIs should be local to NUMA.
> However, they are being in use outside of that for a while. To make
> above happen, introduces simplified APIs that can be used otherwise.
>
> It seems we might have yet another user of the above mentioned APIs.
>
> The last patch has not been tested anyhow (except compilation, so
> all testing and comments are welcome).
>
> The idea is to get an immutable tag (via my tree) that can be pulled
> by bitmap and GPIO trees on the need (while usually I send PR to
> the GPIO subsystem).
>
> Link: https://lore.kernel.org/all/20230815235934.47782-1-yury.norov@gmail.com/ [1]

I don't understand the bitmap changes very well, but the resulting
changes to cdev look very nice clearly making that code more readable
and maintainable, so FWIW:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
Andy Shevchenko Sept. 26, 2023, 11:16 a.m. UTC | #2
On Tue, Sep 26, 2023 at 10:52:05AM +0200, Linus Walleij wrote:
> On Tue, Sep 26, 2023 at 7:20 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > As Rasmus suggested [1], the bit remapping APIs should be local to NUMA.
> > However, they are being in use outside of that for a while. To make
> > above happen, introduces simplified APIs that can be used otherwise.
> >
> > It seems we might have yet another user of the above mentioned APIs.
> >
> > The last patch has not been tested anyhow (except compilation, so
> > all testing and comments are welcome).
> >
> > The idea is to get an immutable tag (via my tree) that can be pulled
> > by bitmap and GPIO trees on the need (while usually I send PR to
> > the GPIO subsystem).
> >
> > Link: https://lore.kernel.org/all/20230815235934.47782-1-yury.norov@gmail.com/ [1]
> 
> I don't understand the bitmap changes very well,

Me neither... Oops (it was a joke :-)

> but the resulting
> changes to cdev look very nice clearly making that code more readable
> and maintainable,

While the above is a joke it took quite a time to get into the logic.
Hence this patch. TBH I'm in doubt, that's why asking for careful testing
and reviews.

> so FWIW:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Thank you!