[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdb=J+hiC5cu+g0Z-gqzpG8PgX01CXc4P98FfSSAf7PZEA@mail.gmail.com>
Date: Wed, 10 Sep 2025 23:32:26 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Keguang Zhang <keguang.zhang@...il.com>, Alban Bedel <albeu@...e.fr>,
Doug Berger <opendmb@...il.com>, Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Paul Walmsley <paul.walmsley@...ive.com>, Samuel Holland <samuel.holland@...ive.com>,
Yixun Lan <dlan@...too.org>, Andy Shevchenko <andy@...nel.org>, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 00/15] gpio: replace legacy bgpio_init() with its
modernized alternative - part 4
On Wed, Sep 10, 2025 at 9:12 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> Here's the final part of the generic GPIO chip conversions. Once all the
> existing users are switched to the new API, the final patch in the
> series removes bgpio_init(), moves the gpio-mmio fields out of struct
> gpio_chip and into struct gpio_generic_chip and adjusts gpio-mmio.c to
> the new situation.
>
> Down the line we could probably improve gpio-mmio.c by using lock guards
> and replacing the - now obsolete - "bgpio" prefix with "gpio_generic" or
> something similar but this series is already big as is so I'm leaving
> that for the future.
>
> Tested in qemu on vexpress-a9.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
The patch set is a beauty, hands down.
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
I especially like where you caught local spinlocks being
(ab)used instead of the generic irqchip ones.
I don't know about merging patch 15/15 into just the GPIO
tree, that can make things fail in other subsystems depending
on merge order into Torvalds tree or linux-next if your tree is
merged first.
I would merge the first 14 and keep the last for the later part
of the merge window when all other trees with conversions
are merged.
(You probably already thought of this.)
Yours,
Linus Walleij
Powered by blists - more mailing lists