* Re: [PATCH 0/2] upboard pinctrl support for device id INTC1055
From: GaryWang @ 2026-06-29 19:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linus Walleij, Mika Westerberg, Andy Shevchenko, Thomas Richard,
Daniele Cleri, JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <akKt4PV5E6lYpEZV@ashevche-desk.local>
On Tue, Jun 30, 2026 at 1:39 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Fri, Jun 12, 2026 at 01:05:35AM +0800, GaryWang wrote:
> > On Fri, Jun 12, 2026 at 12:04 AM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > > On Thu, Jun 11, 2026 at 02:30:00PM +0200, Linus Walleij wrote:
> > > > On Wed, Jun 10, 2026 at 4:13 PM Andy Shevchenko
> > > > <andriy.shevchenko@intel.com> wrote:
> > > > > On Wed, Jun 10, 2026 at 04:34:22PM +0800, GaryWang wrote:
>
> ...
>
> > > > > I can take both via Intel pin control tree, just waiting for Mika's and Linus' acks.
> > > > > Then I can send PR to Linus to (try to) include this to v7.2-rc2 as it seems close
> > > > > enough to the category of adding new HW support without breaking anything else.
> > > >
> > > > Excellent, thanks.
> > > > Acked-by: Linus Walleij< linusw@kernel.org>
> > >
> > > Thanks! I consider that for both patches. Gary, please send a v2 with all tags
> > > and elaborated commit messages and cover letter to address Mika's questions and
> > > concerns.
>
> > yeah, no problem to send patch V2 ASAP.
>
> Did I miss v2? If not, now is a good time for it.
no, I am preparing V3 to fix n series processor and based on 7.2-rc1,
I'll send it after 2 days, thanks.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* RE: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang (OSS) @ 2026-06-29 18:26 UTC (permalink / raw)
To: Andrew Davis, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Shenwei Wang, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn,
Bartosz Golaszewski
In-Reply-To: <655ef1d6-08fd-43a9-8507-c2d478c058d8@ti.com>
> -----Original Message-----
> From: Andrew Davis <afd@ti.com>
> Sent: Thursday, June 25, 2026 3:32 PM
...
> Subject: Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
> > + Say yes here to support the generic GPIO functions over the RPMSG
> > + bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
> > + i.MX9x.
>
> The support would depend on if the right firmware is loaded/running on the given
> remote core. Also if you want to make this generic, then any vendor should be
> able to make a firmware that implements this protocol and make use of this
> driver.
> Suggest dropping this NXP specific device list.
>
Agree.
> > +
> > + If unsure, say N.
> > +
> > +endmenu
> > +
> > menu "SPI GPIO expanders"
> > depends on SPI_MASTER
> >
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > b267598b517d..ee75c0e65b8b 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X) += gpio-
...
> > +
> > +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
> > + struct device *dev = &rpdev->dev;
> > + struct device_node *np;
> > + const char *rproc_name;
> > + int idx;
> > +
> > + idx = rpmsg_get_gpio_index(rpdev->id.name, CHAN_NAME_PREFIX);
> > + if (idx < 0)
> > + return -EINVAL;
> > +
> > + if (!dev->of_node) {
> > + np = rpmsg_get_channel_ofnode(rpdev, GPIO_COMPAT_STR, idx);
> > + if (!np)
> > + return -ENODEV;
>
> This seems to imply that DT nodes are required. RPMSG is a discoverable bus
> with a nameservice that can bind/probe new devices. While then optionally
> binding to a DT node when available so sub-devices can be described in DT is fine,
> I don't see why it should be required.
>
First, a GPIO node typically acts as a provider for other devices.
Second, by requiring a DT node, we can ensure that only explicitly enabled GPIO resources are managed and accessible.
> > +static struct rpmsg_driver rpmsg_gpio_channel_client = {
> > + .callback = rpmsg_gpio_channel_callback,
> > + .id_table = rpmsg_gpio_channel_id_table,
> > + .probe = rpmsg_gpio_channel_probe,
> > + .drv = {
> > + .name = KBUILD_MODNAME,
> > + .of_match_table = rpmsg_gpio_dt_ids,
>
> Does this line actually do anything anymore? Maybe it did when this was a
> platform_driver, but this is a rpmsg_driver and will probe though .id_table
> matches.
>
Yes, it can be removed because the driver will find the dt node on its own.
Thanks,
Shenwei
> Andrew
>
> > + },
> > +};
> > +module_rpmsg_driver(rpmsg_gpio_channel_client);
> > +
> > +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
> > +MODULE_DESCRIPTION("generic rpmsg gpio driver");
> > +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH 0/2] upboard pinctrl support for device id INTC1055
From: Andy Shevchenko @ 2026-06-29 17:39 UTC (permalink / raw)
To: GaryWang
Cc: Linus Walleij, Mika Westerberg, Andy Shevchenko, Thomas Richard,
Daniele Cleri, JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <CANYHO6rUVm=6WQSemJhMoVV5owPAL=4Nw4cFxULaKmq3fG36=A@mail.gmail.com>
On Fri, Jun 12, 2026 at 01:05:35AM +0800, GaryWang wrote:
> On Fri, Jun 12, 2026 at 12:04 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Thu, Jun 11, 2026 at 02:30:00PM +0200, Linus Walleij wrote:
> > > On Wed, Jun 10, 2026 at 4:13 PM Andy Shevchenko
> > > <andriy.shevchenko@intel.com> wrote:
> > > > On Wed, Jun 10, 2026 at 04:34:22PM +0800, GaryWang wrote:
...
> > > > I can take both via Intel pin control tree, just waiting for Mika's and Linus' acks.
> > > > Then I can send PR to Linus to (try to) include this to v7.2-rc2 as it seems close
> > > > enough to the category of adding new HW support without breaking anything else.
> > >
> > > Excellent, thanks.
> > > Acked-by: Linus Walleij< linusw@kernel.org>
> >
> > Thanks! I consider that for both patches. Gary, please send a v2 with all tags
> > and elaborated commit messages and cover letter to address Mika's questions and
> > concerns.
> yeah, no problem to send patch V2 ASAP.
Did I miss v2? If not, now is a good time for it.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-29 17:06 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-2-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:17 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
> v1 -> v2: open-code the descriptor mutex; drop the gpio_shared_desc_lock
> guard and the gpio_shared_lockdep_assert() helper, use
> guard(mutex) and lockdep_assert_held() directly; move the
> mutex rationale from the header to the can_sleep assignment in
> probe.
>
> v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-2-v@baodeep.com/
>
> drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++++-------------------
> drivers/gpio/gpiolib-shared.c | 9 +----
> drivers/gpio/gpiolib-shared.h | 28 +-------------
> 3 files changed, 29 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
> index 6941e4be6cf1..0cd52015b731 100644
> --- a/drivers/gpio/gpio-shared-proxy.c
> +++ b/drivers/gpio/gpio-shared-proxy.c
> @@ -9,8 +9,10 @@
> #include <linux/err.h>
> #include <linux/gpio/consumer.h>
> #include <linux/gpio/driver.h>
> +#include <linux/lockdep.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
> #include <linux/string_choices.h>
> #include <linux/types.h>
>
> @@ -32,7 +34,7 @@ gpio_shared_proxy_set_unlocked(struct gpio_shared_proxy_data *proxy,
I was about to apply it but then realized that it can be simplified further.
The set_func() argument in gpio_shared_proxy_set_unlocked() is no longer
needed and can be replaced with a direct call to gpiod_set_value_cansleep().
Would you mind sending a v3 with that included?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v5 0/5] Add support for AAEON SRG-IMX8P MCU
From: Thomas Perrot @ 2026-06-29 16:04 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: thomas.perrot@bootlin.com, devicetree, linux-kernel, linux-gpio,
imx, linux-arm-kernel, linux-watchdog, Thomas Petazzoni,
Miquel Raynal, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski
In-Reply-To: <b4396f57-3501-4e89-9cf3-8dc5d7cad9b7@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
Hello Guenter,
On Sat, 2026-04-11 at 17:12 -0700, Guenter Roeck wrote:
> snip
>
> Sashiko has some interesting feedback that might be worth looking
> into.
>
> https://sashiko.dev/#/patchset/20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668%40bootlin.com
>
Thanks for the pointer. I went through all findings and addressed the
valid ones in v6:
MFD driver:
- Set I2C_M_DMA_SAFE on all i2c_msg flags. The buffers were already
heap-allocated for DMA safety but the flag was missing, which
would have caused unnecessary bounce-buffering by the host driver.
- Add select REGMAP to config MFD_AAEON_MCU
- "Kconfig COMPILE_TEST link failure": I2C || COMPILE_TEST lets
MFD_AAEON_MCU=y even when I2C=m (tristate OR caps to y), which
would fail to link since i2c_transfer(), only exist when I2C
itself is built in. Will drop the COMPILE_TEST escape and just use
depends on I2C, matching the other I2C MFD drivers in this file.
GPIO driver:
- Replace __set_bit/__clear_bit/__assign_bit with their atomic
counterparts. gpiolib does not serialize across pins, so
concurrent direction changes on different pins could race on the
shared bitmaps.
- Reverse the order in aaeon_mcu_gpio_config_output_cmd(): write the
output value first, then switch the pin to output mode, to avoid a
potential glitch if the previously latched value differs.
- Add MODULE_ALIAS("platform:aaeon-mcu-gpio") for udev auto-loading.
Watchdog driver:
- Add WDIOF_SETTIMEOUT and watchdog_init_timeout() so the software
timeout is configurable via ioctl, DT timeout-sec, or the
watchdog_timeout boot parameter. This also addresses the concern
you raised about the hardcoded 240s timeout.
- Add watchdog_stop_on_reboot() so the MCU watchdog is stopped
during system shutdown, preventing a spurious reset from the
external MCU.
- Add MODULE_ALIAS("platform:aaeon-mcu-wdt") for udev auto-loading.
The following findings were considered false positives:
- "Heap buffer overflow during bulk writes": with reg_bits=16 and
val_bits=8, regcache_sync() calls _regmap_write() per register, so
the write callback always receives exactly 3 bytes (2 reg + 1
val).
No bulk path reaches the custom bus callback.
- "Stack DMA violation in read path": val_buf comes from regmap's
own
heap-allocated work_buf, not a stack pointer, so DMA safety is
guaranteed by the regmap core.
- "I2C interleaving race": Concurrent access from child drivers
(GPIO and watchdog) is serialized by regmap's internal mutex,
which is held for the entire bus transaction ; both i2c_transfer()
calls complete under that lock before another caller can enter.
- "Missing PM suspend/resume callbacks": the watchdog core already
handles this via watchdog_pm_ops, which calls wdt->ops->stop() on
system suspend.
Kind regards,
Thomas
> Guenter
>
--
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
From: Geert Uytterhoeven @ 2026-06-29 16:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, linux-sh, linux-kernel,
linux-input, linux-leds
In-Reply-To: <20260629130329.1291953-7-arnd@kernel.org>
On Mon, 29 Jun 2026 at 15:18, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> All users of the legacy interface now select CONFIG_GPIOLIB_LEGACY,
> so it can be turned off by default and only get built on platforms
> that still have one unconverted driver.
>
> Allow turning it on manually for compile testing, in order to keep
> the build coverage of the legacy drivers in allmodconfig and
> randconfig.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v5: added patch, now that we are getting closer to completing
> the series
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/6] [v5] leds: gpio: make legacy gpiolib interface optional
From: Arnd Bergmann @ 2026-06-29 15:58 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, linux-sh, linux-kernel,
linux-input, linux-leds, Bartosz Golaszewski
In-Reply-To: <akKKxHB6RMymG70Z@ashevche-desk.local>
On Mon, Jun 29, 2026, at 17:09, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 03:03:28PM +0200, Arnd Bergmann wrote:
>
>> gpiod = devm_gpiod_get_index_optional(dev, NULL, idx, GPIOD_OUT_LOW);
>> - if (IS_ERR(gpiod))
>> - return gpiod;
>
> We can leave these and rather have
>
> gpiod_set_consumer_name(gpiod, template->name);
> return gpiod;
>
> than introduce irregular pattern.
>
Ok, changed now.
Arnd
^ permalink raw reply
* Re: [PATCH 5/5] gpio: kunit: add test cases verifying swnode devlink support
From: Andy Shevchenko @ 2026-06-29 15:58 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Brendan Higgins, David Gow, Rae Moar, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Bartosz Golaszewski,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Linus Walleij, Dmitry Torokhov, linux-kernel, linux-kselftest,
kunit-dev, linux-acpi, driver-core, linux-gpio
In-Reply-To: <20260629-swnode-fw-devlink-v1-5-b90058b41839@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 12:52:10PM +0200, Bartosz Golaszewski wrote:
> The software node fw_devlink support already has its own kunit suite, but
> that verifies the fwnode links in isolation. Add GPIO tests that prove
> the ordering works in a real-life use-case: a GPIO consumer that
> references its provider via a software node.
>
> The first suite registers the provider's software node, adds the consumer
> device first and checks that fw_devlink defers its probe until the
> provider has been added and bound. The second covers the fallback:
> with the provider's software node not yet registered no supplier link is
> created, so the consumer probes, devm_gpiod_get() returns -EPROBE_DEFER
> and the consumer only binds once the provider shows up.
>
> While at it: the existing gpio_unbind_with_consumers() test keeps the
> consumer bound while the provider goes away and then operates the orphaned
> descriptor. With software nodes now being covered by fw_devlink that would
> instead force-unbind the consumer along with the provider, so opt it out
> by setting FWNODE_FLAG_LINKS_ADDED.
...
+ cleanup.h // guard()()
+ err.h // IS_ERR()
> #include <linux/platform_device.h>
> #include <linux/property.h>
+ types.h // bool
> +#include <kunit/fwnode.h>
> #include <kunit/platform_device.h>
> #include <kunit/test.h>
...
> + properties[1] = (struct property_entry){ };
Just zero the whole array at the definition time.
...
> + pdevinfo = (struct platform_device_info){
It's better to have a space after ).
> + .name = GPIO_PROBE_ORDER_TEST_CONSUMER,
> + .id = PLATFORM_DEVID_NONE,
> + .data = &gpio_probe_order_pdata_template,
> + .size_data = sizeof(gpio_probe_order_pdata_template),
> + .properties = properties,
> + };
...
> + pdevinfo = (struct platform_device_info){
Ditto.
> + .name = GPIO_TEST_PROVIDER,
> + .id = PLATFORM_DEVID_NONE,
> + .swnode = &gpio_test_provider_swnode,
> + };
...
> +struct gpio_probe_defer_pdata {
> + int probe_count;
Why is this signed?
> + int gpio_err;
> +};
...
> +static int gpio_probe_defer_consumer_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct gpio_probe_defer_pdata *pdata = dev_get_platdata(dev);
> + struct gpio_desc *desc;
> + pdata->probe_count++;
Even in case of error?
> + desc = devm_gpiod_get(dev, "foo", GPIOD_OUT_HIGH);
> + if (IS_ERR(desc)) {
> + pdata->gpio_err = PTR_ERR(desc);
> + return pdata->gpio_err;
> + }
> +
> + pdata->gpio_err = 0;
> +
> + return 0;
> +}
...
> +static void gpio_swnode_probe_defer_on_unregistered(struct kunit *test)
As per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/5] software node: add kunit tests for fw_devlink support
From: Andy Shevchenko @ 2026-06-29 15:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Brendan Higgins, David Gow, Rae Moar, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Bartosz Golaszewski,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Linus Walleij, Dmitry Torokhov, linux-kernel, linux-kselftest,
kunit-dev, linux-acpi, driver-core, linux-gpio
In-Reply-To: <20260629-swnode-fw-devlink-v1-3-b90058b41839@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 12:52:08PM +0200, Bartosz Golaszewski wrote:
> Add a kunit test suite for fw_devlink support for software nodes.
>
> Most cases call add_links() directly and inspect the resulting fwnode
> supplier/consumer lists: a single reference, multiple references, a
> reference to an unregistered node, a "remote-endpoint" reference and a
> reference array. The last case is end-to-end - it registers real consumer
> and supplier platform devices together with their drivers, adds the
> consumer first and checks that fw_devlink defers its probe until the
> supplier has been bound.
...
> ---
> drivers/base/test/Kconfig | 5 +
> drivers/base/test/Makefile | 3 +
> drivers/base/test/swnode-devlink-test.c | 336 ++++++++++++++++++++++++++++++++
+ MAINTAINERS.
...
> CFLAGS_property-entry-test.o += $(DISABLE_STRUCTLEAK_PLUGIN)
> +
> +obj-$(CONFIG_DRIVER_SWNODE_KUNIT_TEST) += swnode-devlink-test.o
> +CFLAGS_swnode-devlink-test.o += $(DISABLE_STRUCTLEAK_PLUGIN)
Is it the case for this?
...
> +#include <linux/device.h>
> +#include <linux/fwnode.h>
+ list.h
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/types.h>
> +#include <linux/wait.h>
...
> +static int swnode_count_suppliers(struct fwnode_handle *fwnode)
> +{
> + struct fwnode_link *link;
> + int ret = 0;
Why signed? Also it's not 'ret' semantically it's 'count'.
> + /*
> + * The suppliers and consumers lists should typically only be accessed
> + * with the fwnode_link_lock taken but it's private to the driver core.
> + *
> + * These are tests and at this point nobody should be modifying them so
> + * let's just access the list.
> + */
> + list_for_each_entry(link, &fwnode->suppliers, c_hook)
> + ret++;
> +
> + return ret;
> +}
...
> +/* A single reference creates exactly one supplier link, on both list ends. */
> +static void swnode_devlink_test_single_ref(struct kunit *test)
> +{
> + static const struct software_node supp_swnode = {
> + .name = "swnode-devlink-test-supplier"
Keep trailing comma.
> + };
> +
Redundant blank line.
> + struct fwnode_handle *cons_fwnode, *supp_fwnode;
> + int ret;
> +
> + const struct property_entry props[] = {
> + PROPERTY_ENTRY_REF("supplier", &supp_swnode),
> + { }
> + };
> +
> + supp_fwnode = kunit_software_node_register(test, &supp_swnode);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, supp_fwnode);
> +
> + cons_fwnode = kunit_fwnode_create_software_node(test, props, NULL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, cons_fwnode);
> +
> + ret = fwnode_call_int_op(cons_fwnode, add_links);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> +
> + KUNIT_EXPECT_EQ(test, swnode_count_suppliers(cons_fwnode), 1);
> + KUNIT_EXPECT_TRUE(test, swnode_has_link(cons_fwnode, supp_fwnode));
> +}
...
> +/* Multiple distinct references create multiple supplier links. */
> +static void swnode_devlink_test_multiple_refs(struct kunit *test)
> +{
> + static const struct software_node supp1_swnode = {
> + .name = "swnode-devlink-test-supplier-1"
Keep comma.
> + };
> + static const struct software_node supp2_swnode = {
> + .name = "swnode-devlink-test-supplier-2"
Ditto.
> + };
> + static const struct software_node *supp_nodes[] = {
> + &supp1_swnode, &supp2_swnode, NULL
Here it's fine.
> + };
> +
Redundant blank line.
> + const struct property_entry props[] = {
> + PROPERTY_ENTRY_REF("foo", &supp1_swnode),
> + PROPERTY_ENTRY_REF("bar", &supp2_swnode),
> + { }
> + };
> +
> + struct fwnode_handle *fwnode;
> + int ret;
> +
> + ret = kunit_software_node_register_node_group(test, supp_nodes);
> + KUNIT_ASSERT_EQ(test, ret, 0);
> +
> + fwnode = kunit_fwnode_create_software_node(test, props, NULL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fwnode);
> +
> + ret = fwnode_call_int_op(fwnode, add_links);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> +
> + KUNIT_EXPECT_EQ(test, swnode_count_suppliers(fwnode), 2);
> + KUNIT_EXPECT_TRUE(test, swnode_has_link(fwnode, software_node_fwnode(&supp1_swnode)));
> + KUNIT_EXPECT_TRUE(test, swnode_has_link(fwnode, software_node_fwnode(&supp2_swnode)));
> +}
...
> +static void swnode_devlink_test_unregistered_ref(struct kunit *test)
Same comments as per above.
...
> +static void swnode_devlink_test_remote_endpoint_excluded(struct kunit *test)
Ditto.
...
> +static void swnode_devlink_test_ref_array(struct kunit *test)
Ditto.
...
> +#define SWNODE_DEVLINK_TEST_TIMEOUT_MS 2000
(2 * MSEC_PER_SEC) ?
(will require time.h).
...
> +static int swnode_test_record_probe(struct platform_device *pdev)
> +{
> + struct swnode_test_probe_order *order = platform_get_drvdata(pdev);
> +
> + if (order && order->count < ARRAY_SIZE(order->probed)) {
+ array_size.h
> + order->probed[order->count++] = dev_name(&pdev->dev);
> + wake_up_interruptible(&order->wq);
> + }
> +
> + return 0;
> +}
...
> +static void swnode_devlink_test_probe_order(struct kunit *test)
As per above comments.
...
> +static struct kunit_suite swnode_test_suite = {
> + .name = "software-node-links",
> + .test_cases = swnode_test_cases,
> +};
> +
Redundant blank line.
> +kunit_test_suite(swnode_test_suite);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <CAMuHMdXhsM4JzArRuB=A46N-Ogbn2Fans+PVJVA-hEytFq=DeQ@mail.gmail.com>
On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Most remaining users of desc_to_gpio() only call it for printing debug
>> information.
>>
>> Replace this with a new gpiod_name() helper that returns the
>> gpio_desc->name string after checking the gpio_desc pointer.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for your patch!
Thanks for testing!
>> --- a/drivers/gpio/gpio-aggregator.c
>> +++ b/drivers/gpio/gpio-aggregator.c
>> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>>
>> fwd->descs[offset] = desc;
>>
>> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
>> - desc_to_gpio(desc), gpiod_to_irq(desc));
>> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
>> + gpiod_name(desc), gpiod_to_irq(desc));
>>
>> return 0;
>> }
>
> Before, this printed:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
>
> After, this prints:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
>
> Same results for instantiation using sysfs or configfs[1], although
> the latter does have optional support for specifying the name.
I wonder how many of the other instances have the same problem
then. Would it be appropriate for gpiochip_fwd_desc_add() to set
a name itself to address this one?
Arnd
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:45 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <akKN59lv55CXS3HU@ashevche-desk.local>
On Mon, Jun 29, 2026, at 17:23, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
>> +const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + return desc ? desc->name : "(no gpio)";
>
> Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
> one of validate_desc() / VALIDATE_DESC()?
Since all the callers previously call desc_to_gpio and that does
not even check desc at all, it would be a preexisting bug if
any caller passed an error pointer.
I added the NULL pointer check since many callers had that
part originally, like
tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
> Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
Any of those seem fine to me, not sure.
>> +static inline const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + WARN_ON(desc);
>> + return "(no gpio)";
>
> Hmm... This will be a second copy with a slight potential of going apart from
> the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
> and cons, in particular readability with define is questionable.)
I was mostly trying to optimize for consistency with the other
stub functions here. Since it should not actually be used at all
without gpiolib, returning NULL or an empty string here would
also work.
Arnd
^ permalink raw reply
* Re: (subset) [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Frank.Li @ 2026-06-29 15:43 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peter Rosin, Frank Li
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260504-pinctrl-mux-v6-0-8ea858ba3a5b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 04 May 2026 19:54:34 -0400, Frank Li wrote:
> Add a generic pinctrl binding for board-level pinmux chips that are
> controlled through the multiplexer subsystem.
>
> On some boards, especially development boards, external mux chips are used
> to switch SoC signals between different peripherals (e.g. MMC and UART).
> The mux select lines are often driven by a GPIO expander over I2C,
> as illustrated below:
>
> [...]
Applied, thanks!
[6/7] arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
commit: ec5c75673cb9d4c9a2a55a70d54a6ccb254f4ba4
[7/7] arm64: dts: imx8mp-evk: add flexcan2 overlay file
commit: 368eb597c6ef0263931a3922648e8c7b83cd0536
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 2/5] software node: add fw_devlink support
From: Andy Shevchenko @ 2026-06-29 15:42 UTC (permalink / raw)
To: Bartosz Golaszewski, Herve Codina
Cc: Brendan Higgins, David Gow, Rae Moar, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Bartosz Golaszewski,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Linus Walleij, Dmitry Torokhov, linux-kernel, linux-kselftest,
kunit-dev, linux-acpi, driver-core, linux-gpio
In-Reply-To: <20260629-swnode-fw-devlink-v1-2-b90058b41839@oss.qualcomm.com>
+Cc: Herve, to just ask the situation with one series that adds nice helper.
On Mon, Jun 29, 2026 at 12:52:07PM +0200, Bartosz Golaszewski wrote:
> Software nodes can be used to describe supplier-consumer relationships
> between devices they represent using reference property entries. Unlike
> for OF-nodes, driver core cannot yet use these references to create a
> probe order that avoids needless probe deferrals on missing providers.
>
> Implement software_node_add_links() modelled on of_fwnode_add_links().
> For every DEV_PROP_REF property we resolve each referenced supplier and
> create an fwnode link from the node to it. The driver core later promotes
> these to device links and defers the consumer until the suppliers are
> ready.
>
> There's no allowlist like the one DT needs - devicetree phandles appear
> in plenty of non-supplier contexts, but a software node only carries a
> reference property when its author explicitly points at another node, so
> we treat every reference as an intentional supplier dependency and link
> all of them. Graph "remote-endpoint" references are skipped for now: they
> go 2-ways between endpoint nodes and would create graph cycles without
> the port-parent lifting DT does via get_con_dev(). References to
> suppliers that aren't registered yet and self-references are ignored.
>
> fw_devlink resolves the supplier device through fwnode->dev but the core
> only records the owning device on the primary fwnode. When the software
> node is a device's secondary fwnode, mirror the device pointer onto it in
> software_node_notify() so the consumer can actually find the supplier
> instead of deferring forever.
>
> While at it: purge the fwnode links in software_node_release() now that
> software nodes can own them.
...
> +static int software_node_add_links(struct fwnode_handle *fwnode)
> +{
> + const struct software_node_ref_args *ref, *ref_array;
> + struct swnode *swnode = to_swnode(fwnode);
> + const struct property_entry *prop;
> + struct fwnode_handle *refnode;
> + unsigned int count, i;
'i' is local to the loop.
> + if (!swnode || !swnode->node->properties)
> + return 0;
> +
> + /*
> + * Unlike Device Tree, where phandles appear in many non-supplier
> + * contexts and a curated allowlist is required, a software node only
> + * carries a DEV_PROP_REF property when the author explicitly describes
> + * a reference to another node. Every such reference is therefore an
> + * intentional supplier dependency, so we create fwnode links for all
> + * of them.
> + */
> + for (prop = swnode->node->properties; prop->name; prop++) {
> + if (prop->type != DEV_PROP_REF || prop->is_inline)
> + continue;
> +
> + /*
> + * TODO: Graph "remote-endpoint" references go both ways
> + * between endpoint child nodes and would create endpoint
> + * cycles. Let's leave it out for now until we have potential
> + * users.
> + */
> + if (!strcmp(prop->name, "remote-endpoint"))
> + continue;
> +
> + ref_array = prop->pointer;
> + count = prop->length / sizeof(*ref_array);
Seems we are going to have more of a such, perhaps make a helper for counting
(which will do that division beneath).
> + for (i = 0; i < count; i++) {
for (unsigned int i = 0; i < count; i++) {
> +
Redundant blank line?
> + if (ref->swnode)
> + refnode = software_node_fwnode(ref->swnode);
> + else if (ref->fwnode)
> + refnode = ref->fwnode;
> + else
> + continue;
> +
> + /* Supplier not registered yet, or self-reference. */
> + if (!refnode || refnode == &swnode->fwnode)
> + continue;
> +
> + fwnode_link_add(&swnode->fwnode, refnode, 0);
> + }
> + }
> +
> + return 0;
> +}
...
> + /*
> + * When the software node is the device's secondary firmware node, the
> + * core only records the owning device on the primary fwnode (see
> + * device_add()). fw_devlink resolves a supplier device through
> + * fwnode->dev, so without this a consumer referencing the software
> + * node could never find the supplier device and would defer forever.
> + * Make fwnode.dev point to its owner in that case.
The below seems more balanced in terms of line lengths.
* When the software node is the device's secondary firmware node,
* the core only records the owning device on the primary fwnode
* (see device_add()). fw_devlink resolves a supplier device through
* fwnode->dev, so without this a consumer referencing the software
* node could never find the supplier device and would defer forever.
* Make fwnode.dev point to its owner in that case.
> + */
> + if (dev_fwnode(dev) != &swnode->fwnode && !swnode->fwnode.dev)
> + swnode->fwnode.dev = dev;
Doesn't Herve's patch(es) add some helpers for this?
https://lore.kernel.org/lkml/20260511155930.34604-2-herve.codina@bootlin.com/
Ah, still not applied :-( Perhaps it can be applied as just part that brings
fw_devlink_set_device()?
> + /*
> + * Drop the device pointer mirrored onto a secondary software node in
> + * software_node_notify(). For a primary software node the core owns
> + * fwnode->dev and clears it in device_del().
> + */
> + if (dev_fwnode(dev) != &swnode->fwnode && swnode->fwnode.dev == dev)
> + swnode->fwnode.dev = NULL;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-29 15:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
Hi Arnd,
On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for your patch!
> Not sure if this the way we want to take this, or if the gpio name is
> an appropriate replacement in debug printk.
>
> Since most of the callers of desc_to_gpio() and gpio_to_desc() are
> otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
> include linux/gpio/legacy.h, only a handful of instances remain that
> are otherwise in files that otherwise only use the descriptor interfaces:
> --- a/drivers/gpio/gpio-aggregator.c
> +++ b/drivers/gpio/gpio-aggregator.c
> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>
> fwd->descs[offset] = desc;
>
> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> - desc_to_gpio(desc), gpiod_to_irq(desc));
> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> + gpiod_name(desc), gpiod_to_irq(desc));
>
> return 0;
> }
Before, this printed:
gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
After, this prints:
gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
Same results for instantiation using sysfs or configfs[1], although
the latter does have optional support for specifying the name.
[1] Documentation/admin-guide/gpio/gpio-aggregator.rst
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Andy Shevchenko @ 2026-06-29 15:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
Oh, that's nice!
...
> +/**
> + * gpiod_name() - get a name to print for a gpio descriptor
> + * @desc: gpio or NULL pointer to query
> + *
> + * Returns:
> + * The desc->name field or a dummy string for unknown GPIOs.
> + */
> +const char *gpiod_name(const struct gpio_desc *desc)
> +{
> + return desc ? desc->name : "(no gpio)";
Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
one of validate_desc() / VALIDATE_DESC()?
Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
> +}
...
> +static inline const char *gpiod_name(const struct gpio_desc *desc)
> +{
> + WARN_ON(desc);
> + return "(no gpio)";
Hmm... This will be a second copy with a slight potential of going apart from
the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
and cons, in particular readability with define is questionable.)
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 5/6] [v5] leds: gpio: make legacy gpiolib interface optional
From: Andy Shevchenko @ 2026-06-29 15:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, linux-sh, linux-kernel,
linux-input, linux-leds, Bartosz Golaszewski
In-Reply-To: <20260629130329.1291953-6-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:03:28PM +0200, Arnd Bergmann wrote:
> There are still a handful of ancient mips/armv5/sh boards that use the
> gpio_led:gpio member to pass an old-style gpio number, but all modern
> users have been converted to gpio descriptors.
>
> While the CONFIG_GPIOLIB_LEGACY option that guards devm_gpio_request_one()
> and related helpers is currently turned on in all kernel builds,
> the plan is to only enable it on the few platforms that actually
> pass gpio numbers in any platform_data.
>
> Split out the legacy portion of the platform_data handling into a custom
> helper function that is guarded with in #ifdef block, to allow the
> the leds-gpio driver to compile cleanly when CONFIG_GPIOLIB_LEGACY
> gets turned off. Once the last user is converted, this function can
> be removed.
...
> gpiod = devm_gpiod_get_index_optional(dev, NULL, idx, GPIOD_OUT_LOW);
> - if (IS_ERR(gpiod))
> - return gpiod;
We can leave these and rather have
gpiod_set_consumer_name(gpiod, template->name);
return gpiod;
than introduce irregular pattern.
> - if (gpiod) {
> + if (!IS_ERR(gpiod))
> gpiod_set_consumer_name(gpiod, template->name);
> - return gpiod;
> - }
>
> - /*
> - * This is the legacy code path for platform code that
> - * still uses GPIO numbers. Ultimately we would like to get
> - * rid of this block completely.
> - */
> + return gpiod;
> +}
I haven't insisted on this previously as I thought that this was on track to be
applied. Since it's not (yet), please, amend the change.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: Krzysztof Kozlowski @ 2026-06-29 14:44 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
Cc: Abel Vesa
In-Reply-To: <20260612090426.23403-2-krzysztof.kozlowski@oss.qualcomm.com>
On 12/06/2026 11:04, Krzysztof Kozlowski wrote:
> Document Qualcomm PMK7750 GPIO used with Eliza SoC. PMIC is almost the
> same as PMK8550, thus compatible with it.
>
> Cc: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v3:
> 1. Drop stale pmk7750 from main enum lisrt (the big one) - leftover of
> previous version
>
> Changes in v2:
> 1. Add fallback compatible.
> ---
> .../bindings/pinctrl/qcom,pmic-gpio.yaml | 151 +++++++++---------
> 1 file changed, 78 insertions(+), 73 deletions(-)
After some internal discussions, we concluded that it probably is the
same die as pmk8550, just fused differently, thus does not deserve
dedicated compatible and patch can be dropped.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] gpio: swnode: remove deprecated lookup mechanism
From: Andy Shevchenko @ 2026-06-29 14:35 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Linus Walleij, Dmitry Torokhov, Andy Shevchenko, linux-gpio,
linux-kernel, Bartosz Golaszewski
In-Reply-To: <CAMRc=MdZeUEMh28_NCNo1k02E3X_A2tUsv6YuUUWONPoy2nwBQ@mail.gmail.com>
On Mon, Jun 29, 2026 at 07:04:43AM -0700, Bartosz Golaszewski wrote:
> On Mon, 29 Jun 2026 15:10:40 +0200, Andy Shevchenko
> <andriy.shevchenko@intel.com> said:
> > On Mon, Jun 29, 2026 at 12:54:58PM +0200, Bartosz Golaszewski wrote:
...
> >> fwnode_lookup:
> >> - gdev = gpio_device_find_by_fwnode(fwnode);
> >
> >> - return gdev ?: ERR_PTR(-EPROBE_DEFER);
> >
> > Can we simply leave these two instead?
>
> Honestly, that's just personal preference. I prefer the oneliner.
I was under impression that gdev variable has use after this, but LKP showed
that you missed its removal. With that in mind, I have no objections against
oneliner.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Arnd Bergmann @ 2026-06-29 14:24 UTC (permalink / raw)
To: Andreas Schwab, Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, Netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <mvmik71win7.fsf@suse.de>
On Mon, Jun 29, 2026, at 16:01, Andreas Schwab wrote:
> On Jun 29 2026, Arnd Bergmann wrote:
>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> The linux/gpio.h header used to be the global definition for the gpio
>> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
>> 130 of those remain, so this series cleans out the rest.
>>
>> In each subsystem, we can replace the header either with
>> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
>
> A few of them already used <linux/gpio/consumer.h>, and is duplicated
> now.
Indeed, I have removed the extra ones now and folded those into
the patches.
Arnd
diff --git a/drivers/gpib/gpio/gpib_bitbang.c b/drivers/gpib/gpio/gpib_bitbang.c
index 2e8d895db06a..34d14b94a0b8 100644
--- a/drivers/gpib/gpio/gpib_bitbang.c
+++ b/drivers/gpib/gpio/gpib_bitbang.c
@@ -64,7 +64,6 @@
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
#include <linux/gpio/machine.h>
-#include <linux/gpio/consumer.h>
#include <linux/irq.h>
static int sn7516x_used = 1, sn7516x;
diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
index 98d0269a978f..8863b741d1a3 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -16,7 +16,6 @@
#include <linux/interrupt.h>
#include <linux/jiffies.h>
#include <linux/module.h>
-#include <linux/gpio/consumer.h>
#include <linux/input/matrix_keypad.h>
#include <linux/slab.h>
#include <linux/of.h>
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index eb11bf2e9436..a6c984205123 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -15,7 +15,6 @@
#include <linux/dmi.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio_keys.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
static bool use_low_level_irq;
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 88c5c52e0e38..5f5adc9c9e83 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -16,7 +16,6 @@
#include <linux/net_tstamp.h>
#include <linux/ptp_classify.h>
#include <linux/ptp_pch.h>
-#include <linux/gpio/consumer.h>
#define PCH_GBE_MAR_ENTRIES 16
#define PCH_GBE_SHORT_PKT 64
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index a18263d5bb02..06151f207134 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -9,7 +9,6 @@
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
index d9c06129ed23..171bf097a8b8 100644
--- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
+++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
@@ -4,7 +4,6 @@
#include <linux/delay.h>
#include <linux/extcon-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 2233babc0078..1f5dba49ace4 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/mfd/syscon.h>
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index 5040c7d1e1b9..2089ec5124e8 100644
--- a/include/linux/mfd/ti-lmu.h
+++ b/include/linux/mfd/ti-lmu.h
@@ -10,7 +10,6 @@
#ifndef __MFD_TI_LMU_H__
#define __MFD_TI_LMU_H__
-#include <linux/gpio/consumer.h>
#include <linux/notifier.h>
#include <linux/regmap.h>
#include <linux/gpio/consumer.h>
diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
index 36c3abc21fed..f2448b4c11fc 100644
--- a/sound/soc/codecs/cs42l84.c
+++ b/sound/soc/codecs/cs42l84.c
@@ -16,7 +16,6 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/i2c.h>
-#include <linux/gpio/consumer.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/acpi.h>
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 8b05d6f9b429..cbed11136935 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -7,7 +7,6 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
^ permalink raw reply related
* Re: [PATCH] gpio: swnode: remove deprecated lookup mechanism
From: kernel test robot @ 2026-06-29 14:23 UTC (permalink / raw)
To: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Andy Shevchenko
Cc: oe-kbuild-all, linux-gpio, linux-kernel
In-Reply-To: <20260629-gpio-swnode-drop-label-matching-v1-1-db1af36cf883@oss.qualcomm.com>
Hi Bartosz,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dc59e4fea9d83f03bad6bddf3fa2e52491777482]
url: https://github.com/intel-lab-lkp/linux/commits/Bartosz-Golaszewski/gpio-swnode-remove-deprecated-lookup-mechanism/20260629-185811
base: dc59e4fea9d83f03bad6bddf3fa2e52491777482
patch link: https://lore.kernel.org/r/20260629-gpio-swnode-drop-label-matching-v1-1-db1af36cf883%40oss.qualcomm.com
patch subject: [PATCH] gpio: swnode: remove deprecated lookup mechanism
config: m68k-allnoconfig (https://download.01.org/0day-ci/archive/20260629/202606292234.A3QghcWA-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260629/202606292234.A3QghcWA-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606292234.A3QghcWA-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpio/gpiolib-swnode.c: In function 'swnode_get_gpio_device':
>> drivers/gpio/gpiolib-swnode.c:29:29: warning: unused variable 'gdev' [-Wunused-variable]
29 | struct gpio_device *gdev;
| ^~~~
vim +/gdev +29 drivers/gpio/gpiolib-swnode.c
e7f9ff5dc90c38 Dmitry Torokhov 2022-11-11 25
b7b56e64a345e7 Bartosz Golaszewski 2023-09-27 26 static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode)
e7f9ff5dc90c38 Dmitry Torokhov 2022-11-11 27 {
b7b56e64a345e7 Bartosz Golaszewski 2023-09-27 28 const struct software_node *gdev_node;
b7b56e64a345e7 Bartosz Golaszewski 2023-09-27 @29 struct gpio_device *gdev;
e7f9ff5dc90c38 Dmitry Torokhov 2022-11-11 30
b7b56e64a345e7 Bartosz Golaszewski 2023-09-27 31 gdev_node = to_software_node(fwnode);
6774a66d0e103d Bartosz Golaszewski 2025-12-15 32 if (!gdev_node)
216c1204757190 Bartosz Golaszewski 2025-11-20 33 goto fwnode_lookup;
e7f9ff5dc90c38 Dmitry Torokhov 2022-11-11 34
9d50f95bc0d5df Charles Keepax 2024-04-16 35 /*
9d50f95bc0d5df Charles Keepax 2024-04-16 36 * Check for a special node that identifies undefined GPIOs, this is
9d50f95bc0d5df Charles Keepax 2024-04-16 37 * primarily used as a key for internal chip selects in SPI bindings.
9d50f95bc0d5df Charles Keepax 2024-04-16 38 */
9d50f95bc0d5df Charles Keepax 2024-04-16 39 if (IS_ENABLED(CONFIG_GPIO_SWNODE_UNDEFINED) &&
6774a66d0e103d Bartosz Golaszewski 2025-12-15 40 gdev_node == &swnode_gpio_undefined)
9d50f95bc0d5df Charles Keepax 2024-04-16 41 return ERR_PTR(-ENOENT);
9d50f95bc0d5df Charles Keepax 2024-04-16 42
216c1204757190 Bartosz Golaszewski 2025-11-20 43 fwnode_lookup:
ff373b244a4cbb Bartosz Golaszewski 2026-06-29 44 return gpio_device_find_by_fwnode(fwnode) ?: ERR_PTR(-EPROBE_DEFER);
e7f9ff5dc90c38 Dmitry Torokhov 2022-11-11 45 }
e7f9ff5dc90c38 Dmitry Torokhov 2022-11-11 46
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [BUG] I2C HID touchpad BLTP7853:00 347D:7853 enumerates but reports no events on MECHREVO XINGYAO Series-P916F-PTL
From: Steve Yang @ 2026-06-29 14:15 UTC (permalink / raw)
To: linux-input, linux-acpi, linux-i2c, linux-gpio
Hello,
Resending as plain text; sorry if this is a duplicate. My previous
message was rejected by linux-acpi because Gmail sent a HTML part.
I am seeing a non-working internal I2C HID touchpad on a new MECHREVO
laptop. The device enumerates, binds to i2c_hid_acpi + hid-multitouch,
and userspace sees it as a touchpad, but touching/clicking it produces
no input events. The GPIO interrupt counter also does not increase
while touching the pad.
I am new to kernel debugging, but I have the machine here and can test
patches, ACPI overrides, debug kernels, etc.
Hardware
========
DMI, with serial/UUID intentionally omitted:
BIOS Vendor: MECHREVO
BIOS Version: 1.00
BIOS Release Date: 03/14/2026
Firmware Revision: 1.48
EC Firmware Revision: 1.0
System Manufacturer: MECHREVO
Product Name: XINGYAO Series
Family: Panther Lake
Base Board Product Name: XINGYAO Series-P916F-PTL
Software
========
Linux archbook 7.0.14-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 27 Jun
2026 16:15:10 +0000 x86_64 GNU/Linux
linux-firmware 20260622-1
libinput 1.31.3
hid-tools 0.12
acpica 20251212
Kernel command line at initial capture time:
BOOT_IMAGE=/vmlinuz-linux root=UUID=<omitted> rw rootflags=subvol=@
loglevel=3 quiet
Device identification
=====================
/sys/bus/i2c/devices/i2c-BLTP7853:00/uevent:
DRIVER=i2c_hid_acpi
MODALIAS=acpi:BLTP7853:PNP0C50:
/sys/bus/hid/devices/0018:347D:7853.0001/uevent:
DRIVER=hid-multitouch
HID_ID=0018:0000347D:00007853
HID_NAME=BLTP7853:00 347D:7853
HID_PHYS=i2c-BLTP7853:00
MODALIAS=hid:b0018g0004v0000347Dp00007853
udev for /dev/input/event5:
DEVNAME=/dev/input/event5
ID_INPUT=1
ID_INPUT_TOUCHPAD=1
ID_INPUT_WIDTH_MM=115
ID_INPUT_HEIGHT_MM=72
ID_BUS=i2c
ID_INTEGRATION=internal
ID_INPUT_TOUCHPAD_INTEGRATION=internal
LIBINPUT_DEVICE_GROUP=18/347d/7853:i2c-BLTP7853:00
Symptoms / tests
================
1. dmesg shows the device binding successfully:
input: BLTP7853:00 347D:7853 Mouse ...
input: BLTP7853:00 347D:7853 Touchpad ...
hid-generic 0018:347D:7853.0001: input,hidraw0: I2C HID v1.00 Mouse
[BLTP7853:00 347D:7853] on i2c-BLTP7853:00
input: BLTP7853:00 347D:7853 Touchpad ...
hid-multitouch 0018:347D:7853.0001: input,hidraw0: I2C HID v1.00
Mouse [BLTP7853:00 347D:7853] on i2c-BLTP7853:00
2. evtest on /dev/input/event5 shows normal-looking touchpad
capabilities, for example
ABS_X/ABS_Y/ABS_MT_POSITION_X/ABS_MT_POSITION_Y/ABS_MT_SLOT/ABS_MT_TRACKING_ID
and BTN_TOUCH/BTN_LEFT. However, during physical touch/click tests it
prints no events after:
Testing ... (interrupt to exit)
3. /proc/interrupts has an IRQ for the touchpad in the original ACPI
configuration:
intel-gpio 18 BLTP7853:00
While physically touching/clicking the touchpad, the counter did not increase.
4. debugfs gpio shows this line as claimed by the touchpad and high:
gpiochip1: 51 GPIOs, parent: platform/INTC10BC:01, INTC10BC:01:
gpio-18 ( |TPD0 GpioInt(0) ) in hi IRQ
5. KDE/libinput sees a touchpad-class input device, but the pointer
does not move and clicks do not work.
Things already tried
====================
None of these changed the behavior:
- acpi_osi=Windows 2021
- BIOS option named "Enable Windows OSI"
- unbind/bind i2c-BLTP7853:00 from i2c_hid_acpi
- echo on > /sys/bus/i2c/devices/i2c-BLTP7853:00/power/control
- unloading huawei_wmi
- setting HID feature Inputmode=3 with hid-feature
- setting HID feature Surface Switch=1 and Button Switch=1
ACPI override experiments
=========================
The kernel supports ACPI table upgrade, and I confirmed the modified
SSDT was loaded each time via dmesg, for example:
ACPI: Table Upgrade: override [SSDT-XXXXXX-I2C_DEVT]
I tried these changes to the touchpad GpioInt resource:
original: GpioInt(Level, ActiveLow, ...)
test 1: GpioInt(Level, ActiveHigh, ...)
test 2: GpioInt(Edge, ActiveLow, ...)
test 3: GpioInt(Edge, ActiveHigh, ...)
All three GpioInt variants still resulted in an intel-gpio IRQ for
BLTP7853:00, but the IRQ counter did not increase while
touching/clicking the touchpad.
I also forced _CRS to return the SBFI Interrupt() resource instead of
the SBFG GpioInt() resource. That changed the interrupt to:
IR-IO-APIC 84-fasteoi BLTP7853:00
but it caused an apparent interrupt storm, with the counter increasing
by thousands over a few seconds, and still no evtest events. So the
Interrupt() path does not look correct either.
ACPI notes
==========
The touchpad ACPI device appears in SSDT under:
\_SB.PC00.I2C5.TPD0
Relevant decompiled pieces from ssdt18.dsl:
Scope (\_SB.PC00.I2C5)
{
Device (TPD0)
{
Name (HID2, Zero)
...
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,
"\\_SB.GPI1", 0x00, ResourceConsumer, ,)
{ 0x0000 }
})
Name (SBFI, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow,
ExclusiveAndWake, ,, _Y08)
{
0x00000000,
}
})
CreateWordField (SBFB, \_SB.PC00.I2C5.TPD0._Y07._ADR, BADR)
CreateDWordField (SBFB, \_SB.PC00.I2C5.TPD0._Y07._SPE, SPED)
CreateWordField (SBFG, 0x17, INT1)
CreateDWordField (SBFI, \_SB.PC00.I2C5.TPD0._Y08._INT, INT2)
Method (_INI, 0, NotSerialized)
{
INT1 = GNUM (\TPIT)
INT2 = INUM (\TPIT)
If ((TPDM == Zero))
{
SHPO (\TPIT, One)
}
SGRA (\TPIT, TPDM)
If ((TPDM == One))
{
SGII (\TPIT, Zero)
GRXE (\TPIT, Zero)
}
If ((\TPTY == One))
{
_HID = "BLTP7853"
HID2 = One
BADR = 0x2C
SPED = 0x00061A80
Return (Zero)
}
}
Name (_HID, "XXXX0000")
Name (_CID, "PNP0C50")
Method (_CRS, 0, NotSerialized)
{
If ((TPDM == Zero))
{
Return (ConcatenateResTemplate (I2CM (I2CX, BADR,
SPED), SBFG))
}
Return (ConcatenateResTemplate (I2CM (I2CX, BADR, SPED), SBFI))
}
}
}
ssdt13.dsl defines the NVS fields used by that code:
OperationRegion (LCNV, SystemMemory, 0x6FDE4000, 0x0300)
Field (LCNV, AnyAcc, Lock, Preserve)
{
EDID, 4096,
TPTY, 8,
TPST, 8,
TPIT, 32,
...
}
A possibly relevant observation from the same SSDT: under
\_SB.PC00.I2C5, TPD0 seems to use the PXTC power resource, and the
Arg0==0 path in PON() appears to only route/configure IRQ. The Arg0==1
path, apparently for the touch panel PTPL resource, is the one that
toggles TPWR/TRST GPIOs. I have not tested overriding TPD0 to use that
power resource yet.
Question
========
Does this still look like an ACPI GPIO/resource issue, or should I now
focus on an i2c-hid/hid-multitouch quirk or a missing vendor-specific
reset/init sequence for HID 347D:7853?
I have a full debug bundle available, including acpidump, decompiled
SSDTs, dmesg, udev info, evtest output, hid-recorder output,
dmidecode, and /proc/interrupts snapshots. I can provide any specific
files or test patches you want.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Andreas Schwab @ 2026-06-29 14:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Jun 29 2026, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
A few of them already used <linux/gpio/consumer.h>, and is duplicated
now.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* [PATCH] gpio-f7188x: Add support for NCT6126D version B
From: Paul Louvel @ 2026-06-29 14:07 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Henning Schild, Simon Guinot
Cc: linux-gpio, linux-kernel, Thomas Petazzoni, stable, Paul Louvel
The Nuvoton NCT6126D Super-I/O is available in two hardware revisions.
According to the manufacturer datasheet revision 2.4, version A reports
chip ID 0xD283, while version B reports chip ID 0xD284.
The driver currently only recognizes only the version A ID. Version B
only contains hardware fixes unrelated to the GPIO functionality, so it
can be supported by simply adding its chip ID without any other driver
changes.
Fixes: 3002b8642f01 ("gpio-f7188x: fix chip name and pin count on Nuvoton chip")
Cc: stable@vger.kernel.org
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
---
drivers/gpio/gpio-f7188x.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-f7188x.c b/drivers/gpio/gpio-f7188x.c
index 4d5b927ad70f..fb007b978729 100644
--- a/drivers/gpio/gpio-f7188x.c
+++ b/drivers/gpio/gpio-f7188x.c
@@ -48,7 +48,8 @@
/*
* Nuvoton devices.
*/
-#define SIO_NCT6126D_ID 0xD283 /* NCT6126D chipset ID */
+#define SIO_NCT6126D_VER_A_ID 0xD283 /* NCT6126D version A chipset ID */
+#define SIO_NCT6126D_VER_B_ID 0xD284 /* NCT6126D version B chipset ID */
#define SIO_LD_GPIO_NUVOTON 0x07 /* GPIO logical device */
@@ -564,7 +565,8 @@ static int __init f7188x_find(int addr, struct f7188x_sio *sio)
case SIO_F81865_ID:
sio->type = f81865;
break;
- case SIO_NCT6126D_ID:
+ case SIO_NCT6126D_VER_A_ID:
+ case SIO_NCT6126D_VER_B_ID:
sio->device = SIO_LD_GPIO_NUVOTON;
sio->type = nct6126d;
break;
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260629-gpio-f7188x-nct6126d-version-b-a83cd56689b9
Best regards,
--
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply related
* Re: [PATCH] gpio: swnode: remove deprecated lookup mechanism
From: Bartosz Golaszewski @ 2026-06-29 14:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov,
Andy Shevchenko, linux-gpio, linux-kernel, Bartosz Golaszewski
In-Reply-To: <akJu0EFRFUjxaq34@ashevche-desk.local>
On Mon, 29 Jun 2026 15:10:40 +0200, Andy Shevchenko
<andriy.shevchenko@intel.com> said:
> On Mon, Jun 29, 2026 at 12:54:58PM +0200, Bartosz Golaszewski wrote:
>> GPIO software node lookup should rely exclusively on matching the
>> addresses of the referenced firmware nodes. Commit e5d527be7e69 ("gpio:
>> swnode: don't use the swnode's name as the key for GPIO lookup") tried to
>> enforce this but had to be reverted: it broke existing users who abused
>> the software node mechanism by creating "dummy" software nodes named
>> after the device they want to get GPIOs from, without ever attaching them
>> to the actual GPIO devices. Those users relied on GPIOLIB matching the
>> label of the GPIO controller against the name of the software node rather
>> than on a real firmware node link.
>>
>> All such users have now been coverted to using attached software nodes
>> via the fwnode address lookup path and the kernel documentation has been
>> updated to recommend it as the correct approach. This allows us to remove
>> the old behavior.
>>
>> This will allow us to leverage the upcoming support for fw_devlink for
>> software nodes in GPIO core.
>
> I am in favour of this,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> (but I prefer cleaner diff, see below).
>
> ...
>
>> fwnode_lookup:
>> - gdev = gpio_device_find_by_fwnode(fwnode);
>
>> - return gdev ?: ERR_PTR(-EPROBE_DEFER);
>
>
> Can we simply leave these two instead?
>
Honestly, that's just personal preference. I prefer the oneliner.
Bart
^ permalink raw reply
* [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 13:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Marcel Holtmann, MyungJoo Ham, Chanwoo Choi,
Geert Uytterhoeven, Andy Shevchenko, Dmitry Torokhov, Ulf Hansson,
linux-bluetooth, linux-kernel, linux-gpio, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc, linux-arm-kernel, linux-pm,
linux-usb
From: Arnd Bergmann <arnd@arndb.de>
Most remaining users of desc_to_gpio() only call it for printing debug
information.
Replace this with a new gpiod_name() helper that returns the
gpio_desc->name string after checking the gpio_desc pointer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Not sure if this the way we want to take this, or if the gpio name is
an appropriate replacement in debug printk.
Since most of the callers of desc_to_gpio() and gpio_to_desc() are
otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
include linux/gpio/legacy.h, only a handful of instances remain that
are otherwise in files that otherwise only use the descriptor interfaces:
arch/arm/mach-pxa/pxa27x.c: reset_gpio = desc_to_gpio(gpiod);
arch/arm/plat-orion/gpio.c: unsigned gpio = desc_to_gpio(desc);
drivers/gpio/gpio-nomadik.c: mode = nmk_prcm_gpiocr_get_mode(pctldev, desc_to_gpio(desc));
drivers/gpio/gpiolib-acpi-core.c: desc = gpio_to_desc(agpio->pin_table[pin_index]);
drivers/gpio/gpiolib-cdev.c: hte_init_line_attr(hdesc, desc_to_gpio(line->desc), flags, NULL,
drivers/gpio/gpiolib-sysfs.c: desc = gpio_to_desc(gpio);
drivers/gpio/gpiolib-sysfs.c: desc_to_gpio(desc));
drivers/gpio/gpiolib.c: trace_gpio_direction(desc_to_gpio(desc), 1, ret);
drivers/input/misc/soc_button_array.c: *gpio_ret = desc_to_gpio(desc);
drivers/pinctrl/core.c: gdev = gpiod_to_gpio_device(gpio_to_desc(gpio_num));
drivers/platform/x86/x86-android-tablets/core.c: * 2. Calling desc_to_gpio() to get an old style GPIO number for gpio-keys
drivers/soc/fsl/qe/gpio.c: gpio_num = desc_to_gpio(gpiod);
---
drivers/bluetooth/hci_intel.c | 4 ++--
drivers/extcon/extcon-rtk-type-c.c | 4 ++--
drivers/gpio/gpio-aggregator.c | 4 ++--
drivers/gpio/gpiolib.c | 13 +++++++++++++
drivers/gpu/drm/bridge/analogix/anx7625.c | 6 +++---
drivers/i2c/busses/i2c-gpio.c | 4 ++--
drivers/iio/accel/mma9551.c | 4 ++--
drivers/iio/humidity/dht11.c | 2 +-
drivers/input/touchscreen/edt-ft5x06.c | 6 +++---
drivers/input/touchscreen/hycon-hy46xx.c | 5 ++---
drivers/mmc/host/atmel-mci.c | 8 ++++----
drivers/power/supply/bq24257_charger.c | 2 +-
drivers/usb/gadget/udc/at91_udc.c | 4 ++--
include/linux/gpio/consumer.h | 8 ++++++++
14 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
index c31105b91e47..2e6ebc152bcb 100644
--- a/drivers/bluetooth/hci_intel.c
+++ b/drivers/bluetooth/hci_intel.c
@@ -1176,8 +1176,8 @@ static int intel_probe(struct platform_device *pdev)
list_add_tail(&idev->list, &intel_device_list);
mutex_unlock(&intel_device_list_lock);
- dev_info(&pdev->dev, "registered, gpio(%d)/irq(%d).\n",
- desc_to_gpio(idev->reset), idev->irq);
+ dev_info(&pdev->dev, "registered, gpio(%s)/irq(%d).\n",
+ gpiod_name(idev->reset), idev->irq);
return 0;
}
diff --git a/drivers/extcon/extcon-rtk-type-c.c b/drivers/extcon/extcon-rtk-type-c.c
index 82b60b927e41..fb57e9d7ddb6 100644
--- a/drivers/extcon/extcon-rtk-type-c.c
+++ b/drivers/extcon/extcon-rtk-type-c.c
@@ -1356,8 +1356,8 @@ static int extcon_rtk_type_c_probe(struct platform_device *pdev)
(int)PTR_ERR(gpio));
} else {
type_c->rd_ctrl_gpio_desc = gpio;
- dev_dbg(dev, "%s get rd-ctrl-gpios (id=%d) OK\n",
- __func__, desc_to_gpio(gpio));
+ dev_dbg(dev, "%s get rd-ctrl-gpios (id=%s) OK\n",
+ __func__, gpiod_name(gpio));
}
}
diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
index bc6699a821ee..27df680fbdbb 100644
--- a/drivers/gpio/gpio-aggregator.c
+++ b/drivers/gpio/gpio-aggregator.c
@@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
fwd->descs[offset] = desc;
- dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
- desc_to_gpio(desc), gpiod_to_irq(desc));
+ dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
+ gpiod_name(desc), gpiod_to_irq(desc));
return 0;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1f498d6c8c68..00de24db74a5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -4122,6 +4122,19 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)
}
EXPORT_SYMBOL_GPL(gpiod_set_consumer_name);
+/**
+ * gpiod_name() - get a name to print for a gpio descriptor
+ * @desc: gpio or NULL pointer to query
+ *
+ * Returns:
+ * The desc->name field or a dummy string for unknown GPIOs.
+ */
+const char *gpiod_name(const struct gpio_desc *desc)
+{
+ return desc ? desc->name : "(no gpio)";
+}
+EXPORT_SYMBOL_GPL(gpiod_name);
+
/**
* gpiod_is_shared() - check if this GPIO can be shared by multiple consumers
* @desc: GPIO to inspect
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c
index fffcd6154c71..5dce097d4045 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1448,9 +1448,9 @@ static void anx7625_init_gpio(struct anx7625_data *platform)
if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
platform->pdata.low_power_mode = 1;
- DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %d, reset %d.\n",
- desc_to_gpio(platform->pdata.gpio_p_on),
- desc_to_gpio(platform->pdata.gpio_reset));
+ DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %s, reset %s.\n",
+ gpiod_name(platform->pdata.gpio_p_on),
+ gpiod_name(platform->pdata.gpio_reset));
} else {
platform->pdata.low_power_mode = 0;
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode.\n");
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index f4355b17bfbf..4c320a833d9e 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -440,8 +440,8 @@ static int i2c_gpio_probe(struct platform_device *pdev)
* get accessors to get the actual name of the GPIO line,
* from the descriptor, then provide that instead.
*/
- dev_info(dev, "using lines %u (SDA) and %u (SCL%s)\n",
- desc_to_gpio(priv->sda), desc_to_gpio(priv->scl),
+ dev_info(dev, "using lines %s (SDA) and %s (SCL%s)\n",
+ gpiod_name(priv->sda), gpiod_name(priv->scl),
pdata->scl_is_output_only
? ", no clock stretching" : "");
diff --git a/drivers/iio/accel/mma9551.c b/drivers/iio/accel/mma9551.c
index 020370b0ec07..b9d1fc3caf83 100644
--- a/drivers/iio/accel/mma9551.c
+++ b/drivers/iio/accel/mma9551.c
@@ -426,8 +426,8 @@ static int mma9551_gpio_probe(struct iio_dev *indio_dev)
return ret;
}
- dev_dbg(dev, "gpio resource, no:%d irq:%d\n",
- desc_to_gpio(gpio), data->irqs[i]);
+ dev_dbg(dev, "gpio resource, no:%s irq:%d\n",
+ gpiod_name(gpio), data->irqs[i]);
}
return 0;
diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
index 980cb946bbf7..ca6b8c53e462 100644
--- a/drivers/iio/humidity/dht11.c
+++ b/drivers/iio/humidity/dht11.c
@@ -305,7 +305,7 @@ static int dht11_probe(struct platform_device *pdev)
dht11->irq = gpiod_to_irq(dht11->gpiod);
if (dht11->irq < 0) {
- dev_err(dev, "GPIO %d has no interrupt\n", desc_to_gpio(dht11->gpiod));
+ dev_err(dev, "GPIO %s has no interrupt\n", gpiod_name(dht11->gpiod));
return -EINVAL;
}
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index d3b1177185a3..2d31c77614b0 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1326,10 +1326,10 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client)
edt_ft5x06_ts_prepare_debugfs(tsdata);
dev_dbg(&client->dev,
- "EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
+ "EDT FT5x06 initialized: IRQ %d, WAKE pin %s, Reset pin %s.\n",
client->irq,
- tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
- tsdata->reset_gpio ? desc_to_gpio(tsdata->reset_gpio) : -1);
+ gpiod_name(tsdata->wake_gpio),
+ gpiod_name(tsdata->reset_gpio));
return 0;
}
diff --git a/drivers/input/touchscreen/hycon-hy46xx.c b/drivers/input/touchscreen/hycon-hy46xx.c
index 1513f20cbf51..797667c5dd99 100644
--- a/drivers/input/touchscreen/hycon-hy46xx.c
+++ b/drivers/input/touchscreen/hycon-hy46xx.c
@@ -528,9 +528,8 @@ static int hycon_hy46xx_probe(struct i2c_client *client)
return error;
dev_dbg(&client->dev,
- "HYCON HY46XX initialized: IRQ %d, Reset pin %d.\n",
- client->irq,
- tsdata->reset_gpio ? desc_to_gpio(tsdata->reset_gpio) : -1);
+ "HYCON HY46XX initialized: IRQ %d, Reset pin %s.\n",
+ client->irq, gpiod_name(tsdata->reset_gpio));
return 0;
}
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 3b4928f5b9b2..b21820564315 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2255,11 +2255,11 @@ static int atmci_init_slot(struct atmel_mci *host,
slot->sdio_irq = sdio_irq;
dev_dbg(&mmc->class_dev,
- "slot[%u]: bus_width=%u, detect_pin=%d, "
- "detect_is_active_high=%s, wp_pin=%d\n",
- id, slot_data->bus_width, desc_to_gpio(slot_data->detect_pin),
+ "slot[%u]: bus_width=%u, detect_pin=%s, "
+ "detect_is_active_high=%s, wp_pin=%s\n",
+ id, slot_data->bus_width, gpiod_name(slot_data->detect_pin),
str_true_false(!gpiod_is_active_low(slot_data->detect_pin)),
- desc_to_gpio(slot_data->wp_pin));
+ gpiod_name(slot_data->wp_pin));
mmc->ops = &atmci_ops;
mmc->f_min = DIV_ROUND_UP(host->bus_hz, 512);
diff --git a/drivers/power/supply/bq24257_charger.c b/drivers/power/supply/bq24257_charger.c
index 72f1bfea8d54..b756bab74eec 100644
--- a/drivers/power/supply/bq24257_charger.c
+++ b/drivers/power/supply/bq24257_charger.c
@@ -868,7 +868,7 @@ static void bq24257_pg_gpio_probe(struct bq24257_device *bq)
}
if (bq->pg)
- dev_dbg(bq->dev, "probed PG pin = %d\n", desc_to_gpio(bq->pg));
+ dev_dbg(bq->dev, "probed PG pin = %s\n", gpiod_name(bq->pg));
}
static int bq24257_fw_probe(struct bq24257_device *bq)
diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c
index 5aa360ba4f03..099313604387 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1896,8 +1896,8 @@ static int at91udc_probe(struct platform_device *pdev)
gpiod_to_irq(udc->board.vbus_pin),
at91_vbus_irq, 0, driver_name, udc);
if (retval) {
- DBG("request vbus irq %d failed\n",
- desc_to_gpio(udc->board.vbus_pin));
+ DBG("request vbus irq %s failed\n",
+ gpiod_name(udc->board.vbus_pin));
goto err_unprepare_iclk;
}
}
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index fceeefd5f893..9c91fae62f8c 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -172,6 +172,8 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name);
bool gpiod_is_shared(const struct gpio_desc *desc);
+const char *gpiod_name(const struct gpio_desc *desc);
+
/* Convert between the old gpio_ and new gpiod_ interfaces */
struct gpio_desc *gpio_to_desc(unsigned gpio);
int desc_to_gpio(const struct gpio_desc *desc);
@@ -538,6 +540,12 @@ static inline bool gpiod_is_shared(const struct gpio_desc *desc)
return false;
}
+static inline const char *gpiod_name(const struct gpio_desc *desc)
+{
+ WARN_ON(desc);
+ return "(no gpio)";
+}
+
static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
{
return NULL;
--
2.39.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox