[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYCY+P5+6nk28TQ9stoyYO83q1X1YG7mbrBJnG65uTwwA@mail.gmail.com>
Date: Tue, 26 Sep 2023 10:52:05 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Yury Norov <yury.norov@...il.com>, linux-gpio@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Shubhrajyoti Datta <shubhrajyoti.datta@....com>,
Srinivas Neeli <srinivas.neeli@....com>,
Michal Simek <michal.simek@....com>,
Bartosz Golaszewski <brgl@...ev.pl>,
Andy Shevchenko <andy@...nel.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Marek Behún <kabel@...nel.org>
Subject: Re: [PATCH v1 0/5] bitmap: get rid of bitmap_remap() and
bitmap_biremap() uses
On Tue, Sep 26, 2023 at 7:20 AM Andy Shevchenko
<andriy.shevchenko@...ux.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@...aro.org>
Yours,
Linus Walleij
Powered by blists - more mailing lists