* [PATCH v4 00/10] gpio: improve support for shared GPIOs
@ 2025-11-12 13:55 Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 01/10] string: provide strends() Bartosz Golaszewski
` (16 more replies)
0 siblings, 17 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
this series however impacts Qualcomm platforms. It's a runtime dependency
of patches 8 and 9. Would you mind Acking it so that I can take it into
an immutable branch that I'll make available to Mark Brown for him to
take patches 8-10 through the ASoC and regulator trees for v6.19?
Problem statement: GPIOs are implemented as a strictly exclusive
resource in the kernel but there are lots of platforms on which single
pin is shared by multiple devices which don't communicate so need some
way of properly sharing access to a GPIO. What we have now is the
GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
doesn't do any locking or arbitration of access - it literally just hand
the same GPIO descriptor to all interested users.
The proposed solution is composed of three major parts: the high-level,
shared GPIO proxy driver that arbitrates access to the shared pin and
exposes a regular GPIO chip interface to consumers, a low-level shared
GPIOLIB module that scans firmware nodes and creates auxiliary devices
that attach to the proxy driver and finally a set of core GPIOLIB
changes that plug the former into the GPIO lookup path.
The changes are implemented in a way that allows to seamlessly compile
out any code related to sharing GPIOs for systems that don't need it.
The practical use-case for this are the powerdown GPIOs shared by
speakers on Qualcomm db845c platform, however I have also extensively
tested it using gpio-virtuser on arm64 qemu with various DT
configurations.
I'm Cc'ing some people that may help with reviewing/be interested in
this: OF maintainers (because the main target are OF systems initially),
Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
in audio or regulator drivers and one of the goals of this series is
dropping the hand-crafted GPIO enable counting via struct
regulator_enable_gpio in regulator core), Andy and Mika because I'd like
to also cover ACPI (even though I don't know about any ACPI platform that
would need this at the moment, I think it makes sense to make the
solution complete), Dmitry (same thing but for software nodes), Mani
(because you have a somewhat related use-case for the PERST# signal and
I'd like to hear your input on whether this is something you can use or
maybe it needs a separate, implicit gpio-perst driver similar to what
Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
last week in person and I also use the auxiliary bus for the proxy
devices).
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Changes in v4:
- Collect tags
- Extend Cc list
- Link to v3: https://lore.kernel.org/r/20251029-gpio-shared-v3-0-71c568acf47c@linaro.org
Changes in v3:
- Make strends() a static inline function
- Use an empty release() callback for auxiliary devices
- Refactor the code for finding the shared descriptors in the GPIOLIB
shared module, split it into several smaller functions
- Use str_high_low() where applicable
- Use non-atomic bit ops where atomicity is not required
- Link to v2: https://lore.kernel.org/r/20251022-gpio-shared-v2-0-d34aa1fbdf06@linaro.org
Changes in v2:
- Fix a memory leak in error path in gpiolib-shared
- Drop the gpio-wcd934x fix that already went upstream
- Free resources used during scanning by GPIOs that turned out to be
unique
- Rework the OF property scanning
- Add patches making the regulator subsystem aware of shared GPIOs
managed by GPIOLIB
- Link to v1: https://lore.kernel.org/r/20250924-gpio-shared-v1-0-775e7efeb1a3@linaro.org
---
Bartosz Golaszewski (10):
string: provide strends()
gpiolib: define GPIOD_FLAG_SHARED
gpiolib: implement low-level, shared GPIO support
gpio: shared-proxy: implement the shared GPIO proxy driver
gpiolib: support shared GPIOs in core subsystem code
gpio: provide gpiod_is_shared()
arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
regulator: make the subsystem aware of shared GPIOs
arch/arm64/Kconfig.platforms | 1 +
drivers/gpio/Kconfig | 17 ++
drivers/gpio/Makefile | 2 +
drivers/gpio/gpio-shared-proxy.c | 333 +++++++++++++++++++++++
drivers/gpio/gpiolib-shared.c | 558 +++++++++++++++++++++++++++++++++++++++
drivers/gpio/gpiolib-shared.h | 71 +++++
drivers/gpio/gpiolib.c | 70 ++++-
drivers/gpio/gpiolib.h | 2 +
drivers/regulator/core.c | 8 +
include/linux/gpio/consumer.h | 9 +
include/linux/string.h | 18 ++
lib/tests/string_kunit.c | 13 +
sound/soc/codecs/wsa881x.c | 3 +-
sound/soc/codecs/wsa883x.c | 7 +-
14 files changed, 1096 insertions(+), 16 deletions(-)
---
base-commit: 96bf1bb63977b67d1a3e4a3645f857bc3fa03f48
change-id: 20250908-gpio-shared-67ec352884b6
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v4 01/10] string: provide strends()
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-17 20:33 ` Kees Cook
2025-11-12 13:55 ` [PATCH v4 02/10] gpiolib: define GPIOD_FLAG_SHARED Bartosz Golaszewski
` (15 subsequent siblings)
16 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Implement a function for checking if a string ends with a different
string and add its kunit test cases.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
include/linux/string.h | 18 ++++++++++++++++++
lib/tests/string_kunit.c | 13 +++++++++++++
2 files changed, 31 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index fdd3442c6bcbd786e177b6e87358e1065a0ffafc..929d05d1247c76eb9011fe34250b487834b2d3c9 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -562,4 +562,22 @@ static inline bool strstarts(const char *str, const char *prefix)
return strncmp(str, prefix, strlen(prefix)) == 0;
}
+/**
+ * strends - Check if a string ends with another string.
+ * @str - NULL-terminated string to check against @suffix
+ * @suffix - NULL-terminated string defining the suffix to look for in @str
+ *
+ * Returns:
+ * True if @str ends with @suffix. False in all other cases.
+ */
+static inline bool strends(const char *str, const char *suffix)
+{
+ unsigned int str_len = strlen(str), suffix_len = strlen(suffix);
+
+ if (str_len < suffix_len)
+ return false;
+
+ return !(strcmp(str + str_len - suffix_len, suffix));
+}
+
#endif /* _LINUX_STRING_H_ */
diff --git a/lib/tests/string_kunit.c b/lib/tests/string_kunit.c
index 0ed7448a26d3aa0fe9e2a6a894d4c49c2c0b86e0..f9a8e557ba7734c9848d58ff986407d8000f52ee 100644
--- a/lib/tests/string_kunit.c
+++ b/lib/tests/string_kunit.c
@@ -602,6 +602,18 @@ static void string_test_memtostr(struct kunit *test)
KUNIT_EXPECT_EQ(test, dest[7], '\0');
}
+static void string_test_strends(struct kunit *test)
+{
+ KUNIT_EXPECT_TRUE(test, strends("foo-bar", "bar"));
+ KUNIT_EXPECT_TRUE(test, strends("foo-bar", "-bar"));
+ KUNIT_EXPECT_TRUE(test, strends("foobar", "foobar"));
+ KUNIT_EXPECT_TRUE(test, strends("foobar", ""));
+ KUNIT_EXPECT_FALSE(test, strends("bar", "foobar"));
+ KUNIT_EXPECT_FALSE(test, strends("", "foo"));
+ KUNIT_EXPECT_FALSE(test, strends("foobar", "ba"));
+ KUNIT_EXPECT_TRUE(test, strends("", ""));
+}
+
static struct kunit_case string_test_cases[] = {
KUNIT_CASE(string_test_memset16),
KUNIT_CASE(string_test_memset32),
@@ -623,6 +635,7 @@ static struct kunit_case string_test_cases[] = {
KUNIT_CASE(string_test_strlcat),
KUNIT_CASE(string_test_strtomem),
KUNIT_CASE(string_test_memtostr),
+ KUNIT_CASE(string_test_strends),
{}
};
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 02/10] gpiolib: define GPIOD_FLAG_SHARED
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 01/10] string: provide strends() Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support Bartosz Golaszewski
` (14 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Define a new GPIO descriptor flag for marking pins that are shared by
multiple consumer. This flag will be used in several places so we need
to do it in advance and separately from other changes.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/gpiolib.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 14e6a9807a89da6d7c6594a0a2de5f5032c49e0d..c9de4bb10584206f4888c0f28468762a3680aae6 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -204,6 +204,7 @@ struct gpio_desc {
#define GPIOD_FLAG_EDGE_FALLING 17 /* GPIO CDEV detects falling edge events */
#define GPIOD_FLAG_EVENT_CLOCK_REALTIME 18 /* GPIO CDEV reports REALTIME timestamps in events */
#define GPIOD_FLAG_EVENT_CLOCK_HTE 19 /* GPIO CDEV reports hardware timestamps in events */
+#define GPIOD_FLAG_SHARED 20 /* GPIO is shared by multiple consumers */
/* Connection label */
struct gpio_desc_label __rcu *label;
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 01/10] string: provide strends() Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 02/10] gpiolib: define GPIOD_FLAG_SHARED Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-26 15:34 ` Cosmin Tanislav
2026-03-11 18:38 ` Jon Hunter
2025-11-12 13:55 ` [PATCH v4 04/10] gpio: shared-proxy: implement the shared GPIO proxy driver Bartosz Golaszewski
` (13 subsequent siblings)
16 siblings, 2 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This module scans the device tree (for now only OF nodes are supported
but care is taken to make other fwnode implementations easy to
integrate) and determines which GPIO lines are shared by multiple users.
It stores that information in memory. When the GPIO chip exposing shared
lines is registered, the shared GPIO descriptors it exposes are marked
as shared and virtual "proxy" devices that mediate access to the shared
lines are created. When a consumer of a shared GPIO looks it up, its
fwnode lookup is redirected to a just-in-time machine lookup that points
to this proxy device.
This code can be compiled out on platforms which don't use shared GPIOs.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/Kconfig | 8 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpiolib-shared.c | 540 ++++++++++++++++++++++++++++++++++++++++++
drivers/gpio/gpiolib-shared.h | 71 ++++++
4 files changed, 620 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ce237398fa00eddad49afe995accae3abbb4b2cb..f90b4d3e77f7cab46525b7adfcf114a21d276678 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -6,6 +6,9 @@
config GPIOLIB_LEGACY
def_bool y
+config HAVE_SHARED_GPIOS
+ bool
+
menuconfig GPIOLIB
bool "GPIO Support"
help
@@ -42,6 +45,11 @@ config GPIOLIB_IRQCHIP
select IRQ_DOMAIN
bool
+config GPIO_SHARED
+ def_bool y
+ depends on HAVE_SHARED_GPIOS || COMPILE_TEST
+ select AUXILIARY_BUS
+
config DEBUG_GPIO
bool "Debug GPIO calls"
depends on DEBUG_KERNEL
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ee260a0809d36cd07987f04e0ef17b05af764214..48f309c764e3286c23dbe604be933f7180f0b89a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
obj-$(CONFIG_GPIO_ACPI) += gpiolib-acpi.o
gpiolib-acpi-y := gpiolib-acpi-core.o gpiolib-acpi-quirks.o
obj-$(CONFIG_GPIOLIB) += gpiolib-swnode.o
+obj-$(CONFIG_GPIO_SHARED) += gpiolib-shared.o
# Device drivers. Generally keep list sorted alphabetically
obj-$(CONFIG_GPIO_REGMAP) += gpio-regmap.o
diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
new file mode 100644
index 0000000000000000000000000000000000000000..56b9b03cbb6dbcdf095a656fc36ff321770035da
--- /dev/null
+++ b/drivers/gpio/gpiolib-shared.c
@@ -0,0 +1,540 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 Linaro Ltd.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/auxiliary_bus.h>
+#include <linux/cleanup.h>
+#include <linux/device.h>
+#include <linux/fwnode.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/machine.h>
+#include <linux/idr.h>
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/lockdep.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/overflow.h>
+#include <linux/printk.h>
+#include <linux/property.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+
+#include "gpiolib.h"
+#include "gpiolib-shared.h"
+
+/* Represents a single reference to a GPIO pin. */
+struct gpio_shared_ref {
+ struct list_head list;
+ /* Firmware node associated with this GPIO's consumer. */
+ struct fwnode_handle *fwnode;
+ /* GPIO flags this consumer uses for the request. */
+ enum gpiod_flags flags;
+ char *con_id;
+ int dev_id;
+ struct auxiliary_device adev;
+ struct gpiod_lookup_table *lookup;
+};
+
+/* Represents a single GPIO pin. */
+struct gpio_shared_entry {
+ struct list_head list;
+ /* Firmware node associated with the GPIO controller. */
+ struct fwnode_handle *fwnode;
+ /* Hardware offset of the GPIO within its chip. */
+ unsigned int offset;
+ /* Index in the property value array. */
+ size_t index;
+ struct gpio_shared_desc *shared_desc;
+ struct kref ref;
+ struct list_head refs;
+};
+
+static LIST_HEAD(gpio_shared_list);
+static DEFINE_MUTEX(gpio_shared_lock);
+static DEFINE_IDA(gpio_shared_ida);
+
+static struct gpio_shared_entry *
+gpio_shared_find_entry(struct fwnode_handle *controller_node,
+ unsigned int offset)
+{
+ struct gpio_shared_entry *entry;
+
+ list_for_each_entry(entry, &gpio_shared_list, list) {
+ if (entry->fwnode == controller_node && entry->offset == offset)
+ return entry;
+ }
+
+ return NULL;
+}
+
+#if IS_ENABLED(CONFIG_OF)
+static int gpio_shared_of_traverse(struct device_node *curr)
+{
+ struct gpio_shared_entry *entry;
+ size_t con_id_len, suffix_len;
+ struct fwnode_handle *fwnode;
+ struct of_phandle_args args;
+ struct property *prop;
+ unsigned int offset;
+ const char *suffix;
+ int ret, count, i;
+
+ for_each_property_of_node(curr, prop) {
+ /*
+ * The standard name for a GPIO property is "foo-gpios"
+ * or "foo-gpio". Some bindings also use "gpios" or "gpio".
+ * There are some legacy device-trees which have a different
+ * naming convention and for which we have rename quirks in
+ * place in gpiolib-of.c. I don't think any of them require
+ * support for shared GPIOs so for now let's just ignore
+ * them. We can always just export the quirk list and
+ * iterate over it here.
+ */
+ if (!strends(prop->name, "-gpios") &&
+ !strends(prop->name, "-gpio") &&
+ strcmp(prop->name, "gpios") != 0 &&
+ strcmp(prop->name, "gpio") != 0)
+ continue;
+
+ count = of_count_phandle_with_args(curr, prop->name,
+ "#gpio-cells");
+ if (count <= 0)
+ continue;
+
+ for (i = 0; i < count; i++) {
+ struct device_node *np __free(device_node) = NULL;
+
+ ret = of_parse_phandle_with_args(curr, prop->name,
+ "#gpio-cells", i,
+ &args);
+ if (ret)
+ continue;
+
+ np = args.np;
+
+ if (!of_property_present(np, "gpio-controller"))
+ continue;
+
+ /*
+ * We support 1, 2 and 3 cell GPIO bindings in the
+ * kernel currently. There's only one old MIPS dts that
+ * has a one-cell binding but there's no associated
+ * consumer so it may as well be an error. There don't
+ * seem to be any 3-cell users of non-exclusive GPIOs,
+ * so we can skip this as well. Let's occupy ourselves
+ * with the predominant 2-cell binding with the first
+ * cell indicating the hardware offset of the GPIO and
+ * the second defining the GPIO flags of the request.
+ */
+ if (args.args_count != 2)
+ continue;
+
+ fwnode = of_fwnode_handle(args.np);
+ offset = args.args[0];
+
+ entry = gpio_shared_find_entry(fwnode, offset);
+ if (!entry) {
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ return -ENOMEM;
+
+ entry->fwnode = fwnode_handle_get(fwnode);
+ entry->offset = offset;
+ entry->index = count;
+ INIT_LIST_HEAD(&entry->refs);
+
+ list_add_tail(&entry->list, &gpio_shared_list);
+ }
+
+ struct gpio_shared_ref *ref __free(kfree) =
+ kzalloc(sizeof(*ref), GFP_KERNEL);
+ if (!ref)
+ return -ENOMEM;
+
+ ref->fwnode = fwnode_handle_get(of_fwnode_handle(curr));
+ ref->flags = args.args[1];
+
+ if (strends(prop->name, "gpios"))
+ suffix = "-gpios";
+ else if (strends(prop->name, "gpio"))
+ suffix = "-gpio";
+ else
+ suffix = NULL;
+ if (!suffix)
+ continue;
+
+ /* We only set con_id if there's actually one. */
+ if (strcmp(prop->name, "gpios") && strcmp(prop->name, "gpio")) {
+ ref->con_id = kstrdup(prop->name, GFP_KERNEL);
+ if (!ref->con_id)
+ return -ENOMEM;
+
+ con_id_len = strlen(ref->con_id);
+ suffix_len = strlen(suffix);
+
+ ref->con_id[con_id_len - suffix_len] = '\0';
+ }
+
+ ref->dev_id = ida_alloc(&gpio_shared_ida, GFP_KERNEL);
+ if (ref->dev_id < 0) {
+ kfree(ref->con_id);
+ return -ENOMEM;
+ }
+
+ if (!list_empty(&entry->refs))
+ pr_debug("GPIO %u at %s is shared by multiple firmware nodes\n",
+ entry->offset, fwnode_get_name(entry->fwnode));
+
+ list_add_tail(&no_free_ptr(ref)->list, &entry->refs);
+ }
+ }
+
+ for_each_child_of_node_scoped(curr, child) {
+ ret = gpio_shared_of_traverse(child);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int gpio_shared_of_scan(void)
+{
+ return gpio_shared_of_traverse(of_root);
+}
+#else
+static int gpio_shared_of_scan(void)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
+static void gpio_shared_adev_release(struct device *dev)
+{
+
+}
+
+static int gpio_shared_make_adev(struct gpio_device *gdev,
+ struct gpio_shared_ref *ref)
+{
+ struct auxiliary_device *adev = &ref->adev;
+ int ret;
+
+ lockdep_assert_held(&gpio_shared_lock);
+
+ memset(adev, 0, sizeof(*adev));
+
+ adev->id = ref->dev_id;
+ adev->name = "proxy";
+ adev->dev.parent = gdev->dev.parent;
+ adev->dev.release = gpio_shared_adev_release;
+
+ ret = auxiliary_device_init(adev);
+ if (ret)
+ return ret;
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ pr_debug("Created an auxiliary GPIO proxy %s for GPIO device %s\n",
+ dev_name(&adev->dev), gpio_device_get_label(gdev));
+
+ return 0;
+}
+
+int gpio_shared_add_proxy_lookup(struct device *consumer, unsigned long lflags)
+{
+ const char *dev_id = dev_name(consumer);
+ struct gpio_shared_entry *entry;
+ struct gpio_shared_ref *ref;
+
+ struct gpiod_lookup_table *lookup __free(kfree) =
+ kzalloc(struct_size(lookup, table, 2), GFP_KERNEL);
+ if (!lookup)
+ return -ENOMEM;
+
+ guard(mutex)(&gpio_shared_lock);
+
+ list_for_each_entry(entry, &gpio_shared_list, list) {
+ list_for_each_entry(ref, &entry->refs, list) {
+ if (!device_match_fwnode(consumer, ref->fwnode))
+ continue;
+
+ /* We've already done that on a previous request. */
+ if (ref->lookup)
+ return 0;
+
+ char *key __free(kfree) =
+ kasprintf(GFP_KERNEL,
+ KBUILD_MODNAME ".proxy.%u",
+ ref->adev.id);
+ if (!key)
+ return -ENOMEM;
+
+ pr_debug("Adding machine lookup entry for a shared GPIO for consumer %s, with key '%s' and con_id '%s'\n",
+ dev_id, key, ref->con_id ?: "none");
+
+ lookup->dev_id = dev_id;
+ lookup->table[0] = GPIO_LOOKUP(no_free_ptr(key), 0,
+ ref->con_id, lflags);
+
+ gpiod_add_lookup_table(no_free_ptr(lookup));
+
+ return 0;
+ }
+ }
+
+ /* We warn here because this can only happen if the programmer borked. */
+ WARN_ON(1);
+ return -ENOENT;
+}
+
+static void gpio_shared_remove_adev(struct auxiliary_device *adev)
+{
+ lockdep_assert_held(&gpio_shared_lock);
+
+ auxiliary_device_uninit(adev);
+ auxiliary_device_delete(adev);
+}
+
+int gpio_device_setup_shared(struct gpio_device *gdev)
+{
+ struct gpio_shared_entry *entry;
+ struct gpio_shared_ref *ref;
+ unsigned long *flags;
+ int ret;
+
+ guard(mutex)(&gpio_shared_lock);
+
+ list_for_each_entry(entry, &gpio_shared_list, list) {
+ if (!device_match_fwnode(&gdev->dev, entry->fwnode))
+ continue;
+
+ if (list_count_nodes(&entry->refs) <= 1)
+ continue;
+
+ flags = &gdev->descs[entry->offset].flags;
+
+ __set_bit(GPIOD_FLAG_SHARED, flags);
+ /*
+ * Shared GPIOs are not requested via the normal path. Make
+ * them inaccessible to anyone even before we register the
+ * chip.
+ */
+ __set_bit(GPIOD_FLAG_REQUESTED, flags);
+
+ pr_debug("GPIO %u owned by %s is shared by multiple consumers\n",
+ entry->offset, gpio_device_get_label(gdev));
+
+ list_for_each_entry(ref, &entry->refs, list) {
+ pr_debug("Setting up a shared GPIO entry for %s\n",
+ fwnode_get_name(ref->fwnode));
+
+ ret = gpio_shared_make_adev(gdev, ref);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+void gpio_device_teardown_shared(struct gpio_device *gdev)
+{
+ struct gpio_shared_entry *entry;
+ struct gpio_shared_ref *ref;
+
+ guard(mutex)(&gpio_shared_lock);
+
+ list_for_each_entry(entry, &gpio_shared_list, list) {
+ if (!device_match_fwnode(&gdev->dev, entry->fwnode))
+ continue;
+
+ list_for_each_entry(ref, &entry->refs, list) {
+ gpiod_remove_lookup_table(ref->lookup);
+ kfree(ref->lookup->table[0].key);
+ kfree(ref->lookup);
+ ref->lookup = NULL;
+ gpio_shared_remove_adev(&ref->adev);
+ }
+ }
+}
+
+static void gpio_shared_release(struct kref *kref)
+{
+ struct gpio_shared_entry *entry =
+ container_of(kref, struct gpio_shared_entry, ref);
+ struct gpio_shared_desc *shared_desc = entry->shared_desc;
+
+ guard(mutex)(&gpio_shared_lock);
+
+ gpio_device_put(shared_desc->desc->gdev);
+ if (shared_desc->can_sleep)
+ mutex_destroy(&shared_desc->mutex);
+ kfree(shared_desc);
+ entry->shared_desc = NULL;
+}
+
+static void gpiod_shared_put(void *data)
+{
+ struct gpio_shared_entry *entry = data;
+
+ lockdep_assert_not_held(&gpio_shared_lock);
+
+ kref_put(&entry->ref, gpio_shared_release);
+}
+
+static struct gpio_shared_desc *
+gpiod_shared_desc_create(struct gpio_shared_entry *entry)
+{
+ struct gpio_shared_desc *shared_desc;
+ struct gpio_device *gdev;
+
+ shared_desc = kzalloc(sizeof(*shared_desc), GFP_KERNEL);
+ if (!shared_desc)
+ return ERR_PTR(-ENOMEM);
+
+ gdev = gpio_device_find_by_fwnode(entry->fwnode);
+ if (!gdev) {
+ kfree(shared_desc);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ shared_desc->desc = &gdev->descs[entry->offset];
+ shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
+ if (shared_desc->can_sleep)
+ mutex_init(&shared_desc->mutex);
+ else
+ spin_lock_init(&shared_desc->spinlock);
+
+ return shared_desc;
+}
+
+static struct gpio_shared_entry *gpiod_shared_find(struct auxiliary_device *adev)
+{
+ struct gpio_shared_desc *shared_desc;
+ struct gpio_shared_entry *entry;
+ struct gpio_shared_ref *ref;
+
+ guard(mutex)(&gpio_shared_lock);
+
+ list_for_each_entry(entry, &gpio_shared_list, list) {
+ list_for_each_entry(ref, &entry->refs, list) {
+ if (adev != &ref->adev)
+ continue;
+
+ if (entry->shared_desc) {
+ kref_get(&entry->ref);
+ return entry;
+ }
+
+ shared_desc = gpiod_shared_desc_create(entry);
+ if (IS_ERR(shared_desc))
+ return ERR_CAST(shared_desc);
+
+ kref_init(&entry->ref);
+ entry->shared_desc = shared_desc;
+
+ pr_debug("Device %s acquired a reference to the shared GPIO %u owned by %s\n",
+ dev_name(&adev->dev), gpiod_hwgpio(shared_desc->desc),
+ gpio_device_get_label(shared_desc->desc->gdev));
+
+
+ return entry;
+ }
+ }
+
+ return ERR_PTR(-ENOENT);
+}
+
+struct gpio_shared_desc *devm_gpiod_shared_get(struct device *dev)
+{
+ struct gpio_shared_entry *entry;
+ int ret;
+
+ entry = gpiod_shared_find(to_auxiliary_dev(dev));
+ if (IS_ERR(entry))
+ return ERR_CAST(entry);
+
+ ret = devm_add_action_or_reset(dev, gpiod_shared_put, entry);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return entry->shared_desc;
+}
+EXPORT_SYMBOL_GPL(devm_gpiod_shared_get);
+
+static void gpio_shared_drop_ref(struct gpio_shared_ref *ref)
+{
+ list_del(&ref->list);
+ kfree(ref->con_id);
+ ida_free(&gpio_shared_ida, ref->dev_id);
+ fwnode_handle_put(ref->fwnode);
+ kfree(ref);
+}
+
+static void gpio_shared_drop_entry(struct gpio_shared_entry *entry)
+{
+ list_del(&entry->list);
+ fwnode_handle_put(entry->fwnode);
+ kfree(entry);
+}
+
+/*
+ * This is only called if gpio_shared_init() fails so it's in fact __init and
+ * not __exit.
+ */
+static void __init gpio_shared_teardown(void)
+{
+ struct gpio_shared_entry *entry, *epos;
+ struct gpio_shared_ref *ref, *rpos;
+
+ list_for_each_entry_safe(entry, epos, &gpio_shared_list, list) {
+ list_for_each_entry_safe(ref, rpos, &entry->refs, list)
+ gpio_shared_drop_ref(ref);
+
+ gpio_shared_drop_entry(entry);
+ }
+}
+
+static void gpio_shared_free_exclusive(void)
+{
+ struct gpio_shared_entry *entry, *epos;
+
+ list_for_each_entry_safe(entry, epos, &gpio_shared_list, list) {
+ if (list_count_nodes(&entry->refs) > 1)
+ continue;
+
+ gpio_shared_drop_ref(list_first_entry(&entry->refs,
+ struct gpio_shared_ref,
+ list));
+ gpio_shared_drop_entry(entry);
+ }
+}
+
+static int __init gpio_shared_init(void)
+{
+ int ret;
+
+ /* Right now, we only support OF-based systems. */
+ ret = gpio_shared_of_scan();
+ if (ret) {
+ gpio_shared_teardown();
+ pr_err("Failed to scan OF nodes for shared GPIOs: %d\n", ret);
+ return ret;
+ }
+
+ gpio_shared_free_exclusive();
+
+ pr_debug("Finished scanning firmware nodes for shared GPIOs\n");
+ return 0;
+}
+postcore_initcall(gpio_shared_init);
diff --git a/drivers/gpio/gpiolib-shared.h b/drivers/gpio/gpiolib-shared.h
new file mode 100644
index 0000000000000000000000000000000000000000..667dbdff3585066b7cbe2ebe476725fe7d683d84
--- /dev/null
+++ b/drivers/gpio/gpiolib-shared.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __LINUX_GPIO_SHARED_H
+#define __LINUX_GPIO_SHARED_H
+
+#include <linux/cleanup.h>
+#include <linux/lockdep.h>
+#include <linux/mutex.h>
+#include <linux/spinlock.h>
+
+struct gpio_device;
+struct gpio_desc;
+struct device;
+
+#if IS_ENABLED(CONFIG_GPIO_SHARED)
+
+int gpio_device_setup_shared(struct gpio_device *gdev);
+void gpio_device_teardown_shared(struct gpio_device *gdev);
+int gpio_shared_add_proxy_lookup(struct device *consumer, unsigned long lflags);
+
+#else
+
+static inline int gpio_device_setup_shared(struct gpio_device *gdev)
+{
+ return 0;
+}
+
+static inline void gpio_device_teardown_shared(struct gpio_device *gdev) { }
+
+static inline int gpio_shared_add_proxy_lookup(struct device *consumer,
+ unsigned long lflags)
+{
+ return 0;
+}
+
+#endif /* CONFIG_GPIO_SHARED */
+
+struct gpio_shared_desc {
+ struct gpio_desc *desc;
+ bool can_sleep;
+ unsigned long cfg;
+ unsigned int usecnt;
+ unsigned int highcnt;
+ union {
+ struct mutex mutex;
+ spinlock_t spinlock;
+ };
+};
+
+struct gpio_shared_desc *devm_gpiod_shared_get(struct device *dev);
+
+DEFINE_LOCK_GUARD_1(gpio_shared_desc_lock, struct gpio_shared_desc,
+ if (_T->lock->can_sleep)
+ mutex_lock(&_T->lock->mutex);
+ else
+ spin_lock_irqsave(&_T->lock->spinlock, _T->flags),
+ if (_T->lock->can_sleep)
+ mutex_unlock(&_T->lock->mutex);
+ else
+ spin_unlock_irqrestore(&_T->lock->spinlock, _T->flags),
+ unsigned long flags)
+
+static inline void gpio_shared_lockdep_assert(struct gpio_shared_desc *shared_desc)
+{
+ if (shared_desc->can_sleep)
+ lockdep_assert_held(&shared_desc->mutex);
+ else
+ lockdep_assert_held(&shared_desc->spinlock);
+}
+
+#endif /* __LINUX_GPIO_SHARED_H */
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 04/10] gpio: shared-proxy: implement the shared GPIO proxy driver
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (2 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 05/10] gpiolib: support shared GPIOs in core subsystem code Bartosz Golaszewski
` (12 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add a virtual GPIO proxy driver which arbitrates access to a single
shared GPIO by multiple users. It works together with the core shared
GPIO support from GPIOLIB and functions by acquiring a reference to a
shared GPIO descriptor exposed by gpiolib-shared and making sure that
the state of the GPIO stays consistent.
In general: if there's only one user at the moment: allow it to do
anything as if this was a normal GPIO (in essence: just propagate calls
to the underlying real hardware driver). If there are more users: don't
allow to change the direction set by the initial user, allow to change
configuration options but warn about possible conflicts and finally:
treat the output-high value as a reference counted, logical "GPIO
enabled" setting, meaning: the GPIO value is set to high when the first
user requests it to be high and back to low once the last user stops
"voting" for high.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-shared-proxy.c | 333 +++++++++++++++++++++++++++++++++++++++
3 files changed, 343 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index f90b4d3e77f7cab46525b7adfcf114a21d276678..f910c20f0d5d7771f7f8f3d52ced7bce413d24f1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -2025,6 +2025,15 @@ config GPIO_SIM
This enables the GPIO simulator - a configfs-based GPIO testing
driver.
+config GPIO_SHARED_PROXY
+ tristate "Proxy driver for non-exclusive GPIOs"
+ default m
+ depends on GPIO_SHARED || COMPILE_TEST
+ select AUXILIARY_BUS
+ help
+ This enables the GPIO shared proxy driver - an abstraction layer
+ for GPIO pins that are shared by multiple devices.
+
endmenu
menu "GPIO Debugging utilities"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 48f309c764e3286c23dbe604be933f7180f0b89a..2421a8fd3733e0b06c2581262aaa9cd629f66c7d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
obj-$(CONFIG_GPIO_SCH) += gpio-sch.o
+obj-$(CONFIG_GPIO_SHARED_PROXY) += gpio-shared-proxy.o
obj-$(CONFIG_GPIO_SIFIVE) += gpio-sifive.o
obj-$(CONFIG_GPIO_SIM) += gpio-sim.o
obj-$(CONFIG_GPIO_SIOX) += gpio-siox.o
diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
new file mode 100644
index 0000000000000000000000000000000000000000..3ef2c40ed15229074052eda93b6ee56f0a2bfb72
--- /dev/null
+++ b/drivers/gpio/gpio-shared-proxy.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 Linaro Ltd.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/cleanup.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/string_choices.h>
+#include <linux/types.h>
+
+#include "gpiolib-shared.h"
+
+struct gpio_shared_proxy_data {
+ struct gpio_chip gc;
+ struct gpio_shared_desc *shared_desc;
+ struct device *dev;
+ bool voted_high;
+};
+
+static int
+gpio_shared_proxy_set_unlocked(struct gpio_shared_proxy_data *proxy,
+ int (*set_func)(struct gpio_desc *desc, int value),
+ int value)
+{
+ struct gpio_shared_desc *shared_desc = proxy->shared_desc;
+ struct gpio_desc *desc = shared_desc->desc;
+ int ret = 0;
+
+ gpio_shared_lockdep_assert(shared_desc);
+
+ if (value) {
+ /* User wants to set value to high. */
+ if (proxy->voted_high)
+ /* Already voted for high, nothing to do. */
+ goto out;
+
+ /* Haven't voted for high yet. */
+ if (!shared_desc->highcnt) {
+ /*
+ * Current value is low, need to actually set value
+ * to high.
+ */
+ ret = set_func(desc, 1);
+ if (ret)
+ goto out;
+ }
+
+ shared_desc->highcnt++;
+ proxy->voted_high = true;
+
+ goto out;
+ }
+
+ /* Desired value is low. */
+ if (!proxy->voted_high)
+ /* We didn't vote for high, nothing to do. */
+ goto out;
+
+ /* We previously voted for high. */
+ if (shared_desc->highcnt == 1) {
+ /* This is the last remaining vote for high, set value to low. */
+ ret = set_func(desc, 0);
+ if (ret)
+ goto out;
+ }
+
+ shared_desc->highcnt--;
+ proxy->voted_high = false;
+
+out:
+ if (shared_desc->highcnt)
+ dev_dbg(proxy->dev,
+ "Voted for value '%s', effective value is 'high', number of votes for 'high': %u\n",
+ str_high_low(value), shared_desc->highcnt);
+ else
+ dev_dbg(proxy->dev, "Voted for value 'low', effective value is 'low'\n");
+
+ return ret;
+}
+
+static int gpio_shared_proxy_request(struct gpio_chip *gc, unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+ struct gpio_shared_desc *shared_desc = proxy->shared_desc;
+
+ guard(gpio_shared_desc_lock)(shared_desc);
+
+ proxy->shared_desc->usecnt++;
+
+ dev_dbg(proxy->dev, "Shared GPIO requested, number of users: %u\n",
+ proxy->shared_desc->usecnt);
+
+ return 0;
+}
+
+static void gpio_shared_proxy_free(struct gpio_chip *gc, unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+ struct gpio_shared_desc *shared_desc = proxy->shared_desc;
+
+ guard(gpio_shared_desc_lock)(shared_desc);
+
+ proxy->shared_desc->usecnt--;
+
+ dev_dbg(proxy->dev, "Shared GPIO freed, number of users: %u\n",
+ proxy->shared_desc->usecnt);
+}
+
+static int gpio_shared_proxy_set_config(struct gpio_chip *gc,
+ unsigned int offset, unsigned long cfg)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+ struct gpio_shared_desc *shared_desc = proxy->shared_desc;
+ struct gpio_desc *desc = shared_desc->desc;
+ int ret;
+
+ guard(gpio_shared_desc_lock)(shared_desc);
+
+ if (shared_desc->usecnt > 1) {
+ if (shared_desc->cfg != cfg) {
+ dev_dbg(proxy->dev,
+ "Shared GPIO's configuration already set, accepting changes but users may conflict!!\n");
+ } else {
+ dev_dbg(proxy->dev, "Equal config requested, nothing to do\n");
+ return 0;
+ }
+ }
+
+ ret = gpiod_set_config(desc, cfg);
+ if (ret && ret != -ENOTSUPP)
+ return ret;
+
+ shared_desc->cfg = cfg;
+ return 0;
+}
+
+static int gpio_shared_proxy_direction_input(struct gpio_chip *gc,
+ unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+ struct gpio_shared_desc *shared_desc = proxy->shared_desc;
+ struct gpio_desc *desc = shared_desc->desc;
+ int dir;
+
+ guard(gpio_shared_desc_lock)(shared_desc);
+
+ if (shared_desc->usecnt == 1) {
+ dev_dbg(proxy->dev,
+ "Only one user of this shared GPIO, allowing to set direction to input\n");
+
+ return gpiod_direction_input(desc);
+ }
+
+ dir = gpiod_get_direction(desc);
+ if (dir < 0)
+ return dir;
+
+ if (dir == GPIO_LINE_DIRECTION_OUT) {
+ dev_dbg(proxy->dev,
+ "Shared GPIO's direction already set to output, refusing to change\n");
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+static int gpio_shared_proxy_direction_output(struct gpio_chip *gc,
+ unsigned int offset, int value)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+ struct gpio_shared_desc *shared_desc = proxy->shared_desc;
+ struct gpio_desc *desc = shared_desc->desc;
+ int ret, dir;
+
+ guard(gpio_shared_desc_lock)(shared_desc);
+
+ if (shared_desc->usecnt == 1) {
+ dev_dbg(proxy->dev,
+ "Only one user of this shared GPIO, allowing to set direction to output with value '%s'\n",
+ str_high_low(value));
+
+ ret = gpiod_direction_output(desc, value);
+ if (ret)
+ return ret;
+
+ if (value) {
+ proxy->voted_high = true;
+ shared_desc->highcnt = 1;
+ } else {
+ proxy->voted_high = false;
+ shared_desc->highcnt = 0;
+ }
+
+ return 0;
+ }
+
+ dir = gpiod_get_direction(desc);
+ if (dir < 0)
+ return dir;
+
+ if (dir == GPIO_LINE_DIRECTION_IN) {
+ dev_dbg(proxy->dev,
+ "Shared GPIO's direction already set to input, refusing to change\n");
+ return -EPERM;
+ }
+
+ return gpio_shared_proxy_set_unlocked(proxy, gpiod_direction_output, value);
+}
+
+static int gpio_shared_proxy_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+
+ return gpiod_get_value(proxy->shared_desc->desc);
+}
+
+static int gpio_shared_proxy_get_cansleep(struct gpio_chip *gc,
+ unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+
+ return gpiod_get_value_cansleep(proxy->shared_desc->desc);
+}
+
+static int gpio_shared_proxy_do_set(struct gpio_shared_proxy_data *proxy,
+ int (*set_func)(struct gpio_desc *desc, int value),
+ int value)
+{
+ guard(gpio_shared_desc_lock)(proxy->shared_desc);
+
+ return gpio_shared_proxy_set_unlocked(proxy, set_func, value);
+}
+
+static int gpio_shared_proxy_set(struct gpio_chip *gc, unsigned int offset,
+ int value)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+
+ return gpio_shared_proxy_do_set(proxy, gpiod_set_value, value);
+}
+
+static int gpio_shared_proxy_set_cansleep(struct gpio_chip *gc,
+ unsigned int offset, int value)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+
+ return gpio_shared_proxy_do_set(proxy, gpiod_set_value_cansleep, value);
+}
+
+static int gpio_shared_proxy_get_direction(struct gpio_chip *gc,
+ unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+
+ return gpiod_get_direction(proxy->shared_desc->desc);
+}
+
+static int gpio_shared_proxy_to_irq(struct gpio_chip *gc, unsigned int offset)
+{
+ struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
+
+ return gpiod_to_irq(proxy->shared_desc->desc);
+}
+
+static int gpio_shared_proxy_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
+{
+ struct gpio_shared_proxy_data *proxy;
+ struct gpio_shared_desc *shared_desc;
+ struct device *dev = &adev->dev;
+ struct gpio_chip *gc;
+
+ shared_desc = devm_gpiod_shared_get(dev);
+ if (IS_ERR(shared_desc))
+ return PTR_ERR(shared_desc);
+
+ proxy = devm_kzalloc(dev, sizeof(*proxy), GFP_KERNEL);
+ if (!proxy)
+ return -ENOMEM;
+
+ proxy->shared_desc = shared_desc;
+ proxy->dev = dev;
+
+ gc = &proxy->gc;
+ gc->base = -1;
+ gc->ngpio = 1;
+ gc->label = dev_name(dev);
+ gc->parent = dev;
+ gc->owner = THIS_MODULE;
+ gc->can_sleep = shared_desc->can_sleep;
+
+ gc->request = gpio_shared_proxy_request;
+ gc->free = gpio_shared_proxy_free;
+ gc->set_config = gpio_shared_proxy_set_config;
+ gc->direction_input = gpio_shared_proxy_direction_input;
+ gc->direction_output = gpio_shared_proxy_direction_output;
+ if (gc->can_sleep) {
+ gc->set = gpio_shared_proxy_set_cansleep;
+ gc->get = gpio_shared_proxy_get_cansleep;
+ } else {
+ gc->set = gpio_shared_proxy_set;
+ gc->get = gpio_shared_proxy_get;
+ }
+ gc->get_direction = gpio_shared_proxy_get_direction;
+ gc->to_irq = gpio_shared_proxy_to_irq;
+
+ return devm_gpiochip_add_data(dev, &proxy->gc, proxy);
+}
+
+static const struct auxiliary_device_id gpio_shared_proxy_id_table[] = {
+ { .name = "gpiolib_shared.proxy" },
+ {},
+};
+MODULE_DEVICE_TABLE(auxiliary, gpio_shared_proxy_id_table);
+
+static struct auxiliary_driver gpio_shared_proxy_driver = {
+ .driver = {
+ .name = "gpio-shared-proxy",
+ },
+ .probe = gpio_shared_proxy_probe,
+ .id_table = gpio_shared_proxy_id_table,
+};
+module_auxiliary_driver(gpio_shared_proxy_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("Shared GPIO mux driver.");
+MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 05/10] gpiolib: support shared GPIOs in core subsystem code
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (3 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 04/10] gpio: shared-proxy: implement the shared GPIO proxy driver Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 06/10] gpio: provide gpiod_is_shared() Bartosz Golaszewski
` (11 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As the final step in adding official support for shared GPIOs, enable
the previously added elements in core GPIO subsystem code. Set-up shared
GPIOs when adding a GPIO chip, tear it down on removal and check if a
GPIO descriptor looked up during the firmware-node stage is shared and
fall-back to machine lookup in this case.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/gpiolib.c | 50 +++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 3659acc600d9622d5d2baeb055ac083556f344a9..c59fe05c838e073b4bc99c4a7667cb1ff40c26b4 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -37,6 +37,7 @@
#include "gpiolib-acpi.h"
#include "gpiolib-cdev.h"
#include "gpiolib-of.h"
+#include "gpiolib-shared.h"
#include "gpiolib-swnode.h"
#include "gpiolib-sysfs.h"
#include "gpiolib.h"
@@ -1213,6 +1214,10 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
if (ret)
goto err_remove_irqchip_mask;
+ ret = gpio_device_setup_shared(gdev);
+ if (ret)
+ goto err_remove_irqchip;
+
/*
* By first adding the chardev, and then adding the device,
* we get a device node entry in sysfs under
@@ -1224,10 +1229,13 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
if (gpiolib_initialized) {
ret = gpiochip_setup_dev(gdev);
if (ret)
- goto err_remove_irqchip;
+ goto err_teardown_shared;
}
+
return 0;
+err_teardown_shared:
+ gpio_device_teardown_shared(gdev);
err_remove_irqchip:
gpiochip_irqchip_remove(gc);
err_remove_irqchip_mask:
@@ -1296,6 +1304,7 @@ void gpiochip_remove(struct gpio_chip *gc)
/* Numb the device, cancelling all outstanding operations */
rcu_assign_pointer(gdev->chip, NULL);
synchronize_srcu(&gdev->srcu);
+ gpio_device_teardown_shared(gdev);
gpiochip_irqchip_remove(gc);
acpi_gpiochip_remove(gc);
of_gpiochip_remove(gc);
@@ -4659,11 +4668,29 @@ struct gpio_desc *gpiod_find_and_request(struct device *consumer,
scoped_guard(srcu, &gpio_devices_srcu) {
desc = gpiod_fwnode_lookup(fwnode, consumer, con_id, idx,
&flags, &lookupflags);
+ if (!IS_ERR_OR_NULL(desc) &&
+ test_bit(GPIOD_FLAG_SHARED, &desc->flags)) {
+ /*
+ * We're dealing with a GPIO shared by multiple
+ * consumers. This is the moment to add the machine
+ * lookup table for the proxy device as previously
+ * we only knew the consumer's fwnode.
+ */
+ ret = gpio_shared_add_proxy_lookup(consumer, lookupflags);
+ if (ret)
+ return ERR_PTR(ret);
+
+ /* Trigger platform lookup for shared GPIO proxy. */
+ desc = ERR_PTR(-ENOENT);
+ /* Trigger it even for fwnode-only gpiod_get(). */
+ platform_lookup_allowed = true;
+ }
+
if (gpiod_not_found(desc) && platform_lookup_allowed) {
/*
* Either we are not using DT or ACPI, or their lookup
- * did not return a result. In that case, use platform
- * lookup as a fallback.
+ * did not return a result or this is a shared GPIO. In
+ * that case, use platform lookup as a fallback.
*/
dev_dbg(consumer,
"using lookup tables for GPIO lookup\n");
@@ -4686,14 +4713,19 @@ struct gpio_desc *gpiod_find_and_request(struct device *consumer,
return ERR_PTR(ret);
/*
- * This happens when there are several consumers for
- * the same GPIO line: we just return here without
- * further initialization. It is a bit of a hack.
- * This is necessary to support fixed regulators.
+ * This happens when there are several consumers for the same
+ * GPIO line: we just return here without further
+ * initialization. It's a hack introduced long ago to support
+ * fixed regulators. We now have a better solution with
+ * automated scanning where affected platforms just need to
+ * select the provided Kconfig option.
*
- * FIXME: Make this more sane and safe.
+ * FIXME: Remove the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag after
+ * making sure all platforms use the new mechanism.
*/
- dev_info(consumer, "nonexclusive access to GPIO for %s\n", name);
+ dev_info(consumer,
+ "nonexclusive access to GPIO for %s, consider updating your code to using gpio-shared-proxy\n",
+ name);
return desc;
}
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 06/10] gpio: provide gpiod_is_shared()
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (4 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 05/10] gpiolib: support shared GPIOs in core subsystem code Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
` (10 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Provide an interface allowing consumers to check if a GPIO descriptor
represents a GPIO that can potentially be shared by multiple consumers
at the same time. This is exposed to allow subsystems that already
work around the limitations of the current non-exclusive GPIO handling
in some ways, to gradually convert to relying on the new shared GPIO
feature of GPIOLIB.
Extend the gpiolib-shared module to mark the GPIO shared proxy
descriptors with a flag checked by the new interface.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/gpiolib-shared.c | 18 ++++++++++++++++++
drivers/gpio/gpiolib.c | 20 ++++++++++++++++++++
drivers/gpio/gpiolib.h | 1 +
include/linux/gpio/consumer.h | 9 +++++++++
4 files changed, 48 insertions(+)
diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
index 56b9b03cbb6dbcdf095a656fc36ff321770035da..c22eaf05eef23a7f5f111708c3db9412c4c30231 100644
--- a/drivers/gpio/gpiolib-shared.c
+++ b/drivers/gpio/gpiolib-shared.c
@@ -314,6 +314,24 @@ int gpio_device_setup_shared(struct gpio_device *gdev)
guard(mutex)(&gpio_shared_lock);
+ list_for_each_entry(entry, &gpio_shared_list, list) {
+ list_for_each_entry(ref, &entry->refs, list) {
+ if (gdev->dev.parent == &ref->adev.dev) {
+ /*
+ * This is a shared GPIO proxy. Mark its
+ * descriptor as such and return here.
+ */
+ __set_bit(GPIOD_FLAG_SHARED_PROXY,
+ &gdev->descs[0].flags);
+ return 0;
+ }
+ }
+ }
+
+ /*
+ * This is not a shared GPIO proxy but it still may be the device
+ * exposing shared pins. Find them and create the proxy devices.
+ */
list_for_each_entry(entry, &gpio_shared_list, list) {
if (!device_match_fwnode(&gdev->dev, entry->fwnode))
continue;
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c59fe05c838e073b4bc99c4a7667cb1ff40c26b4..91e0c384f34ae5c0ed61ccd3a978685d4f72e867 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3997,6 +3997,26 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)
}
EXPORT_SYMBOL_GPL(gpiod_set_consumer_name);
+/**
+ * gpiod_is_shared() - check if this GPIO can be shared by multiple consumers
+ * @desc: GPIO to inspect
+ *
+ * Returns:
+ * True if this GPIO can be shared by multiple consumers at once. False if it's
+ * a regular, exclusive GPIO.
+ *
+ * Note:
+ * This function returning true does not mean that this GPIO is currently being
+ * shared. It means the GPIO core has registered the fact that the firmware
+ * configuration indicates that it can be shared by multiple consumers and is
+ * in charge of arbitrating the access.
+ */
+bool gpiod_is_shared(const struct gpio_desc *desc)
+{
+ return test_bit(GPIOD_FLAG_SHARED_PROXY, &desc->flags);
+}
+EXPORT_SYMBOL_GPL(gpiod_is_shared);
+
/**
* gpiod_to_irq() - return the IRQ corresponding to a GPIO
* @desc: gpio whose IRQ will be returned (already requested)
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index c9de4bb10584206f4888c0f28468762a3680aae6..77f6f2936dc263a67b31a38799a841128a57603a 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -205,6 +205,7 @@ struct gpio_desc {
#define GPIOD_FLAG_EVENT_CLOCK_REALTIME 18 /* GPIO CDEV reports REALTIME timestamps in events */
#define GPIOD_FLAG_EVENT_CLOCK_HTE 19 /* GPIO CDEV reports hardware timestamps in events */
#define GPIOD_FLAG_SHARED 20 /* GPIO is shared by multiple consumers */
+#define GPIOD_FLAG_SHARED_PROXY 21 /* GPIO is a virtual proxy to a physically shared pin. */
/* Connection label */
struct gpio_desc_label __rcu *label;
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 994d46874d560416175c9099e18180237839bd4c..cafeb7a40ad1c25aeb7deaf598410d5f2f004a82 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -167,6 +167,8 @@ int gpiod_cansleep(const struct gpio_desc *desc);
int gpiod_to_irq(const struct gpio_desc *desc);
int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name);
+bool gpiod_is_shared(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);
@@ -522,6 +524,13 @@ static inline int gpiod_set_consumer_name(struct gpio_desc *desc,
return -EINVAL;
}
+static inline bool gpiod_is_shared(const struct gpio_desc *desc)
+{
+ /* GPIO can never have been requested */
+ WARN_ON(desc);
+ return false;
+}
+
static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
{
return NULL;
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (5 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 06/10] gpio: provide gpiod_is_shared() Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-13 8:51 ` Arnd Bergmann
` (4 more replies)
2025-11-12 13:55 ` [PATCH v4 08/10] ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup Bartosz Golaszewski
` (9 subsequent siblings)
16 siblings, 5 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Some qualcomm platforms use shared GPIOs. Enable support for them by
selecting the Kconfig switch provided by GPIOLIB.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -316,6 +316,7 @@ config ARCH_QCOM
select GPIOLIB
select PINCTRL
select HAVE_PWRCTRL if PCI
+ select HAVE_SHARED_GPIOS
help
This enables support for the ARMv8 based Qualcomm chipsets.
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 08/10] ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (6 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 09/10] ASoC: wsa883x: " Bartosz Golaszewski
` (8 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This driver is only used on Qualcomm platforms which now select
HAVE_SHARED_GPIOS so this flag can be dropped.
Reviewed-and-tested-by: Alexey Klimov <alexey.klimov@linaro.org> # RB3
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
sound/soc/codecs/wsa881x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wsa881x.c b/sound/soc/codecs/wsa881x.c
index e249de7f91d91f8c7f1e7020086cc65c71e64c5e..d7aca6567c2de1ec36e9f36aa82463bdbf3be27e 100644
--- a/sound/soc/codecs/wsa881x.c
+++ b/sound/soc/codecs/wsa881x.c
@@ -1112,8 +1112,7 @@ static int wsa881x_probe(struct sdw_slave *pdev,
if (!wsa881x)
return -ENOMEM;
- wsa881x->sd_n = devm_gpiod_get_optional(dev, "powerdown",
- GPIOD_FLAGS_BIT_NONEXCLUSIVE);
+ wsa881x->sd_n = devm_gpiod_get_optional(dev, "powerdown", 0);
if (IS_ERR(wsa881x->sd_n))
return dev_err_probe(dev, PTR_ERR(wsa881x->sd_n),
"Shutdown Control GPIO not found\n");
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 09/10] ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (7 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 08/10] ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 10/10] regulator: make the subsystem aware of shared GPIOs Bartosz Golaszewski
` (7 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This driver is only used on Qualcomm platforms which now select
HAVE_SHARED_GPIOS so this flag can be dropped.
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
sound/soc/codecs/wsa883x.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/wsa883x.c b/sound/soc/codecs/wsa883x.c
index 96dd66c4b88dea34f1f24bed4d5ab66d3e2249ae..c3046e260cb958296a41b78b545f1ac7f377a968 100644
--- a/sound/soc/codecs/wsa883x.c
+++ b/sound/soc/codecs/wsa883x.c
@@ -1572,13 +1572,10 @@ static int wsa883x_get_reset(struct device *dev, struct wsa883x_priv *wsa883x)
if (IS_ERR(wsa883x->sd_reset))
return dev_err_probe(dev, PTR_ERR(wsa883x->sd_reset),
"Failed to get reset\n");
- /*
- * if sd_reset: NULL, so use the backwards compatible way for powerdown-gpios,
- * which does not handle sharing GPIO properly.
- */
+
+ /* if sd_reset: NULL, so use the backwards compatible way for powerdown-gpios */
if (!wsa883x->sd_reset) {
wsa883x->sd_n = devm_gpiod_get_optional(dev, "powerdown",
- GPIOD_FLAGS_BIT_NONEXCLUSIVE |
GPIOD_OUT_HIGH);
if (IS_ERR(wsa883x->sd_n))
return dev_err_probe(dev, PTR_ERR(wsa883x->sd_n),
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v4 10/10] regulator: make the subsystem aware of shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (8 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 09/10] ASoC: wsa883x: " Bartosz Golaszewski
@ 2025-11-12 13:55 ` Bartosz Golaszewski
2025-11-17 9:20 ` (subset) [PATCH v4 00/10] gpio: improve support for " Bartosz Golaszewski
` (6 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-12 13:55 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Bartosz Golaszewski,
Catalin Marinas, Will Deacon, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Alexey Klimov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
GPIOLIB is now aware of shared GPIOs and - for platforms where access to
such pins is managed internally - we don't need to keep track of the
enable count.
Once all users in the kernel switch to using the new mechanism, we'll be
able to drop the internal counting of users from the regulator code.
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/regulator/core.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2eab56df042e6b05abf0989f425dc161c7b0e66d..53b2b2d3746f9f2419234912d49bd8b4f21a893d 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2742,6 +2742,13 @@ static int regulator_ena_gpio_request(struct regulator_dev *rdev,
mutex_lock(®ulator_list_mutex);
+ if (gpiod_is_shared(gpiod))
+ /*
+ * The sharing of this GPIO pin is managed internally by
+ * GPIOLIB. We don't need to keep track of its enable count.
+ */
+ goto skip_compare;
+
list_for_each_entry(pin, ®ulator_ena_gpio_list, list) {
if (gpiod_is_equal(pin->gpiod, gpiod)) {
rdev_dbg(rdev, "GPIO is already used\n");
@@ -2754,6 +2761,7 @@ static int regulator_ena_gpio_request(struct regulator_dev *rdev,
return -ENOMEM;
}
+skip_compare:
pin = new_pin;
new_pin = NULL;
--
2.51.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
@ 2025-11-13 8:51 ` Arnd Bergmann
2025-11-14 19:40 ` Bjorn Andersson
` (3 subsequent siblings)
4 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2025-11-13 8:51 UTC (permalink / raw)
To: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, open list:GPIO SUBSYSTEM,
linux-arm-kernel, linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Nov 12, 2025, at 14:55, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Some qualcomm platforms use shared GPIOs. Enable support for them by
> selecting the Kconfig switch provided by GPIOLIB.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Please take this through the gpio and asoc trees for simplicity.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
2025-11-13 8:51 ` Arnd Bergmann
@ 2025-11-14 19:40 ` Bjorn Andersson
2025-11-18 14:06 ` Mark Brown
` (2 subsequent siblings)
4 siblings, 0 replies; 71+ messages in thread
From: Bjorn Andersson @ 2025-11-14 19:40 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Konrad Dybcio, linux-hardening,
linux-kernel, linux-gpio, linux-arm-kernel, linux-sound,
linux-arm-msm, Bartosz Golaszewski
On Wed, Nov 12, 2025 at 02:55:36PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Some qualcomm platforms use shared GPIOs. Enable support for them by
> selecting the Kconfig switch provided by GPIOLIB.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Regards,
Bjorn
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -316,6 +316,7 @@ config ARCH_QCOM
> select GPIOLIB
> select PINCTRL
> select HAVE_PWRCTRL if PCI
> + select HAVE_SHARED_GPIOS
> help
> This enables support for the ARMv8 based Qualcomm chipsets.
>
>
> --
> 2.51.0
>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: (subset) [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (9 preceding siblings ...)
2025-11-12 13:55 ` [PATCH v4 10/10] regulator: make the subsystem aware of shared GPIOs Bartosz Golaszewski
@ 2025-11-17 9:20 ` Bartosz Golaszewski
2025-11-18 11:15 ` Geert Uytterhoeven
` (5 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-17 9:20 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
Bartosz Golaszewski
Cc: Bartosz Golaszewski, linux-hardening, linux-kernel, linux-gpio,
linux-arm-kernel, linux-sound, linux-arm-msm
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
On Wed, 12 Nov 2025 14:55:29 +0100, Bartosz Golaszewski wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> [...]
Applied, thanks!
[01/10] string: provide strends()
https://git.kernel.org/brgl/linux/c/197b3f3c70d61ff1c7ca24f66d567e06fe8ed3d9
[02/10] gpiolib: define GPIOD_FLAG_SHARED
https://git.kernel.org/brgl/linux/c/d4340ff75eaa083f261e16d49f13191236bfad06
[03/10] gpiolib: implement low-level, shared GPIO support
https://git.kernel.org/brgl/linux/c/a060b8c511abb0997381b397e52149a5e3e5259a
[04/10] gpio: shared-proxy: implement the shared GPIO proxy driver
https://git.kernel.org/brgl/linux/c/e992d54c6f970b382ffeacd7c88f68b94a3c6caf
[05/10] gpiolib: support shared GPIOs in core subsystem code
https://git.kernel.org/brgl/linux/c/1e4f6db614a310cc34d07ffbf031c76ea9581bcf
[06/10] gpio: provide gpiod_is_shared()
https://git.kernel.org/brgl/linux/c/eb374f764a7012eda28019266a6d9191670c4fa5
[07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
https://git.kernel.org/brgl/linux/c/e511d484cbe44fe48a1b9f621f6a947c72503f9e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 01/10] string: provide strends()
2025-11-12 13:55 ` [PATCH v4 01/10] string: provide strends() Bartosz Golaszewski
@ 2025-11-17 20:33 ` Kees Cook
2025-11-18 9:47 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Kees Cook @ 2025-11-17 20:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mika Westerberg, Dmitry Torokhov, Andrew Morton, Linus Walleij,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Nov 12, 2025 at 02:55:30PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Implement a function for checking if a string ends with a different
> string and add its kunit test cases.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> include/linux/string.h | 18 ++++++++++++++++++
> lib/tests/string_kunit.c | 13 +++++++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index fdd3442c6bcbd786e177b6e87358e1065a0ffafc..929d05d1247c76eb9011fe34250b487834b2d3c9 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -562,4 +562,22 @@ static inline bool strstarts(const char *str, const char *prefix)
> return strncmp(str, prefix, strlen(prefix)) == 0;
> }
>
> +/**
> + * strends - Check if a string ends with another string.
> + * @str - NULL-terminated string to check against @suffix
> + * @suffix - NULL-terminated string defining the suffix to look for in @str
> + *
> + * Returns:
> + * True if @str ends with @suffix. False in all other cases.
Maybe added "empty strings never match"?
> + */
> +static inline bool strends(const char *str, const char *suffix)
These are required to be non-NULL, so we might want to consider marking
them as such with the "nonnull" attribute. We don't use it much in Linux
yet, but I do see a few places.
e.g.:
static inline bool __attribute__((nonnull(1,2)))
strends(const char *str, const char *suffix)
> +{
> + unsigned int str_len = strlen(str), suffix_len = strlen(suffix);
> +
> + if (str_len < suffix_len)
> + return false;
> +
> + return !(strcmp(str + str_len - suffix_len, suffix));
> +}
We should probably add it to strlen and strcmp as well. :)
> +
> #endif /* _LINUX_STRING_H_ */
> diff --git a/lib/tests/string_kunit.c b/lib/tests/string_kunit.c
> index 0ed7448a26d3aa0fe9e2a6a894d4c49c2c0b86e0..f9a8e557ba7734c9848d58ff986407d8000f52ee 100644
> --- a/lib/tests/string_kunit.c
> +++ b/lib/tests/string_kunit.c
> @@ -602,6 +602,18 @@ static void string_test_memtostr(struct kunit *test)
> KUNIT_EXPECT_EQ(test, dest[7], '\0');
> }
>
> +static void string_test_strends(struct kunit *test)
> +{
> + KUNIT_EXPECT_TRUE(test, strends("foo-bar", "bar"));
> + KUNIT_EXPECT_TRUE(test, strends("foo-bar", "-bar"));
> + KUNIT_EXPECT_TRUE(test, strends("foobar", "foobar"));
> + KUNIT_EXPECT_TRUE(test, strends("foobar", ""));
> + KUNIT_EXPECT_FALSE(test, strends("bar", "foobar"));
> + KUNIT_EXPECT_FALSE(test, strends("", "foo"));
> + KUNIT_EXPECT_FALSE(test, strends("foobar", "ba"));
> + KUNIT_EXPECT_TRUE(test, strends("", ""));
> +}
Thanks for adding tests! :)
> +
> static struct kunit_case string_test_cases[] = {
> KUNIT_CASE(string_test_memset16),
> KUNIT_CASE(string_test_memset32),
> @@ -623,6 +635,7 @@ static struct kunit_case string_test_cases[] = {
> KUNIT_CASE(string_test_strlcat),
> KUNIT_CASE(string_test_strtomem),
> KUNIT_CASE(string_test_memtostr),
> + KUNIT_CASE(string_test_strends),
> {}
> };
>
>
> --
> 2.51.0
>
Reviewed-by: Kees Cook <kees@kernel.org>
--
Kees Cook
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 01/10] string: provide strends()
2025-11-17 20:33 ` Kees Cook
@ 2025-11-18 9:47 ` Bartosz Golaszewski
2025-11-18 10:13 ` Andy Shevchenko
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-18 9:47 UTC (permalink / raw)
To: Kees Cook
Cc: Mika Westerberg, Dmitry Torokhov, Andrew Morton, Linus Walleij,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Mon, Nov 17, 2025 at 9:33 PM Kees Cook <kees@kernel.org> wrote:
>
> On Wed, Nov 12, 2025 at 02:55:30PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Implement a function for checking if a string ends with a different
> > string and add its kunit test cases.
> >
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
Hi Kees!
Thanks for the review. I already queued this for v6.19, so let me
address the issues in a follow-up.
> > include/linux/string.h | 18 ++++++++++++++++++
> > lib/tests/string_kunit.c | 13 +++++++++++++
> > 2 files changed, 31 insertions(+)
> >
> > diff --git a/include/linux/string.h b/include/linux/string.h
> > index fdd3442c6bcbd786e177b6e87358e1065a0ffafc..929d05d1247c76eb9011fe34250b487834b2d3c9 100644
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -562,4 +562,22 @@ static inline bool strstarts(const char *str, const char *prefix)
> > return strncmp(str, prefix, strlen(prefix)) == 0;
> > }
> >
> > +/**
> > + * strends - Check if a string ends with another string.
> > + * @str - NULL-terminated string to check against @suffix
> > + * @suffix - NULL-terminated string defining the suffix to look for in @str
> > + *
> > + * Returns:
> > + * True if @str ends with @suffix. False in all other cases.
>
> Maybe added "empty strings never match"?
>
But they do, please see the test.
> > + */
> > +static inline bool strends(const char *str, const char *suffix)
>
> These are required to be non-NULL, so we might want to consider marking
> them as such with the "nonnull" attribute. We don't use it much in Linux
> yet, but I do see a few places.
>
> e.g.:
>
> static inline bool __attribute__((nonnull(1,2)))
> strends(const char *str, const char *suffix)
>
Ok.
> > +{
> > + unsigned int str_len = strlen(str), suffix_len = strlen(suffix);
> > +
> > + if (str_len < suffix_len)
> > + return false;
> > +
> > + return !(strcmp(str + str_len - suffix_len, suffix));
> > +}
>
> We should probably add it to strlen and strcmp as well. :)
>
Sure but that's outside of the scope of this.
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 01/10] string: provide strends()
2025-11-18 9:47 ` Bartosz Golaszewski
@ 2025-11-18 10:13 ` Andy Shevchenko
0 siblings, 0 replies; 71+ messages in thread
From: Andy Shevchenko @ 2025-11-18 10:13 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Tue, Nov 18, 2025 at 11:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Mon, Nov 17, 2025 at 9:33 PM Kees Cook <kees@kernel.org> wrote:
> > On Wed, Nov 12, 2025 at 02:55:30PM +0100, Bartosz Golaszewski wrote:
...
> > > + * True if @str ends with @suffix. False in all other cases.
> >
> > Maybe added "empty strings never match"?
>
> But they do, please see the test.
I also think that "" == "" (on the same page as Bart). Why should we
make it different?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (10 preceding siblings ...)
2025-11-17 9:20 ` (subset) [PATCH v4 00/10] gpio: improve support for " Bartosz Golaszewski
@ 2025-11-18 11:15 ` Geert Uytterhoeven
2025-11-18 11:55 ` Bartosz Golaszewski
2025-11-18 23:23 ` Linus Walleij
2025-11-20 10:39 ` (subset) " Mark Brown
` (4 subsequent siblings)
16 siblings, 2 replies; 71+ messages in thread
From: Geert Uytterhoeven @ 2025-11-18 11:15 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
Hi Bartosz,
On Wed, 12 Nov 2025 at 15:05, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> Problem statement: GPIOs are implemented as a strictly exclusive
> resource in the kernel but there are lots of platforms on which single
> pin is shared by multiple devices which don't communicate so need some
> way of properly sharing access to a GPIO. What we have now is the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> doesn't do any locking or arbitration of access - it literally just hand
> the same GPIO descriptor to all interested users.
>
> The proposed solution is composed of three major parts: the high-level,
> shared GPIO proxy driver that arbitrates access to the shared pin and
> exposes a regular GPIO chip interface to consumers, a low-level shared
> GPIOLIB module that scans firmware nodes and creates auxiliary devices
> that attach to the proxy driver and finally a set of core GPIOLIB
> changes that plug the former into the GPIO lookup path.
>
> The changes are implemented in a way that allows to seamlessly compile
> out any code related to sharing GPIOs for systems that don't need it.
>
> The practical use-case for this are the powerdown GPIOs shared by
> speakers on Qualcomm db845c platform, however I have also extensively
> tested it using gpio-virtuser on arm64 qemu with various DT
> configurations.
Thanks for your series, part of which is now present linux-next.
IIUIC, this requires the direction of the GPIO to be fixed?
We have a long-standing use-case on various Renesas R-Car Gen3 boards
(e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
key switches. Basically, the GPIO is connected to:
1. A key switch connecting to GND when closed, with pull-up.
2. The gate of an N-channel MOSFET, turning on an LED when driven
high.
Hence:
- In output mode, the LED can be controlled freely,
- In input mode, the LED is on, unless the key is pressed,
- Hence the switch state can only be read when the LED is turned on.
If you have any idea how to handle this, feel free to reply ;-)
Thanks!
[1] https://www.renesas.com/en/document/sch/r-car-starterkit-schematic
(needs a (free) account) Page 15 aka schematic 12.
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 [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-18 11:15 ` Geert Uytterhoeven
@ 2025-11-18 11:55 ` Bartosz Golaszewski
2025-11-18 12:55 ` Geert Uytterhoeven
2025-11-18 23:23 ` Linus Walleij
1 sibling, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-18 11:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
On Tue, Nov 18, 2025 at 12:16 PM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Bartosz,
>
> On Wed, 12 Nov 2025 at 15:05, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> > came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> > this series however impacts Qualcomm platforms. It's a runtime dependency
> > of patches 8 and 9. Would you mind Acking it so that I can take it into
> > an immutable branch that I'll make available to Mark Brown for him to
> > take patches 8-10 through the ASoC and regulator trees for v6.19?
> >
> > Problem statement: GPIOs are implemented as a strictly exclusive
> > resource in the kernel but there are lots of platforms on which single
> > pin is shared by multiple devices which don't communicate so need some
> > way of properly sharing access to a GPIO. What we have now is the
> > GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> > doesn't do any locking or arbitration of access - it literally just hand
> > the same GPIO descriptor to all interested users.
> >
> > The proposed solution is composed of three major parts: the high-level,
> > shared GPIO proxy driver that arbitrates access to the shared pin and
> > exposes a regular GPIO chip interface to consumers, a low-level shared
> > GPIOLIB module that scans firmware nodes and creates auxiliary devices
> > that attach to the proxy driver and finally a set of core GPIOLIB
> > changes that plug the former into the GPIO lookup path.
> >
> > The changes are implemented in a way that allows to seamlessly compile
> > out any code related to sharing GPIOs for systems that don't need it.
> >
> > The practical use-case for this are the powerdown GPIOs shared by
> > speakers on Qualcomm db845c platform, however I have also extensively
> > tested it using gpio-virtuser on arm64 qemu with various DT
> > configurations.
>
> Thanks for your series, part of which is now present linux-next.
> IIUIC, this requires the direction of the GPIO to be fixed?
>
> We have a long-standing use-case on various Renesas R-Car Gen3 boards
> (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
> key switches. Basically, the GPIO is connected to:
> 1. A key switch connecting to GND when closed, with pull-up.
> 2. The gate of an N-channel MOSFET, turning on an LED when driven
> high.
>
> Hence:
> - In output mode, the LED can be controlled freely,
> - In input mode, the LED is on, unless the key is pressed,
> - Hence the switch state can only be read when the LED is turned on.
> If you have any idea how to handle this, feel free to reply ;-)
>
> Thanks!
>
How is this done currently? Even without this series and using the
GPIOD_FLAGS_BIT_NONEXCLUSIVE, the descriptor has a well-defined
direction so it's not possible for two drivers to request it as input
and output simultaneously. The second requester will override the
previous settings.
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-18 11:55 ` Bartosz Golaszewski
@ 2025-11-18 12:55 ` Geert Uytterhoeven
2025-11-18 13:21 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Geert Uytterhoeven @ 2025-11-18 12:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
Hi Bartosz,
On Tue, 18 Nov 2025 at 12:55, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Tue, Nov 18, 2025 at 12:16 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Wed, 12 Nov 2025 at 15:05, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> > > came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> > > this series however impacts Qualcomm platforms. It's a runtime dependency
> > > of patches 8 and 9. Would you mind Acking it so that I can take it into
> > > an immutable branch that I'll make available to Mark Brown for him to
> > > take patches 8-10 through the ASoC and regulator trees for v6.19?
> > >
> > > Problem statement: GPIOs are implemented as a strictly exclusive
> > > resource in the kernel but there are lots of platforms on which single
> > > pin is shared by multiple devices which don't communicate so need some
> > > way of properly sharing access to a GPIO. What we have now is the
> > > GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> > > doesn't do any locking or arbitration of access - it literally just hand
> > > the same GPIO descriptor to all interested users.
> > >
> > > The proposed solution is composed of three major parts: the high-level,
> > > shared GPIO proxy driver that arbitrates access to the shared pin and
> > > exposes a regular GPIO chip interface to consumers, a low-level shared
> > > GPIOLIB module that scans firmware nodes and creates auxiliary devices
> > > that attach to the proxy driver and finally a set of core GPIOLIB
> > > changes that plug the former into the GPIO lookup path.
> > >
> > > The changes are implemented in a way that allows to seamlessly compile
> > > out any code related to sharing GPIOs for systems that don't need it.
> > >
> > > The practical use-case for this are the powerdown GPIOs shared by
> > > speakers on Qualcomm db845c platform, however I have also extensively
> > > tested it using gpio-virtuser on arm64 qemu with various DT
> > > configurations.
> >
> > Thanks for your series, part of which is now present linux-next.
> > IIUIC, this requires the direction of the GPIO to be fixed?
> >
> > We have a long-standing use-case on various Renesas R-Car Gen3 boards
> > (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
> > key switches. Basically, the GPIO is connected to:
> > 1. A key switch connecting to GND when closed, with pull-up.
> > 2. The gate of an N-channel MOSFET, turning on an LED when driven
> > high.
> >
> > Hence:
> > - In output mode, the LED can be controlled freely,
> > - In input mode, the LED is on, unless the key is pressed,
> > - Hence the switch state can only be read when the LED is turned on.
> > If you have any idea how to handle this, feel free to reply ;-)
>
> How is this done currently? Even without this series and using the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE, the descriptor has a well-defined
> direction so it's not possible for two drivers to request it as input
> and output simultaneously. The second requester will override the
> previous settings.
We do not handle it yet:
- arch/arm64/boot/dts/renesas/salvator-common.dtsi describes only
the keys (key-[a-c]),
- arch/arm64/boot/dts/renesas/ulcb.dtsi describes the first key
(key-1), and the others as LEDs (led[56]).
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 [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-18 12:55 ` Geert Uytterhoeven
@ 2025-11-18 13:21 ` Bartosz Golaszewski
0 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-18 13:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
On Tue, Nov 18, 2025 at 1:56 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > >
> > > Thanks for your series, part of which is now present linux-next.
> > > IIUIC, this requires the direction of the GPIO to be fixed?
> > >
> > > We have a long-standing use-case on various Renesas R-Car Gen3 boards
> > > (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
> > > key switches. Basically, the GPIO is connected to:
> > > 1. A key switch connecting to GND when closed, with pull-up.
> > > 2. The gate of an N-channel MOSFET, turning on an LED when driven
> > > high.
> > >
> > > Hence:
> > > - In output mode, the LED can be controlled freely,
> > > - In input mode, the LED is on, unless the key is pressed,
> > > - Hence the switch state can only be read when the LED is turned on.
> > > If you have any idea how to handle this, feel free to reply ;-)
> >
> > How is this done currently? Even without this series and using the
> > GPIOD_FLAGS_BIT_NONEXCLUSIVE, the descriptor has a well-defined
> > direction so it's not possible for two drivers to request it as input
> > and output simultaneously. The second requester will override the
> > previous settings.
>
> We do not handle it yet:
> - arch/arm64/boot/dts/renesas/salvator-common.dtsi describes only
> the keys (key-[a-c]),
> - arch/arm64/boot/dts/renesas/ulcb.dtsi describes the first key
> (key-1), and the others as LEDs (led[56]).
>
I see. This series cannot possibly address this. Off the top of my
head: I would create an auxiliary device binding to a dedicated driver
that would be a consumer of this pin and register a LED and an input
key. By default it would set the direction to input and if the user
decided to configure the LED, it would change direction to output.
Obviously, there would be a DR quirk to handle as we already have this
described in DT as gpio-keys on salvator.
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
2025-11-13 8:51 ` Arnd Bergmann
2025-11-14 19:40 ` Bjorn Andersson
@ 2025-11-18 14:06 ` Mark Brown
2025-11-18 14:13 ` Bartosz Golaszewski
2025-11-26 14:24 ` Jon Hunter
2026-01-07 11:06 ` Pankaj Patil
4 siblings, 1 reply; 71+ messages in thread
From: Mark Brown @ 2025-11-18 14:06 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio, linux-hardening,
linux-kernel, linux-gpio, linux-arm-kernel, linux-sound,
linux-arm-msm, Bartosz Golaszewski, Aishwarya.TCV
[-- Attachment #1: Type: text/plain, Size: 27163 bytes --]
On Wed, Nov 12, 2025 at 02:55:36PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Some qualcomm platforms use shared GPIOs. Enable support for them by
> selecting the Kconfig switch provided by GPIOLIB.
This is causing boot failures for me in -next on the ARM FVP with
defconfig, the select affects all platforms not just the Qualcomm ones.
We get:
[ 0.137360] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
...
[ 0.140979] Call trace:
[ 0.141037] gpio_shared_of_traverse+0x48/0x480 (P)
[ 0.141187] gpio_shared_init+0x28/0x14c
[ 0.141314] do_one_initcall+0x60/0x1d4
[ 0.141446] kernel_init_freeable+0x24c/0x2c8
[ 0.141607] kernel_init+0x20/0x140
Full log:
https://lava.sirena.org.uk/scheduler/job/2101484#L692
Bisect log:
# bad: [187dac290bfd0741b9d7d5490af825c33fd9baa4] Add linux-next specific files for 20251118
# good: [17bfd0eea14a5f4217041fc57d85c965b07c02a8] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
# good: [118eb2cb97b8fc0d515bb0449495959247db58f0] spi: bcm63xx: drop wrong casts in probe()
# good: [059f545832be85d29ac9ccc416a16f647aa78485] spi: add support for microchip "soft" spi controller
# good: [6402ddf3027d8975f135cf2b2014d6bbeb2d3436] MAINTAINERS: refer to trivial-codec.yaml in relevant sections
# good: [4e00135b2dd1d7924a58bffa551b6ceb3bd836f2] spi: spi-cadence: supports transmission with bits_per_word of 16 and 32
# good: [e65b871c9b5af9265aefc5b8cd34993586d93aab] ASoC: codecs: pm4125: Remove irq_chip on component unbind
# good: [8d63e85c5b50f1dbfa0ccb214bd91fe5d7e2e860] firmware: cs_dsp: fix kernel-doc warnings in a header file
# good: [8ff3dcb0e8a8bf6c41f23ed4aa62d066d3948a10] ASoC: codecs: lpass-rx-macro: add SM6115 compatible
# good: [123cd174a3782307787268adf45f22de4d290128] ASoC: Intel: atom: Replace strcpy() with strscpy()
# good: [4d6e2211aeb932e096f673c88475016b1cc0f8ab] ASoC: Intel: boards: fix HDMI playback lookup when HDMI-In capture used
# good: [1d562ba0aa7df81335bf96c02be77efe8d5bab87] spi: dt-bindings: nuvoton,npcm-pspi: Convert to DT schema
# good: [b3a5302484033331af37569f7277d00131694b57] ASoC: Intel: sof_rt5682: Add quirk override support
# good: [873bc94689d832878befbcadc10b6ad5bb4e0027] ASoC: Intel: sof_sdw: add codec speaker support for the SKU
# good: [32172cf3cb543a04c41a1677c97a38e60cad05b6] ASoC: cs35l56: Allow restoring factory calibration through ALSA control
# good: [772ada50282b0c80343c8989147db816961f571d] ASoC: cs35l56: Alter error codes for calibration routine
# good: [6985defd1d832f1dd9d1977a6a2cc2cef7632704] regmap: sdw-mbq: Reorder regmap_mbq_context struct for better packing
# good: [fb1ebb10468da414d57153ddebaab29c38ef1a78] regulator: core: disable supply if enabling main regulator fails
# good: [6951be397ca8b8b167c9f99b5a11c541148c38cb] ASoC: codecs: pm4125: remove duplicate code
# good: [4e92abd0a11b91af3742197a9ca962c3c00d0948] spi: imx: add i.MX51 ECSPI target mode support
# good: [2089f086303b773e181567fd8d5df3038bd85937] regulator: mt6363: Remove unneeded semicolon
# good: [abc9a349b87ac0fd3ba8787ca00971b59c2e1257] spi: fsl-qspi: support the SpacemiT K1 SoC
# good: [55d03b5b5bdd04daf9a35ce49db18d8bb488dffb] spi: imx: remove CLK calculation and check for target mode
# good: [1b0f3f9ee41ee2bdd206667f85ea2aa36dfe6e69] ASoC: SDCA: support Q7.8 volume format
# good: [6bd1ad97eb790570c167d4de4ca59fbc9c33722a] regulator: pf9453: Fix kernel doc for mux_poll()
# good: [3c36965df80801344850388592e95033eceea05b] regulator: Add support for MediaTek MT6363 SPMI PMIC Regulators
# good: [655079ac8a7721ac215a0596e3f33b740e01144a] ASoC: qcom: q6asm: Use guard() for spin locks
# good: [2f538ef9f6f7c3d700c68536f21447dfc598f8c8] spi: aspeed: Use devm_iounmap() to unmap devm_ioremap() memory
# good: [aa897ffc396b48cc39eee133b6b43175d0df9eb5] ASoC: dt-bindings: ti,pcm1862: convert to dtschema
# good: [380fd29d57abe6679d87ec56babe65ddc5873a37] spi: tegra210-quad: Check hardware status on timeout
# good: [af9c8092d84244ca54ffb590435735f788e7a170] regmap: i3c: Use ARRAY_SIZE()
# good: [c4e68959af66df525d71db619ffe44af9178bb22] ASoC: dt-bindings: ti,tas2781: Add TAS5822 support
# good: [2ecc8c089802e033d2e5204d21a9f467e2517df9] regulator: pf9453: remove unused I2C_LT register
# good: [84194c66aaf78fed150edb217b9f341518b1cba2] ASoC: codecs: aw88261: pass pointer directly instead of passing the address
# good: [252abf2d07d33b1c70a59ba1c9395ba42bbd793e] regulator: Small cleanup in of_get_regulation_constraints()
# good: [ed5d499b5c9cc11dd3edae1a7a55db7dfa4f1bdc] regcache: maple: Split ->populate() from ->init()
# good: [e73b743bfe8a6ff4e05b5657d3f7586a17ac3ba0] ASoC: soc-core: check ops & auto_selectable_formats in snd_soc_dai_get_fmt() to prevent dereference error
# good: [6ef8e042cdcaabe3e3c68592ba8bfbaee2fa10a3] ASoC: codec: wm8400: replace printk() calls with dev_*() device aware logging
# good: [ecd0de438c1f0ee86cf8f6d5047965a2a181444b] spi: tle62x0: Add newline to sysfs attribute output
# good: [f1dfbc1b5cf8650ae9a0d543e5f5335fc0f478ce] ASoC: max98090/91: fixing the stream index
# good: [8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce] ASoC: qcom: sc7280: make use of common helpers
# good: [20bcda681f8597e86070a4b3b12d1e4f541865d3] ASoC: codecs: va-macro: fix revision checking
# good: [cf6bf51b53252284bafc7377a4d8dbf10f048b4d] ASoC: cs4271: Add support for the external mclk
# good: [28039efa4d8e8bbf98b066133a906bd4e307d496] MAINTAINERS: remove obsolete file entry in DIALOG SEMICONDUCTOR DRIVERS
# good: [e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8] regmap: warn users about uninitialized flat cache
# good: [f034c16a4663eaf3198dc18b201ba50533fb5b81] ASoC: spacemit: add failure check for spacemit_i2s_init_dai()
# good: [66fecfa91deb536a12ddf3d878a99590d7900277] ASoC: spacemit: use `depends on` instead of `select`
# good: [4a5ac6cd05a7e54f1585d7779464d6ed6272c134] ASoC: sun4i-spdif: Support SPDIF output on A523 family
# good: [ef042df96d0e1089764f39ede61bc8f140a4be00] ASoC: SDCA: Add HID button IRQ
# good: [4795375d8aa072e9aacb0b278e6203c6ca41816a] ASoC: cs-amp-lib-test: Add test cases for cs_amp_set_efi_calibration_data()
# good: [4c33cef58965eb655a0ac8e243aa323581ec025f] regulator: pca9450: link regulator inputs to supply groups
# good: [e973dfe9259095fb509ab12658c68d46f0e439d7] ASoC: qcom: sm8250: add qrb2210-sndcard compatible string
# good: [e7434adf0c53a84d548226304cdb41c8818da1cb] ASoC: cs530x: Add SPI bus support for cs530x parts
# good: [d29479abaded34b2b1dab2e17efe96a65eba3d61] ASoC: renesas: fsi: Constify struct fsi_stream_handler
# good: [77a58ba7c64ccca20616aa03599766ccb0d1a330] spi: spi-mem: Trace exec_op
# good: [01313661b248c5ba586acae09bff57077dbec0a5] regulator: Let raspberrypi drivers depend on ARM
# good: [c17fa4cbc546c431ccf13e9354d5d9c1cd247b7c] ASoC: sdw_utils: add name_prefix for rt1321 part id
# good: [310bf433c01f78e0756fd5056a43118a2f77318c] ASoC: max98090/91: fixing a space
# good: [fd5ef3d69f8975bad16c437a337b5cb04c8217a2] spi: spi-qpic-snand: make qcom_spi_ecc_engine_ops_pipelined const
# good: [d054cc3a2ccfb19484f3b54d69b6e416832dc8f4] regulator: rpmh-regulator: Add RPMH regulator support for PMR735D
# good: [2528c15f314ece50218d1273654f630d74109583] ASoC: max98090/91: adding DAPM routing for digital output for max98091
# good: [638bae3fb225a708dc67db613af62f6d14c4eff4] ASoC: max98090/91: added DAPM widget for digital output for max98091
# good: [ecba655bf54a661ffe078856cd8dbc898270e4b5] ASoC: fsl_aud2htx: add IEC958_SUBFRAME_LE format in supported list
# good: [7e1906643a7374529af74b013bba35e4fa4e6ffc] ASoC: codecs: va-macro: Clean up on error path in probe()
# good: [d742ebcfe524dc54023f7c520d2ed2e4b7203c19] ASoC: soc.h: remove snd_soc_kcontrol_component()
# good: [fce217449075d59b29052b8cdac567f0f3e22641] ASoC: spacemit: add i2s support for K1 SoC
# good: [6658472a3e2de08197acfe099ba71ee0e2505ecf] ASoC: amd: amd_sdw: Propagate the PCI subsystem Vendor and Device IDs
# good: [0cc08c8130ac8f74419f99fe707dc193b7f79d86] spi: aspeed: Fix an IS_ERR() vs NULL bug in probe()
# good: [0743acf746a81e0460a56fd5ff847d97fa7eb370] spi: airoha: buffer must be 0xff-ed before writing
# good: [d77daa49085b067137d0adbe3263f75a7ee13a1b] spi: aspeed: fix spelling mistake "triming" -> "trimming"
# good: [1e570e77392f43a3cdab2849d1f81535f8a033e2] ASoC: mxs-saif: support usage with simple-audio-card
# good: [15afe57a874eaf104bfbb61ec598fa31627f7b19] ASoC: dt-bindings: qcom: Add Kaanapali LPASS macro codecs
# good: [fb25114cd760c13cf177d9ac37837fafcc9657b5] regulator: sy7636a: add gpios and input regulator
# good: [65efe5404d151767653c7b7dd39bd2e7ad532c2d] regulator: rpmh-regulator: Add RPMH regulator support for Glymur
# good: [6621b0f118d500092f5f3d72ddddb22aeeb3c3a0] ASoC: codecs: rt5670: use SOC_VALUE_ENUM_SINGLE_DECL for DAC2 L/R MX-1B
# good: [433e294c3c5b5d2020085a0e36c1cb47b694690a] regulator: core: forward undervoltage events downstream by default
# good: [0b0eb7702a9fa410755e86124b4b7cd36e7d1cb4] ASoC: replace use of system_wq with system_dfl_wq
# good: [7e7e2c6e2a1cb250f8d03bb99eed01f6d982d5dd] ASoC: sof-function-topology-lib: escalate the log when missing function topoplogy
# good: [64d87ccfae3326a9561fe41dc6073064a083e0df] spi: aspeed: Only map necessary address window region
# good: [4d410ba9aa275e7990a270f63ce436990ace1bea] dt-bindings: sound: Update ADMAIF bindings for tegra264
# good: [b83fb1b14c06bdd765903ac852ba20a14e24f227] spi: offload: Add offset parameter
# good: [9797329220a2c6622411eb9ecf6a35b24ce09d04] ASoC: sof-function-topology-lib: escalate the log when missing function topoplogy
# good: [fe8cc44dd173cde5788ab4e3730ac61f3d316d9c] spi: dw: add target mode support
# good: [6277a486a7faaa6c87f4bf1d59a2de233a093248] regulator: dt-bindings: Convert Dialog DA9211 Regulators to DT schema
# good: [5e537031f322d55315cd384398b726a9a0748d47] ASoC: codecs: Fix the error of excessive semicolons
# good: [4412ab501677606436e5c49e41151a1e6eac7ac0] spi: dt-bindings: spi-qpic-snand: Add IPQ5332 compatible
git bisect start '187dac290bfd0741b9d7d5490af825c33fd9baa4' '17bfd0eea14a5f4217041fc57d85c965b07c02a8' '118eb2cb97b8fc0d515bb0449495959247db58f0' '059f545832be85d29ac9ccc416a16f647aa78485' '6402ddf3027d8975f135cf2b2014d6bbeb2d3436' '4e00135b2dd1d7924a58bffa551b6ceb3bd836f2' 'e65b871c9b5af9265aefc5b8cd34993586d93aab' '8d63e85c5b50f1dbfa0ccb214bd91fe5d7e2e860' '8ff3dcb0e8a8bf6c41f23ed4aa62d066d3948a10' '123cd174a3782307787268adf45f22de4d290128' '4d6e2211aeb932e096f673c88475016b1cc0f8ab' '1d562ba0aa7df81335bf96c02be77efe8d5bab87' 'b3a5302484033331af37569f7277d00131694b57' '873bc94689d832878befbcadc10b6ad5bb4e0027' '32172cf3cb543a04c41a1677c97a38e60cad05b6' '772ada50282b0c80343c8989147db816961f571d' '6985defd1d832f1dd9d1977a6a2cc2cef7632704' 'fb1ebb10468da414d57153ddebaab29c38ef1a78' '6951be397ca8b8b167c9f99b5a11c541148c38cb' '4e92abd0a11b91af3742197a9ca962c3c00d0948' '2089f086303b773e181567fd8d5df3038bd85937' 'abc9a349b87ac0fd3ba8787ca00971b59c2e1257' '55d03b5b5bdd04daf9a35ce49db18d8bb488dffb' '1b0f3f9ee41ee2bdd206667f85ea2aa36dfe6e69' '6bd1ad97eb790570c167d4de4ca59fbc9c33722a' '3c36965df80801344850388592e95033eceea05b' '655079ac8a7721ac215a0596e3f33b740e01144a' '2f538ef9f6f7c3d700c68536f21447dfc598f8c8' 'aa897ffc396b48cc39eee133b6b43175d0df9eb5' '380fd29d57abe6679d87ec56babe65ddc5873a37' 'af9c8092d84244ca54ffb590435735f788e7a170' 'c4e68959af66df525d71db619ffe44af9178bb22' '2ecc8c089802e033d2e5204d21a9f467e2517df9' '84194c66aaf78fed150edb217b9f341518b1cba2' '252abf2d07d33b1c70a59ba1c9395ba42bbd793e' 'ed5d499b5c9cc11dd3edae1a7a55db7dfa4f1bdc' 'e73b743bfe8a6ff4e05b5657d3f7586a17ac3ba0' '6ef8e042cdcaabe3e3c68592ba8bfbaee2fa10a3' 'ecd0de438c1f0ee86cf8f6d5047965a2a181444b' 'f1dfbc1b5cf8650ae9a0d543e5f5335fc0f478ce' '8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce' '20bcda681f8597e86070a4b3b12d1e4f541865d3' 'cf6bf51b53252284bafc7377a4d8dbf10f048b4d' '28039efa4d8e8bbf98b066133a906bd4e307d496' 'e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8' 'f034c16a4663eaf3198dc18b201ba50533fb5b81' '66fecfa91deb536a12ddf3d878a99590d7900277' '4a5ac6cd05a7e54f1585d7779464d6ed6272c134' 'ef042df96d0e1089764f39ede61bc8f140a4be00' '4795375d8aa072e9aacb0b278e6203c6ca41816a' '4c33cef58965eb655a0ac8e243aa323581ec025f' 'e973dfe9259095fb509ab12658c68d46f0e439d7' 'e7434adf0c53a84d548226304cdb41c8818da1cb' 'd29479abaded34b2b1dab2e17efe96a65eba3d61' '77a58ba7c64ccca20616aa03599766ccb0d1a330' '01313661b248c5ba586acae09bff57077dbec0a5' 'c17fa4cbc546c431ccf13e9354d5d9c1cd247b7c' '310bf433c01f78e0756fd5056a43118a2f77318c' 'fd5ef3d69f8975bad16c437a337b5cb04c8217a2' 'd054cc3a2ccfb19484f3b54d69b6e416832dc8f4' '2528c15f314ece50218d1273654f630d74109583' '638bae3fb225a708dc67db613af62f6d14c4eff4' 'ecba655bf54a661ffe078856cd8dbc898270e4b5' '7e1906643a7374529af74b013bba35e4fa4e6ffc' 'd742ebcfe524dc54023f7c520d2ed2e4b7203c19' 'fce217449075d59b29052b8cdac567f0f3e22641' '6658472a3e2de08197acfe099ba71ee0e2505ecf' '0cc08c8130ac8f74419f99fe707dc193b7f79d86' '0743acf746a81e0460a56fd5ff847d97fa7eb370' 'd77daa49085b067137d0adbe3263f75a7ee13a1b' '1e570e77392f43a3cdab2849d1f81535f8a033e2' '15afe57a874eaf104bfbb61ec598fa31627f7b19' 'fb25114cd760c13cf177d9ac37837fafcc9657b5' '65efe5404d151767653c7b7dd39bd2e7ad532c2d' '6621b0f118d500092f5f3d72ddddb22aeeb3c3a0' '433e294c3c5b5d2020085a0e36c1cb47b694690a' '0b0eb7702a9fa410755e86124b4b7cd36e7d1cb4' '7e7e2c6e2a1cb250f8d03bb99eed01f6d982d5dd' '64d87ccfae3326a9561fe41dc6073064a083e0df' '4d410ba9aa275e7990a270f63ce436990ace1bea' 'b83fb1b14c06bdd765903ac852ba20a14e24f227' '9797329220a2c6622411eb9ecf6a35b24ce09d04' 'fe8cc44dd173cde5788ab4e3730ac61f3d316d9c' '6277a486a7faaa6c87f4bf1d59a2de233a093248' '5e537031f322d55315cd384398b726a9a0748d47' '4412ab501677606436e5c49e41151a1e6eac7ac0'
# test job: [118eb2cb97b8fc0d515bb0449495959247db58f0] https://lava.sirena.org.uk/scheduler/job/2092429
# test job: [059f545832be85d29ac9ccc416a16f647aa78485] https://lava.sirena.org.uk/scheduler/job/2086705
# test job: [6402ddf3027d8975f135cf2b2014d6bbeb2d3436] https://lava.sirena.org.uk/scheduler/job/2086607
# test job: [4e00135b2dd1d7924a58bffa551b6ceb3bd836f2] https://lava.sirena.org.uk/scheduler/job/2082519
# test job: [e65b871c9b5af9265aefc5b8cd34993586d93aab] https://lava.sirena.org.uk/scheduler/job/2083021
# test job: [8d63e85c5b50f1dbfa0ccb214bd91fe5d7e2e860] https://lava.sirena.org.uk/scheduler/job/2082629
# test job: [8ff3dcb0e8a8bf6c41f23ed4aa62d066d3948a10] https://lava.sirena.org.uk/scheduler/job/2083070
# test job: [123cd174a3782307787268adf45f22de4d290128] https://lava.sirena.org.uk/scheduler/job/2078932
# test job: [4d6e2211aeb932e096f673c88475016b1cc0f8ab] https://lava.sirena.org.uk/scheduler/job/2078021
# test job: [1d562ba0aa7df81335bf96c02be77efe8d5bab87] https://lava.sirena.org.uk/scheduler/job/2078357
# test job: [b3a5302484033331af37569f7277d00131694b57] https://lava.sirena.org.uk/scheduler/job/2074567
# test job: [873bc94689d832878befbcadc10b6ad5bb4e0027] https://lava.sirena.org.uk/scheduler/job/2074808
# test job: [32172cf3cb543a04c41a1677c97a38e60cad05b6] https://lava.sirena.org.uk/scheduler/job/2075068
# test job: [772ada50282b0c80343c8989147db816961f571d] https://lava.sirena.org.uk/scheduler/job/2069222
# test job: [6985defd1d832f1dd9d1977a6a2cc2cef7632704] https://lava.sirena.org.uk/scheduler/job/2059088
# test job: [fb1ebb10468da414d57153ddebaab29c38ef1a78] https://lava.sirena.org.uk/scheduler/job/2059751
# test job: [6951be397ca8b8b167c9f99b5a11c541148c38cb] https://lava.sirena.org.uk/scheduler/job/2055789
# test job: [4e92abd0a11b91af3742197a9ca962c3c00d0948] https://lava.sirena.org.uk/scheduler/job/2055834
# test job: [2089f086303b773e181567fd8d5df3038bd85937] https://lava.sirena.org.uk/scheduler/job/2058076
# test job: [abc9a349b87ac0fd3ba8787ca00971b59c2e1257] https://lava.sirena.org.uk/scheduler/job/2054550
# test job: [55d03b5b5bdd04daf9a35ce49db18d8bb488dffb] https://lava.sirena.org.uk/scheduler/job/2053870
# test job: [1b0f3f9ee41ee2bdd206667f85ea2aa36dfe6e69] https://lava.sirena.org.uk/scheduler/job/2053622
# test job: [6bd1ad97eb790570c167d4de4ca59fbc9c33722a] https://lava.sirena.org.uk/scheduler/job/2053461
# test job: [3c36965df80801344850388592e95033eceea05b] https://lava.sirena.org.uk/scheduler/job/2049487
# test job: [655079ac8a7721ac215a0596e3f33b740e01144a] https://lava.sirena.org.uk/scheduler/job/2049673
# test job: [2f538ef9f6f7c3d700c68536f21447dfc598f8c8] https://lava.sirena.org.uk/scheduler/job/2048609
# test job: [aa897ffc396b48cc39eee133b6b43175d0df9eb5] https://lava.sirena.org.uk/scheduler/job/2048708
# test job: [380fd29d57abe6679d87ec56babe65ddc5873a37] https://lava.sirena.org.uk/scheduler/job/2044538
# test job: [af9c8092d84244ca54ffb590435735f788e7a170] https://lava.sirena.org.uk/scheduler/job/2043755
# test job: [c4e68959af66df525d71db619ffe44af9178bb22] https://lava.sirena.org.uk/scheduler/job/2044079
# test job: [2ecc8c089802e033d2e5204d21a9f467e2517df9] https://lava.sirena.org.uk/scheduler/job/2038469
# test job: [84194c66aaf78fed150edb217b9f341518b1cba2] https://lava.sirena.org.uk/scheduler/job/2038350
# test job: [252abf2d07d33b1c70a59ba1c9395ba42bbd793e] https://lava.sirena.org.uk/scheduler/job/2038498
# test job: [ed5d499b5c9cc11dd3edae1a7a55db7dfa4f1bdc] https://lava.sirena.org.uk/scheduler/job/2028996
# test job: [e73b743bfe8a6ff4e05b5657d3f7586a17ac3ba0] https://lava.sirena.org.uk/scheduler/job/2026389
# test job: [6ef8e042cdcaabe3e3c68592ba8bfbaee2fa10a3] https://lava.sirena.org.uk/scheduler/job/2025846
# test job: [ecd0de438c1f0ee86cf8f6d5047965a2a181444b] https://lava.sirena.org.uk/scheduler/job/2026091
# test job: [f1dfbc1b5cf8650ae9a0d543e5f5335fc0f478ce] https://lava.sirena.org.uk/scheduler/job/2025507
# test job: [8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce] https://lava.sirena.org.uk/scheduler/job/2021419
# test job: [20bcda681f8597e86070a4b3b12d1e4f541865d3] https://lava.sirena.org.uk/scheduler/job/2022919
# test job: [cf6bf51b53252284bafc7377a4d8dbf10f048b4d] https://lava.sirena.org.uk/scheduler/job/2022940
# test job: [28039efa4d8e8bbf98b066133a906bd4e307d496] https://lava.sirena.org.uk/scheduler/job/2020277
# test job: [e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8] https://lava.sirena.org.uk/scheduler/job/2020136
# test job: [f034c16a4663eaf3198dc18b201ba50533fb5b81] https://lava.sirena.org.uk/scheduler/job/2015402
# test job: [66fecfa91deb536a12ddf3d878a99590d7900277] https://lava.sirena.org.uk/scheduler/job/2015319
# test job: [4a5ac6cd05a7e54f1585d7779464d6ed6272c134] https://lava.sirena.org.uk/scheduler/job/2011242
# test job: [ef042df96d0e1089764f39ede61bc8f140a4be00] https://lava.sirena.org.uk/scheduler/job/2010188
# test job: [4795375d8aa072e9aacb0b278e6203c6ca41816a] https://lava.sirena.org.uk/scheduler/job/2009710
# test job: [4c33cef58965eb655a0ac8e243aa323581ec025f] https://lava.sirena.org.uk/scheduler/job/2009389
# test job: [e973dfe9259095fb509ab12658c68d46f0e439d7] https://lava.sirena.org.uk/scheduler/job/2008156
# test job: [e7434adf0c53a84d548226304cdb41c8818da1cb] https://lava.sirena.org.uk/scheduler/job/2007781
# test job: [d29479abaded34b2b1dab2e17efe96a65eba3d61] https://lava.sirena.org.uk/scheduler/job/2008399
# test job: [77a58ba7c64ccca20616aa03599766ccb0d1a330] https://lava.sirena.org.uk/scheduler/job/2007312
# test job: [01313661b248c5ba586acae09bff57077dbec0a5] https://lava.sirena.org.uk/scheduler/job/2008756
# test job: [c17fa4cbc546c431ccf13e9354d5d9c1cd247b7c] https://lava.sirena.org.uk/scheduler/job/2000025
# test job: [310bf433c01f78e0756fd5056a43118a2f77318c] https://lava.sirena.org.uk/scheduler/job/1995997
# test job: [fd5ef3d69f8975bad16c437a337b5cb04c8217a2] https://lava.sirena.org.uk/scheduler/job/1996106
# test job: [d054cc3a2ccfb19484f3b54d69b6e416832dc8f4] https://lava.sirena.org.uk/scheduler/job/1995702
# test job: [2528c15f314ece50218d1273654f630d74109583] https://lava.sirena.org.uk/scheduler/job/1997627
# test job: [638bae3fb225a708dc67db613af62f6d14c4eff4] https://lava.sirena.org.uk/scheduler/job/1991837
# test job: [ecba655bf54a661ffe078856cd8dbc898270e4b5] https://lava.sirena.org.uk/scheduler/job/1985161
# test job: [7e1906643a7374529af74b013bba35e4fa4e6ffc] https://lava.sirena.org.uk/scheduler/job/1978626
# test job: [d742ebcfe524dc54023f7c520d2ed2e4b7203c19] https://lava.sirena.org.uk/scheduler/job/1975991
# test job: [fce217449075d59b29052b8cdac567f0f3e22641] https://lava.sirena.org.uk/scheduler/job/1975648
# test job: [6658472a3e2de08197acfe099ba71ee0e2505ecf] https://lava.sirena.org.uk/scheduler/job/1973468
# test job: [0cc08c8130ac8f74419f99fe707dc193b7f79d86] https://lava.sirena.org.uk/scheduler/job/1965716
# test job: [0743acf746a81e0460a56fd5ff847d97fa7eb370] https://lava.sirena.org.uk/scheduler/job/1964817
# test job: [d77daa49085b067137d0adbe3263f75a7ee13a1b] https://lava.sirena.org.uk/scheduler/job/1962810
# test job: [1e570e77392f43a3cdab2849d1f81535f8a033e2] https://lava.sirena.org.uk/scheduler/job/1962218
# test job: [15afe57a874eaf104bfbb61ec598fa31627f7b19] https://lava.sirena.org.uk/scheduler/job/1962933
# test job: [fb25114cd760c13cf177d9ac37837fafcc9657b5] https://lava.sirena.org.uk/scheduler/job/1960135
# test job: [65efe5404d151767653c7b7dd39bd2e7ad532c2d] https://lava.sirena.org.uk/scheduler/job/1959967
# test job: [6621b0f118d500092f5f3d72ddddb22aeeb3c3a0] https://lava.sirena.org.uk/scheduler/job/1959721
# test job: [433e294c3c5b5d2020085a0e36c1cb47b694690a] https://lava.sirena.org.uk/scheduler/job/1957324
# test job: [0b0eb7702a9fa410755e86124b4b7cd36e7d1cb4] https://lava.sirena.org.uk/scheduler/job/1957396
# test job: [7e7e2c6e2a1cb250f8d03bb99eed01f6d982d5dd] https://lava.sirena.org.uk/scheduler/job/1954253
# test job: [64d87ccfae3326a9561fe41dc6073064a083e0df] https://lava.sirena.org.uk/scheduler/job/1947205
# test job: [4d410ba9aa275e7990a270f63ce436990ace1bea] https://lava.sirena.org.uk/scheduler/job/1947743
# test job: [b83fb1b14c06bdd765903ac852ba20a14e24f227] https://lava.sirena.org.uk/scheduler/job/1946813
# test job: [9797329220a2c6622411eb9ecf6a35b24ce09d04] https://lava.sirena.org.uk/scheduler/job/1947377
# test job: [fe8cc44dd173cde5788ab4e3730ac61f3d316d9c] https://lava.sirena.org.uk/scheduler/job/1946013
# test job: [6277a486a7faaa6c87f4bf1d59a2de233a093248] https://lava.sirena.org.uk/scheduler/job/1947015
# test job: [5e537031f322d55315cd384398b726a9a0748d47] https://lava.sirena.org.uk/scheduler/job/1946667
# test job: [4412ab501677606436e5c49e41151a1e6eac7ac0] https://lava.sirena.org.uk/scheduler/job/1946327
# test job: [187dac290bfd0741b9d7d5490af825c33fd9baa4] https://lava.sirena.org.uk/scheduler/job/2101535
# bad: [187dac290bfd0741b9d7d5490af825c33fd9baa4] Add linux-next specific files for 20251118
git bisect bad 187dac290bfd0741b9d7d5490af825c33fd9baa4
# test job: [abb54b0b86a61f10649f9ef3f6ab6821ae6abe74] https://lava.sirena.org.uk/scheduler/job/2101660
# good: [abb54b0b86a61f10649f9ef3f6ab6821ae6abe74] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
git bisect good abb54b0b86a61f10649f9ef3f6ab6821ae6abe74
# test job: [ad048b22af91649db0797904f7452bbd082c4f72] https://lava.sirena.org.uk/scheduler/job/2101860
# good: [ad048b22af91649db0797904f7452bbd082c4f72] Merge branch 'for-backlight-next' of https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
git bisect good ad048b22af91649db0797904f7452bbd082c4f72
# test job: [2eb38aa81687e8bde227a4be8bc16aaea024b41a] https://lava.sirena.org.uk/scheduler/job/2102056
# good: [2eb38aa81687e8bde227a4be8bc16aaea024b41a] Merge branch 'driver-core-next' of https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
git bisect good 2eb38aa81687e8bde227a4be8bc16aaea024b41a
# test job: [276498a96b70a88fc8c42d9104edd0d79c1bf6a8] https://lava.sirena.org.uk/scheduler/job/2102243
# good: [276498a96b70a88fc8c42d9104edd0d79c1bf6a8] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
git bisect good 276498a96b70a88fc8c42d9104edd0d79c1bf6a8
# test job: [36ebc989a5812e1de53b78054cb8a2f07b048d2b] https://lava.sirena.org.uk/scheduler/job/2102380
# bad: [36ebc989a5812e1de53b78054cb8a2f07b048d2b] Merge branch 'ntb-next' of https://github.com/jonmason/ntb.git
git bisect bad 36ebc989a5812e1de53b78054cb8a2f07b048d2b
# test job: [5bcc5021b9db0a2f07a041671c3c4a70889d813b] https://lava.sirena.org.uk/scheduler/job/2102409
# bad: [5bcc5021b9db0a2f07a041671c3c4a70889d813b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
git bisect bad 5bcc5021b9db0a2f07a041671c3c4a70889d813b
# test job: [8e9536f35f91235a023bb97d1aa2ce34f702bcfa] https://lava.sirena.org.uk/scheduler/job/2102420
# bad: [8e9536f35f91235a023bb97d1aa2ce34f702bcfa] Merge branch 'gpio/for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
git bisect bad 8e9536f35f91235a023bb97d1aa2ce34f702bcfa
# test job: [82e71fe4368699341333e7e0d059ef7df139cf95] https://lava.sirena.org.uk/scheduler/job/2102438
# bad: [82e71fe4368699341333e7e0d059ef7df139cf95] Merge tag 'gpio/shared-gpios-for-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git into gpio/for-next
git bisect bad 82e71fe4368699341333e7e0d059ef7df139cf95
# test job: [0efa5b2ca6fa7baab4c523b34cfb9495ec143d61] https://lava.sirena.org.uk/scheduler/job/2102456
# good: [0efa5b2ca6fa7baab4c523b34cfb9495ec143d61] gpio: aspeed: remove unneeded include
git bisect good 0efa5b2ca6fa7baab4c523b34cfb9495ec143d61
# test job: [7e061b462b3d43a1f85519f5aebdc77cbbe648c0] https://lava.sirena.org.uk/scheduler/job/2102591
# good: [7e061b462b3d43a1f85519f5aebdc77cbbe648c0] gpio: mmio: use lock guards
git bisect good 7e061b462b3d43a1f85519f5aebdc77cbbe648c0
# test job: [1e4f6db614a310cc34d07ffbf031c76ea9581bcf] https://lava.sirena.org.uk/scheduler/job/2102712
# good: [1e4f6db614a310cc34d07ffbf031c76ea9581bcf] gpiolib: support shared GPIOs in core subsystem code
git bisect good 1e4f6db614a310cc34d07ffbf031c76ea9581bcf
# test job: [b6d31cd41814a33c1a22b8c676131820440cc44e] https://lava.sirena.org.uk/scheduler/job/2102848
# good: [b6d31cd41814a33c1a22b8c676131820440cc44e] gpio: cdev: replace use of system_wq with system_percpu_wq
git bisect good b6d31cd41814a33c1a22b8c676131820440cc44e
# test job: [e511d484cbe44fe48a1b9f621f6a947c72503f9e] https://lava.sirena.org.uk/scheduler/job/2103002
# bad: [e511d484cbe44fe48a1b9f621f6a947c72503f9e] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
git bisect bad e511d484cbe44fe48a1b9f621f6a947c72503f9e
# test job: [eb374f764a7012eda28019266a6d9191670c4fa5] https://lava.sirena.org.uk/scheduler/job/2103014
# good: [eb374f764a7012eda28019266a6d9191670c4fa5] gpio: provide gpiod_is_shared()
git bisect good eb374f764a7012eda28019266a6d9191670c4fa5
# first bad commit: [e511d484cbe44fe48a1b9f621f6a947c72503f9e] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-18 14:06 ` Mark Brown
@ 2025-11-18 14:13 ` Bartosz Golaszewski
2025-11-18 14:20 ` Mark Brown
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-18 14:13 UTC (permalink / raw)
To: Mark Brown
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio, linux-hardening,
linux-kernel, linux-gpio, linux-arm-kernel, linux-sound,
linux-arm-msm, Bartosz Golaszewski, Aishwarya.TCV
On Tue, Nov 18, 2025 at 3:06 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Nov 12, 2025 at 02:55:36PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Some qualcomm platforms use shared GPIOs. Enable support for them by
> > selecting the Kconfig switch provided by GPIOLIB.
>
> This is causing boot failures for me in -next on the ARM FVP with
> defconfig, the select affects all platforms not just the Qualcomm ones.
> We get:
>
> [ 0.137360] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
>
> ...
>
> [ 0.140979] Call trace:
> [ 0.141037] gpio_shared_of_traverse+0x48/0x480 (P)
> [ 0.141187] gpio_shared_init+0x28/0x14c
> [ 0.141314] do_one_initcall+0x60/0x1d4
> [ 0.141446] kernel_init_freeable+0x24c/0x2c8
> [ 0.141607] kernel_init+0x20/0x140
>
> Full log:
>
> https://lava.sirena.org.uk/scheduler/job/2101484#L692
>
Hi Mark!
Thanks for the heads-up. I'll try to fix it ASAP to avoid a revert.
I can't open the link:
500 Internal Server Error
FATAL: remaining connection slots are reserved for non-replication
superuser connections
Oops, something has gone wrong!
Any chance you could get the offending line out of this stack trace?
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-18 14:13 ` Bartosz Golaszewski
@ 2025-11-18 14:20 ` Mark Brown
2025-11-18 14:27 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Mark Brown @ 2025-11-18 14:20 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio, linux-hardening,
linux-kernel, linux-gpio, linux-arm-kernel, linux-sound,
linux-arm-msm, Bartosz Golaszewski, Aishwarya.TCV
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Tue, Nov 18, 2025 at 03:13:49PM +0100, Bartosz Golaszewski wrote:
> Thanks for the heads-up. I'll try to fix it ASAP to avoid a revert.
> I can't open the link:
> 500 Internal Server Error
> FATAL: remaining connection slots are reserved for non-replication
> superuser connections
> Oops, something has gone wrong!
Retry, it's AI scrapers so those 500 responses are just glitches.
> Any chance you could get the offending line out of this stack trace?
https://builds.sirena.org.uk/187dac290bfd0741b9d7d5490af825c33fd9baa4/arm64/defconfig/vmlinux.xz
/build/stage/linux/drivers/gpio/gpiolib-shared.c:87
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-18 14:20 ` Mark Brown
@ 2025-11-18 14:27 ` Bartosz Golaszewski
2025-11-18 19:46 ` Mark Brown
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-18 14:27 UTC (permalink / raw)
To: Mark Brown
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio, linux-hardening,
linux-kernel, linux-gpio, linux-arm-kernel, linux-sound,
linux-arm-msm, Bartosz Golaszewski, Aishwarya.TCV,
Bartosz Golaszewski
On Tue, 18 Nov 2025 15:20:47 +0100, Mark Brown <broonie@kernel.org> said:
> On Tue, Nov 18, 2025 at 03:13:49PM +0100, Bartosz Golaszewski wrote:
>
>> Thanks for the heads-up. I'll try to fix it ASAP to avoid a revert.
>
>> I can't open the link:
>
>> 500 Internal Server Error
>
>> FATAL: remaining connection slots are reserved for non-replication
>> superuser connections
>
>> Oops, something has gone wrong!
>
> Retry, it's AI scrapers so those 500 responses are just glitches.
>
>> Any chance you could get the offending line out of this stack trace?
>
> https://builds.sirena.org.uk/187dac290bfd0741b9d7d5490af825c33fd9baa4/arm64/defconfig/vmlinux.xz
>
> /build/stage/linux/drivers/gpio/gpiolib-shared.c:87
>
Oh, of_root may be NULL...
Could you try the following change please?
diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
index c22eaf05eef23..4ce574a21850b 100644
--- a/drivers/gpio/gpiolib-shared.c
+++ b/drivers/gpio/gpiolib-shared.c
@@ -205,7 +205,10 @@ static int gpio_shared_of_traverse(struct
device_node *curr)
static int gpio_shared_of_scan(void)
{
- return gpio_shared_of_traverse(of_root);
+ if (of_root)
+ return gpio_shared_of_traverse(of_root);
+
+ return 0;
}
#else
static int gpio_shared_of_scan(void)
Bart
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-18 14:27 ` Bartosz Golaszewski
@ 2025-11-18 19:46 ` Mark Brown
0 siblings, 0 replies; 71+ messages in thread
From: Mark Brown @ 2025-11-18 19:46 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio, linux-hardening,
linux-kernel, linux-gpio, linux-arm-kernel, linux-sound,
linux-arm-msm, Bartosz Golaszewski, Aishwarya.TCV
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
On Tue, Nov 18, 2025 at 06:27:23AM -0800, Bartosz Golaszewski wrote:
> Oh, of_root may be NULL...
>
> Could you try the following change please?
That seems to work on FVP, I've also seen the same failure on other
platforms including Orion O6 and Graviton 3 but didn't test there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-18 11:15 ` Geert Uytterhoeven
2025-11-18 11:55 ` Bartosz Golaszewski
@ 2025-11-18 23:23 ` Linus Walleij
2025-11-19 8:01 ` Andy Shevchenko
2025-11-19 8:33 ` Geert Uytterhoeven
1 sibling, 2 replies; 71+ messages in thread
From: Linus Walleij @ 2025-11-18 23:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
On Tue, Nov 18, 2025 at 12:15 PM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> We have a long-standing use-case on various Renesas R-Car Gen3 boards
> (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
> key switches. Basically, the GPIO is connected to:
> 1. A key switch connecting to GND when closed, with pull-up.
> 2. The gate of an N-channel MOSFET, turning on an LED when driven
> high.
>
> Hence:
> - In output mode, the LED can be controlled freely,
> - In input mode, the LED is on, unless the key is pressed,
> - Hence the switch state can only be read when the LED is turned on.
Fantastic solution to a lack of GPIO lines.
This reminds me of the Amiga 500 power LED which was connected
to a GPIO which was cleverly also reused to control the audio filter,
with the effect that when you turned off the audio filter the power LED
went out and music toggling the filter off/on for effects would also
give you an incidental stroboscope.
> If you have any idea how to handle this, feel free to reply ;-)
Isn't it pretty clear from the system-level DTS how the line
is used?
If it is connected to a gpio key it gets assigned for that usecase
and handled by that driver and if it is connected to a gpio LED
it is handled by that driver.
For the input usecase the status of the LED is a byproduct and
should not reflect in software I think. It surely should not be
controllable and possible to set into output mode because
that sounds like a recipe for HW damage if you drive it
actively high and press the key at the same time.
gpio_keys {
compatible = "gpio-keys";
button-ok {
gpios = <&gpio 0 GPIO_OPEN_DRAIN | GPIO_PULL_UP>;
};
};
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-18 23:23 ` Linus Walleij
@ 2025-11-19 8:01 ` Andy Shevchenko
2025-11-19 8:33 ` Geert Uytterhoeven
1 sibling, 0 replies; 71+ messages in thread
From: Andy Shevchenko @ 2025-11-19 8:01 UTC (permalink / raw)
To: Linus Walleij
Cc: Geert Uytterhoeven, Bartosz Golaszewski, Kees Cook,
Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
On Wed, Nov 19, 2025 at 1:24 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Nov 18, 2025 at 12:15 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
...
> > We have a long-standing use-case on various Renesas R-Car Gen3 boards
> > (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
> > key switches. Basically, the GPIO is connected to:
> > 1. A key switch connecting to GND when closed, with pull-up.
> > 2. The gate of an N-channel MOSFET, turning on an LED when driven
> > high.
> >
> > Hence:
> > - In output mode, the LED can be controlled freely,
> > - In input mode, the LED is on, unless the key is pressed,
> > - Hence the switch state can only be read when the LED is turned on.
>
> Fantastic solution to a lack of GPIO lines.
I feel a poster "SARCASM" behind this line :-)
That's what happened when old-school (in a bad term) HW engineers who
try to enforce their experience on the modern SoC-based platforms that
run GP OSes in multi-tasking, multi-user manner.
> This reminds me of the Amiga 500 power LED which was connected
> to a GPIO which was cleverly also reused to control the audio filter,
> with the effect that when you turned off the audio filter the power LED
> went out and music toggling the filter off/on for effects would also
> give you an incidental stroboscope.
>
> > If you have any idea how to handle this, feel free to reply ;-)
>
> Isn't it pretty clear from the system-level DTS how the line
> is used?
>
> If it is connected to a gpio key it gets assigned for that usecase
> and handled by that driver and if it is connected to a gpio LED
> it is handled by that driver.
>
> For the input usecase the status of the LED is a byproduct and
> should not reflect in software I think. It surely should not be
> controllable and possible to set into output mode because
> that sounds like a recipe for HW damage if you drive it
> actively high and press the key at the same time.
>
> gpio_keys {
> compatible = "gpio-keys";
>
> button-ok {
> gpios = <&gpio 0 GPIO_OPEN_DRAIN | GPIO_PULL_UP>;
> };
> };
This is my understanding as well.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-18 23:23 ` Linus Walleij
2025-11-19 8:01 ` Andy Shevchenko
@ 2025-11-19 8:33 ` Geert Uytterhoeven
2025-11-19 14:29 ` Linus Walleij
1 sibling, 1 reply; 71+ messages in thread
From: Geert Uytterhoeven @ 2025-11-19 8:33 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
Hi Linus,
On Wed, 19 Nov 2025 at 00:24, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Nov 18, 2025 at 12:15 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > We have a long-standing use-case on various Renesas R-Car Gen3 boards
> > (e.g. Salvator-X(S) and ULCB[1]), where GPIOs are shared by LEDs and
> > key switches. Basically, the GPIO is connected to:
> > 1. A key switch connecting to GND when closed, with pull-up.
> > 2. The gate of an N-channel MOSFET, turning on an LED when driven
> > high.
> >
> > Hence:
> > - In output mode, the LED can be controlled freely,
> > - In input mode, the LED is on, unless the key is pressed,
> > - Hence the switch state can only be read when the LED is turned on.
>
> > If you have any idea how to handle this, feel free to reply ;-)
>
> Isn't it pretty clear from the system-level DTS how the line
> is used?
>
> If it is connected to a gpio key it gets assigned for that usecase
> and handled by that driver and if it is connected to a gpio LED
> it is handled by that driver.
>
> For the input usecase the status of the LED is a byproduct and
> should not reflect in software I think. It surely should not be
> controllable and possible to set into output mode because
> that sounds like a recipe for HW damage if you drive it
> actively high and press the key at the same time.
Suitable resistors are present to prevent hardware damage.
> gpio_keys {
> compatible = "gpio-keys";
>
> button-ok {
> gpios = <&gpio 0 GPIO_OPEN_DRAIN | GPIO_PULL_UP>;
> };
> };
But only one of the gpio-keys and gpio-leds drivers can bind to the
GPIO, or am I missing something?
So I do think I need a new combined key-and-led driver, like Bartosz
suggested:
- When the user turns the LED on, the GPIO is switched to input mode,
and the switch works,
- When the user turns the LED off, the GPIO is switched to output
and driven low, and the switch does not work.
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 [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-19 8:33 ` Geert Uytterhoeven
@ 2025-11-19 14:29 ` Linus Walleij
0 siblings, 0 replies; 71+ messages in thread
From: Linus Walleij @ 2025-11-19 14:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Linux-Renesas
On Wed, Nov 19, 2025 at 9:38 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > For the input usecase the status of the LED is a byproduct and
> > should not reflect in software I think. It surely should not be
> > controllable and possible to set into output mode because
> > that sounds like a recipe for HW damage if you drive it
> > actively high and press the key at the same time.
>
> Suitable resistors are present to prevent hardware damage.
Aha, clever.
> > gpio_keys {
> > compatible = "gpio-keys";
> >
> > button-ok {
> > gpios = <&gpio 0 GPIO_OPEN_DRAIN | GPIO_PULL_UP>;
> > };
> > };
>
> But only one of the gpio-keys and gpio-leds drivers can bind to the
> GPIO, or am I missing something?
> So I do think I need a new combined key-and-led driver, like Bartosz
> suggested:
> - When the user turns the LED on, the GPIO is switched to input mode,
> and the switch works,
> - When the user turns the LED off, the GPIO is switched to output
> and driven low, and the switch does not work.
You will also have the byproduct that the LED being "on" in software
does not necessarily reflect the actual LED status, someone
may be pressing the key and then the LED is off even though
in sysfs it is clearly "on".
So the status in the LED classdevice also has to be forced to "off"
(brightness 0) anytime the input subsystem detects that the switch
is pressed.
It's going to be a lot of work I think, but I guess it can be done,
with a lot of special-casing and custom APIs.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: (subset) [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (11 preceding siblings ...)
2025-11-18 11:15 ` Geert Uytterhoeven
@ 2025-11-20 10:39 ` Mark Brown
2025-11-20 13:36 ` Mark Brown
` (3 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Mark Brown @ 2025-11-20 10:39 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
Bartosz Golaszewski
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, 12 Nov 2025 14:55:29 +0100, Bartosz Golaszewski wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[10/10] regulator: make the subsystem aware of shared GPIOs
commit: b871d9adffe5a64a1fd9edcb1aebbcc995b17901
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: (subset) [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (12 preceding siblings ...)
2025-11-20 10:39 ` (subset) " Mark Brown
@ 2025-11-20 13:36 ` Mark Brown
2025-11-21 0:27 ` Val Packett
` (2 subsequent siblings)
16 siblings, 0 replies; 71+ messages in thread
From: Mark Brown @ 2025-11-20 13:36 UTC (permalink / raw)
To: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
Bartosz Golaszewski
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, 12 Nov 2025 14:55:29 +0100, Bartosz Golaszewski wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[08/10] ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
commit: d01fbee5c0d3d3061fb16235b71f5a117128e2c1
[09/10] ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
commit: 7a0a87712120329c034b0aae88bdaa05bd046f10
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (13 preceding siblings ...)
2025-11-20 13:36 ` Mark Brown
@ 2025-11-21 0:27 ` Val Packett
2025-11-21 9:03 ` Bartosz Golaszewski
2025-11-26 16:27 ` Dmitry Baryshkov
2026-01-08 14:46 ` Michael Walle
16 siblings, 1 reply; 71+ messages in thread
From: Val Packett @ 2025-11-21 0:27 UTC (permalink / raw)
To: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
Hi,
On 11/12/25 10:55 AM, Bartosz Golaszewski wrote:
> ---
> Bartosz Golaszewski (10):
> string: provide strends()
> gpiolib: define GPIOD_FLAG_SHARED
> gpiolib: implement low-level, shared GPIO support
> gpio: shared-proxy: implement the shared GPIO proxy driver
> gpiolib: support shared GPIOs in core subsystem code
> gpio: provide gpiod_is_shared()
> arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
> ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
> ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
> regulator: make the subsystem aware of shared GPIOs
this seems to actually have caused a regression for me, audio does not
initialize anymore on hamoa due to EBUSY since upgrading
from next-20251114 to next-20251118 or next-20251120:
[ 11.748781] platform
6800000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 30
[ 11.785864] wsa_macro 6aa0000.codec: using zero-initialized flat
cache, this may cause unexpected behavior
[ 11.796964] reset-gpio reset-gpio.0: error -EBUSY: Could not get
reset gpios
[ 11.796984] reset-gpio reset-gpio.0: probe with driver reset-gpio
failed with error -16
[ 11.894662] reset-gpio reset-gpio.1: error -EBUSY: Could not get
reset gpios
[ 11.894676] reset-gpio reset-gpio.1: probe with driver reset-gpio
failed with error -16
[ 12.006938] wcd938x_codec audio-codec: bound sdw:2:0:0217:010d:00:4
(ops wcd_sdw_component_ops [snd_soc_wcd_common])
[ 12.006964] wcd938x_codec audio-codec: bound sdw:3:0:0217:010d:00:3
(ops wcd_sdw_component_ops [snd_soc_wcd_common])
[ 15.424657] qcom-soundwire 6ab0000.soundwire: qcom_swrm_irq_handler:
SWR CMD error, fifo status 0x4e00c00f, flushing fifo
[ 21.994354] qcom-soundwire 6ab0000.soundwire: qcom_swrm_irq_handler:
SWR CMD error, fifo status 0xe00c000, flushing fifo
[ 21.996001] qcom-soundwire 6b10000.soundwire: qcom_swrm_irq_handler:
SWR CMD error, fifo status 0x4e00c00f, flushing fifo
[ 21.996239] platform sound: deferred probe pending: snd-x1e80100: WSA
Playback: codec dai not found
[ 21.996248] soundwire sdw:4:0:0217:0204:00:0: deferred probe pending:
wsa884x-codec: Failed to get reset
[ 21.996250] soundwire sdw:4:0:0217:0204:00:1: deferred probe pending:
wsa884x-codec: Failed to get reset
[ 21.996251] soundwire sdw:1:0:0217:0204:00:0: deferred probe pending:
wsa884x-codec: Failed to get reset
[ 21.996253] soundwire sdw:1:0:0217:0204:00:1: deferred probe pending:
wsa884x-codec: Failed to get reset
gpio_shared_proxy, reset_gpio, pinctrl_sm8550_lpass_lpi are all built as
modules and were autoloaded fine.
This is wsa884x (not wsa881x nor wsa883x), failing in
devm_reset_control_get_optional_shared..
Thanks,
~val
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-21 0:27 ` Val Packett
@ 2025-11-21 9:03 ` Bartosz Golaszewski
2025-11-21 10:20 ` Krzysztof Kozlowski
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-21 9:03 UTC (permalink / raw)
To: Val Packett
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Fri, Nov 21, 2025 at 1:28 AM Val Packett <val@packett.cool> wrote:
>
> Hi,
>
> On 11/12/25 10:55 AM, Bartosz Golaszewski wrote:
> > ---
> > Bartosz Golaszewski (10):
> > string: provide strends()
> > gpiolib: define GPIOD_FLAG_SHARED
> > gpiolib: implement low-level, shared GPIO support
> > gpio: shared-proxy: implement the shared GPIO proxy driver
> > gpiolib: support shared GPIOs in core subsystem code
> > gpio: provide gpiod_is_shared()
> > arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
> > ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
> > ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
> > regulator: make the subsystem aware of shared GPIOs
>
> this seems to actually have caused a regression for me, audio does not
> initialize anymore on hamoa due to EBUSY since upgrading
> from next-20251114 to next-20251118 or next-20251120:
>
Thanks for the heads-up.
> [ 11.748781] platform
> 6800000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 30
> [ 11.785864] wsa_macro 6aa0000.codec: using zero-initialized flat
> cache, this may cause unexpected behavior
> [ 11.796964] reset-gpio reset-gpio.0: error -EBUSY: Could not get
> reset gpios
> [ 11.796984] reset-gpio reset-gpio.0: probe with driver reset-gpio
> failed with error -16
> [ 11.894662] reset-gpio reset-gpio.1: error -EBUSY: Could not get
> reset gpios
> [ 11.894676] reset-gpio reset-gpio.1: probe with driver reset-gpio
> failed with error -16
It seems like it's the reset-gpio driver, not shared GPIOLIB path?
This driver has never used the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag.
> [ 12.006938] wcd938x_codec audio-codec: bound sdw:2:0:0217:010d:00:4
> (ops wcd_sdw_component_ops [snd_soc_wcd_common])
> [ 12.006964] wcd938x_codec audio-codec: bound sdw:3:0:0217:010d:00:3
> (ops wcd_sdw_component_ops [snd_soc_wcd_common])
> [ 15.424657] qcom-soundwire 6ab0000.soundwire: qcom_swrm_irq_handler:
> SWR CMD error, fifo status 0x4e00c00f, flushing fifo
> [ 21.994354] qcom-soundwire 6ab0000.soundwire: qcom_swrm_irq_handler:
> SWR CMD error, fifo status 0xe00c000, flushing fifo
> [ 21.996001] qcom-soundwire 6b10000.soundwire: qcom_swrm_irq_handler:
> SWR CMD error, fifo status 0x4e00c00f, flushing fifo
> [ 21.996239] platform sound: deferred probe pending: snd-x1e80100: WSA
> Playback: codec dai not found
> [ 21.996248] soundwire sdw:4:0:0217:0204:00:0: deferred probe pending:
> wsa884x-codec: Failed to get reset
> [ 21.996250] soundwire sdw:4:0:0217:0204:00:1: deferred probe pending:
> wsa884x-codec: Failed to get reset
> [ 21.996251] soundwire sdw:1:0:0217:0204:00:0: deferred probe pending:
> wsa884x-codec: Failed to get reset
> [ 21.996253] soundwire sdw:1:0:0217:0204:00:1: deferred probe pending:
> wsa884x-codec: Failed to get reset
>
> gpio_shared_proxy, reset_gpio, pinctrl_sm8550_lpass_lpi are all built as
> modules and were autoloaded fine.
>
> This is wsa884x (not wsa881x nor wsa883x), failing in
> devm_reset_control_get_optional_shared..
>
Can you enable DEBUG_GPIO in menuconfig and post the entire kernel log
somewhere as well as the output of gpiodetect and gpioinfo after
booting?
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-21 9:03 ` Bartosz Golaszewski
@ 2025-11-21 10:20 ` Krzysztof Kozlowski
0 siblings, 0 replies; 71+ messages in thread
From: Krzysztof Kozlowski @ 2025-11-21 10:20 UTC (permalink / raw)
To: Bartosz Golaszewski, Val Packett
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On 21/11/2025 10:03, Bartosz Golaszewski wrote:
> On Fri, Nov 21, 2025 at 1:28 AM Val Packett <val@packett.cool> wrote:
>>
>> Hi,
>>
>> On 11/12/25 10:55 AM, Bartosz Golaszewski wrote:
>>> ---
>>> Bartosz Golaszewski (10):
>>> string: provide strends()
>>> gpiolib: define GPIOD_FLAG_SHARED
>>> gpiolib: implement low-level, shared GPIO support
>>> gpio: shared-proxy: implement the shared GPIO proxy driver
>>> gpiolib: support shared GPIOs in core subsystem code
>>> gpio: provide gpiod_is_shared()
>>> arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
>>> ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
>>> ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
>>> regulator: make the subsystem aware of shared GPIOs
>>
>> this seems to actually have caused a regression for me, audio does not
>> initialize anymore on hamoa due to EBUSY since upgrading
>> from next-20251114 to next-20251118 or next-20251120:
>>
>
> Thanks for the heads-up.
>
>> [ 11.748781] platform
>> 6800000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 30
>> [ 11.785864] wsa_macro 6aa0000.codec: using zero-initialized flat
>> cache, this may cause unexpected behavior
>> [ 11.796964] reset-gpio reset-gpio.0: error -EBUSY: Could not get
>> reset gpios
>> [ 11.796984] reset-gpio reset-gpio.0: probe with driver reset-gpio
>> failed with error -16
>> [ 11.894662] reset-gpio reset-gpio.1: error -EBUSY: Could not get
>> reset gpios
>> [ 11.894676] reset-gpio reset-gpio.1: probe with driver reset-gpio
>> failed with error -16
>
> It seems like it's the reset-gpio driver, not shared GPIOLIB path?
> This driver has never used the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag.
NONEXCLUSIVE does not matter here. I think this is just broken code -
your patch 3 goes through allnodes for_each_property_of_node() and then
assumes it is shared GPIO, so probably this nicely breaks existing DTS
and reset-gpio. Well, it is not a shared GPIO, so all your assumptions
here are just wrong.
reset-gpio is already used on multiple Qualcomm and other SoC platforms.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
` (2 preceding siblings ...)
2025-11-18 14:06 ` Mark Brown
@ 2025-11-26 14:24 ` Jon Hunter
2025-11-26 14:28 ` Bartosz Golaszewski
2026-01-07 11:06 ` Pankaj Patil
4 siblings, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2025-11-26 14:24 UTC (permalink / raw)
To: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
Hi Bartosz,
On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Some qualcomm platforms use shared GPIOs. Enable support for them by
> selecting the Kconfig switch provided by GPIOLIB.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -316,6 +316,7 @@ config ARCH_QCOM
> select GPIOLIB
> select PINCTRL
> select HAVE_PWRCTRL if PCI
> + select HAVE_SHARED_GPIOS
> help
> This enables support for the ARMv8 based Qualcomm chipsets.
>
I have noticed the following kernel warning on our Tegra platforms ...
ERR KERN OF: /__symbols__: could not find phandle 794981747
Bisect is pointing to this commit and reverting this does prevent it. I
am not sure if anyone else has seen this?
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 14:24 ` Jon Hunter
@ 2025-11-26 14:28 ` Bartosz Golaszewski
2025-11-26 14:51 ` Jon Hunter
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 14:28 UTC (permalink / raw)
To: Jon Hunter
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Bartosz,
>
> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Some qualcomm platforms use shared GPIOs. Enable support for them by
> > selecting the Kconfig switch provided by GPIOLIB.
> >
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> > arch/arm64/Kconfig.platforms | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -316,6 +316,7 @@ config ARCH_QCOM
> > select GPIOLIB
> > select PINCTRL
> > select HAVE_PWRCTRL if PCI
> > + select HAVE_SHARED_GPIOS
> > help
> > This enables support for the ARMv8 based Qualcomm chipsets.
> >
>
> I have noticed the following kernel warning on our Tegra platforms ...
>
> ERR KERN OF: /__symbols__: could not find phandle 794981747
>
> Bisect is pointing to this commit and reverting this does prevent it. I
> am not sure if anyone else has seen this?
>
I assume it comes from drivers/of/base.c:1295 - could you please post
a stack trace of how you're getting there?
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 14:28 ` Bartosz Golaszewski
@ 2025-11-26 14:51 ` Jon Hunter
2025-11-26 14:54 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2025-11-26 14:51 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On 26/11/2025 14:28, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> Hi Bartosz,
>>
>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>> selecting the Kconfig switch provided by GPIOLIB.
>>>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>> ---
>>> arch/arm64/Kconfig.platforms | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>> --- a/arch/arm64/Kconfig.platforms
>>> +++ b/arch/arm64/Kconfig.platforms
>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>> select GPIOLIB
>>> select PINCTRL
>>> select HAVE_PWRCTRL if PCI
>>> + select HAVE_SHARED_GPIOS
>>> help
>>> This enables support for the ARMv8 based Qualcomm chipsets.
>>>
>>
>> I have noticed the following kernel warning on our Tegra platforms ...
>>
>> ERR KERN OF: /__symbols__: could not find phandle 794981747
>>
>> Bisect is pointing to this commit and reverting this does prevent it. I
>> am not sure if anyone else has seen this?
>>
>
> I assume it comes from drivers/of/base.c:1295 - could you please post
> a stack trace of how you're getting there?
Yes looks like it does and I see ...
[ 0.123356] OF: /__symbols__: could not find phandle 794981747
[ 0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
[ 0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[ 0.123447] Call trace:
[ 0.123453] show_stack+0x18/0x24 (C)
[ 0.123472] dump_stack_lvl+0x74/0x8c
[ 0.123487] dump_stack+0x18/0x24
[ 0.123518] of_phandle_iterator_next+0x18c/0x1c4
[ 0.123536] of_count_phandle_with_args+0xa0/0xc8
[ 0.123551] gpio_shared_of_traverse+0xb8/0x47c
[ 0.123566] gpio_shared_of_traverse+0x158/0x47c
[ 0.123578] gpio_shared_init+0x110/0x1f0
[ 0.123595] do_one_initcall+0x7c/0x1c0
[ 0.123607] kernel_init_freeable+0x204/0x2e0
[ 0.123622] kernel_init+0x20/0x1d8
[ 0.123637] ret_from_fork+0x10/0x20
Thanks
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 14:51 ` Jon Hunter
@ 2025-11-26 14:54 ` Bartosz Golaszewski
2025-11-26 14:55 ` Jon Hunter
2025-11-26 15:29 ` Jon Hunter
0 siblings, 2 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 14:54 UTC (permalink / raw)
To: Jon Hunter
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Wed, Nov 26, 2025 at 3:51 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 26/11/2025 14:28, Bartosz Golaszewski wrote:
> > On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>
> >> Hi Bartosz,
> >>
> >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>
> >>> Some qualcomm platforms use shared GPIOs. Enable support for them by
> >>> selecting the Kconfig switch provided by GPIOLIB.
> >>>
> >>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>> ---
> >>> arch/arm64/Kconfig.platforms | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> >>> --- a/arch/arm64/Kconfig.platforms
> >>> +++ b/arch/arm64/Kconfig.platforms
> >>> @@ -316,6 +316,7 @@ config ARCH_QCOM
> >>> select GPIOLIB
> >>> select PINCTRL
> >>> select HAVE_PWRCTRL if PCI
> >>> + select HAVE_SHARED_GPIOS
> >>> help
> >>> This enables support for the ARMv8 based Qualcomm chipsets.
> >>>
> >>
> >> I have noticed the following kernel warning on our Tegra platforms ...
> >>
> >> ERR KERN OF: /__symbols__: could not find phandle 794981747
> >>
> >> Bisect is pointing to this commit and reverting this does prevent it. I
> >> am not sure if anyone else has seen this?
> >>
> >
> > I assume it comes from drivers/of/base.c:1295 - could you please post
> > a stack trace of how you're getting there?
>
> Yes looks like it does and I see ...
>
> [ 0.123356] OF: /__symbols__: could not find phandle 794981747
> [ 0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
> [ 0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
> [ 0.123447] Call trace:
> [ 0.123453] show_stack+0x18/0x24 (C)
> [ 0.123472] dump_stack_lvl+0x74/0x8c
> [ 0.123487] dump_stack+0x18/0x24
> [ 0.123518] of_phandle_iterator_next+0x18c/0x1c4
> [ 0.123536] of_count_phandle_with_args+0xa0/0xc8
> [ 0.123551] gpio_shared_of_traverse+0xb8/0x47c
> [ 0.123566] gpio_shared_of_traverse+0x158/0x47c
> [ 0.123578] gpio_shared_init+0x110/0x1f0
> [ 0.123595] do_one_initcall+0x7c/0x1c0
> [ 0.123607] kernel_init_freeable+0x204/0x2e0
> [ 0.123622] kernel_init+0x20/0x1d8
> [ 0.123637] ret_from_fork+0x10/0x20
>
Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
Kconfig and post the entire kernel log on pastebin?
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 14:54 ` Bartosz Golaszewski
@ 2025-11-26 14:55 ` Jon Hunter
2025-11-26 15:05 ` Bartosz Golaszewski
2025-11-26 15:29 ` Jon Hunter
1 sibling, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2025-11-26 14:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On 26/11/2025 14:54, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 3:51 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> On 26/11/2025 14:28, Bartosz Golaszewski wrote:
>>> On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>
>>>> Hi Bartosz,
>>>>
>>>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>>>> selecting the Kconfig switch provided by GPIOLIB.
>>>>>
>>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>> ---
>>>>> arch/arm64/Kconfig.platforms | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>>>> select GPIOLIB
>>>>> select PINCTRL
>>>>> select HAVE_PWRCTRL if PCI
>>>>> + select HAVE_SHARED_GPIOS
>>>>> help
>>>>> This enables support for the ARMv8 based Qualcomm chipsets.
>>>>>
>>>>
>>>> I have noticed the following kernel warning on our Tegra platforms ...
>>>>
>>>> ERR KERN OF: /__symbols__: could not find phandle 794981747
>>>>
>>>> Bisect is pointing to this commit and reverting this does prevent it. I
>>>> am not sure if anyone else has seen this?
>>>>
>>>
>>> I assume it comes from drivers/of/base.c:1295 - could you please post
>>> a stack trace of how you're getting there?
>>
>> Yes looks like it does and I see ...
>>
>> [ 0.123356] OF: /__symbols__: could not find phandle 794981747
>> [ 0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
>> [ 0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
>> [ 0.123447] Call trace:
>> [ 0.123453] show_stack+0x18/0x24 (C)
>> [ 0.123472] dump_stack_lvl+0x74/0x8c
>> [ 0.123487] dump_stack+0x18/0x24
>> [ 0.123518] of_phandle_iterator_next+0x18c/0x1c4
>> [ 0.123536] of_count_phandle_with_args+0xa0/0xc8
>> [ 0.123551] gpio_shared_of_traverse+0xb8/0x47c
>> [ 0.123566] gpio_shared_of_traverse+0x158/0x47c
>> [ 0.123578] gpio_shared_init+0x110/0x1f0
>> [ 0.123595] do_one_initcall+0x7c/0x1c0
>> [ 0.123607] kernel_init_freeable+0x204/0x2e0
>> [ 0.123622] kernel_init+0x20/0x1d8
>> [ 0.123637] ret_from_fork+0x10/0x20
>>
>
> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> Kconfig and post the entire kernel log on pastebin?
Yes this is the upstream device-tree in
arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts. OK I will get the
entire log for review.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 14:55 ` Jon Hunter
@ 2025-11-26 15:05 ` Bartosz Golaszewski
0 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 15:05 UTC (permalink / raw)
To: Jon Hunter
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org, Bartosz Golaszewski
On Wed, 26 Nov 2025 15:55:54 +0100, Jon Hunter <jonathanh@nvidia.com> said:
>
>> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
>> Kconfig and post the entire kernel log on pastebin?
>
> Yes this is the upstream device-tree in
> arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts. OK I will get the
> entire log for review.
>
If you could also add the following:
diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
index 3803b5c938f99..51af7886d9f2d 100644
--- a/drivers/gpio/gpiolib-shared.c
+++ b/drivers/gpio/gpiolib-shared.c
@@ -101,6 +101,8 @@ static int gpio_shared_of_traverse(struct device_node *curr)
strcmp(prop->name, "gpio") != 0)
continue;
+ printk("%s: %pOF %s\n", __func__, curr, prop->name);
+
count = of_count_phandle_with_args(curr, prop->name,
"#gpio-cells");
if (count <= 0)
That would help me.
Bart
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 14:54 ` Bartosz Golaszewski
2025-11-26 14:55 ` Jon Hunter
@ 2025-11-26 15:29 ` Jon Hunter
2025-11-26 15:33 ` Bartosz Golaszewski
1 sibling, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2025-11-26 15:29 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On 26/11/2025 14:54, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 3:51 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> On 26/11/2025 14:28, Bartosz Golaszewski wrote:
>>> On Wed, Nov 26, 2025 at 3:24 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>
>>>> Hi Bartosz,
>>>>
>>>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>>>> selecting the Kconfig switch provided by GPIOLIB.
>>>>>
>>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>> ---
>>>>> arch/arm64/Kconfig.platforms | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>>>> select GPIOLIB
>>>>> select PINCTRL
>>>>> select HAVE_PWRCTRL if PCI
>>>>> + select HAVE_SHARED_GPIOS
>>>>> help
>>>>> This enables support for the ARMv8 based Qualcomm chipsets.
>>>>>
>>>>
>>>> I have noticed the following kernel warning on our Tegra platforms ...
>>>>
>>>> ERR KERN OF: /__symbols__: could not find phandle 794981747
>>>>
>>>> Bisect is pointing to this commit and reverting this does prevent it. I
>>>> am not sure if anyone else has seen this?
>>>>
>>>
>>> I assume it comes from drivers/of/base.c:1295 - could you please post
>>> a stack trace of how you're getting there?
>>
>> Yes looks like it does and I see ...
>>
>> [ 0.123356] OF: /__symbols__: could not find phandle 794981747
>> [ 0.123401] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #19 PREEMPT
>> [ 0.123418] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
>> [ 0.123447] Call trace:
>> [ 0.123453] show_stack+0x18/0x24 (C)
>> [ 0.123472] dump_stack_lvl+0x74/0x8c
>> [ 0.123487] dump_stack+0x18/0x24
>> [ 0.123518] of_phandle_iterator_next+0x18c/0x1c4
>> [ 0.123536] of_count_phandle_with_args+0xa0/0xc8
>> [ 0.123551] gpio_shared_of_traverse+0xb8/0x47c
>> [ 0.123566] gpio_shared_of_traverse+0x158/0x47c
>> [ 0.123578] gpio_shared_init+0x110/0x1f0
>> [ 0.123595] do_one_initcall+0x7c/0x1c0
>> [ 0.123607] kernel_init_freeable+0x204/0x2e0
>> [ 0.123622] kernel_init+0x20/0x1d8
>> [ 0.123637] ret_from_fork+0x10/0x20
>>
>
> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> Kconfig and post the entire kernel log on pastebin?
The kernel log is here: https://pastebin.com/7rBh3T3T
Thanks
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 15:29 ` Jon Hunter
@ 2025-11-26 15:33 ` Bartosz Golaszewski
2025-11-26 15:47 ` Jon Hunter
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 15:33 UTC (permalink / raw)
To: Jon Hunter
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Wed, Nov 26, 2025 at 4:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> >>
> >
> > Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> > Kconfig and post the entire kernel log on pastebin?
>
> The kernel log is here: https://pastebin.com/7rBh3T3T
This is not telling me much, can you try again with the printk() I
posted earlier, please?
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2025-11-12 13:55 ` [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support Bartosz Golaszewski
@ 2025-11-26 15:34 ` Cosmin Tanislav
2025-11-26 15:47 ` Bartosz Golaszewski
2026-03-11 18:38 ` Jon Hunter
1 sibling, 1 reply; 71+ messages in thread
From: Cosmin Tanislav @ 2025-11-26 15:34 UTC (permalink / raw)
To: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On 11/12/25 3:55 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> This module scans the device tree (for now only OF nodes are supported
> but care is taken to make other fwnode implementations easy to
> integrate) and determines which GPIO lines are shared by multiple users.
> It stores that information in memory. When the GPIO chip exposing shared
> lines is registered, the shared GPIO descriptors it exposes are marked
> as shared and virtual "proxy" devices that mediate access to the shared
> lines are created. When a consumer of a shared GPIO looks it up, its
> fwnode lookup is redirected to a just-in-time machine lookup that points
> to this proxy device.
>
> This code can be compiled out on platforms which don't use shared GPIOs.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> drivers/gpio/Kconfig | 8 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpiolib-shared.c | 540 ++++++++++++++++++++++++++++++++++++++++++
> drivers/gpio/gpiolib-shared.h | 71 ++++++
> 4 files changed, 620 insertions(+)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index ce237398fa00eddad49afe995accae3abbb4b2cb..f90b4d3e77f7cab46525b7adfcf114a21d276678 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -6,6 +6,9 @@
> config GPIOLIB_LEGACY
> def_bool y
>
> +config HAVE_SHARED_GPIOS
> + bool
> +
> menuconfig GPIOLIB
> bool "GPIO Support"
> help
> @@ -42,6 +45,11 @@ config GPIOLIB_IRQCHIP
> select IRQ_DOMAIN
> bool
>
> +config GPIO_SHARED
> + def_bool y
> + depends on HAVE_SHARED_GPIOS || COMPILE_TEST
> + select AUXILIARY_BUS
> +
> config DEBUG_GPIO
> bool "Debug GPIO calls"
> depends on DEBUG_KERNEL
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index ee260a0809d36cd07987f04e0ef17b05af764214..48f309c764e3286c23dbe604be933f7180f0b89a 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
> obj-$(CONFIG_GPIO_ACPI) += gpiolib-acpi.o
> gpiolib-acpi-y := gpiolib-acpi-core.o gpiolib-acpi-quirks.o
> obj-$(CONFIG_GPIOLIB) += gpiolib-swnode.o
> +obj-$(CONFIG_GPIO_SHARED) += gpiolib-shared.o
>
> # Device drivers. Generally keep list sorted alphabetically
> obj-$(CONFIG_GPIO_REGMAP) += gpio-regmap.o
> diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..56b9b03cbb6dbcdf095a656fc36ff321770035da
> --- /dev/null
> +++ b/drivers/gpio/gpiolib-shared.c
> @@ -0,0 +1,540 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2025 Linaro Ltd.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/cleanup.h>
> +#include <linux/device.h>
> +#include <linux/fwnode.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/gpio/machine.h>
> +#include <linux/idr.h>
> +#include <linux/kref.h>
> +#include <linux/list.h>
> +#include <linux/lockdep.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/overflow.h>
> +#include <linux/printk.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +
> +#include "gpiolib.h"
> +#include "gpiolib-shared.h"
> +
> +/* Represents a single reference to a GPIO pin. */
> +struct gpio_shared_ref {
> + struct list_head list;
> + /* Firmware node associated with this GPIO's consumer. */
> + struct fwnode_handle *fwnode;
> + /* GPIO flags this consumer uses for the request. */
> + enum gpiod_flags flags;
> + char *con_id;
> + int dev_id;
> + struct auxiliary_device adev;
> + struct gpiod_lookup_table *lookup;
> +};
> +
> +/* Represents a single GPIO pin. */
> +struct gpio_shared_entry {
> + struct list_head list;
> + /* Firmware node associated with the GPIO controller. */
> + struct fwnode_handle *fwnode;
> + /* Hardware offset of the GPIO within its chip. */
> + unsigned int offset;
> + /* Index in the property value array. */
> + size_t index;
> + struct gpio_shared_desc *shared_desc;
> + struct kref ref;
> + struct list_head refs;
> +};
> +
> +static LIST_HEAD(gpio_shared_list);
> +static DEFINE_MUTEX(gpio_shared_lock);
> +static DEFINE_IDA(gpio_shared_ida);
> +
> +static struct gpio_shared_entry *
> +gpio_shared_find_entry(struct fwnode_handle *controller_node,
> + unsigned int offset)
> +{
> + struct gpio_shared_entry *entry;
> +
> + list_for_each_entry(entry, &gpio_shared_list, list) {
> + if (entry->fwnode == controller_node && entry->offset == offset)
> + return entry;
> + }
> +
> + return NULL;
> +}
> +
> +#if IS_ENABLED(CONFIG_OF)
> +static int gpio_shared_of_traverse(struct device_node *curr)
> +{
> + struct gpio_shared_entry *entry;
> + size_t con_id_len, suffix_len;
> + struct fwnode_handle *fwnode;
> + struct of_phandle_args args;
> + struct property *prop;
> + unsigned int offset;
> + const char *suffix;
> + int ret, count, i;
> +
> + for_each_property_of_node(curr, prop) {
> + /*
> + * The standard name for a GPIO property is "foo-gpios"
> + * or "foo-gpio". Some bindings also use "gpios" or "gpio".
> + * There are some legacy device-trees which have a different
> + * naming convention and for which we have rename quirks in
> + * place in gpiolib-of.c. I don't think any of them require
> + * support for shared GPIOs so for now let's just ignore
> + * them. We can always just export the quirk list and
> + * iterate over it here.
> + */
> + if (!strends(prop->name, "-gpios") &&
> + !strends(prop->name, "-gpio") &&
> + strcmp(prop->name, "gpios") != 0 &&
> + strcmp(prop->name, "gpio") != 0)
> + continue;
> +
> + count = of_count_phandle_with_args(curr, prop->name,
> + "#gpio-cells");
This call causes error messages to be printed for gpio-hog entries, like
this one from arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi:
sdhi0-emmc-iovs-hog {
gpio-hog;
gpios = <RZT2H_GPIO(2, 6) GPIO_ACTIVE_HIGH>;
output-high;
line-name = "SD0_IOVS";
};
For gpio-hog entries, the first element is not a phandle (gpio-hog is
already under its parent).
of_count_phandle_with_args() will however try to interpret it as a
parent either way, causing the following error to be printed.
OF: /soc/pinctrl@802c0000/sdhi0-emmc-iovs-hog: could not get #gpio-cells
for /soc/ethernet@92010000/mdio/ethernet-phy@2
RZT2H_GPIO(2, 6) expands to 22, or 0x16.
Coincidentally, in the decompiled dts file we have:
ethernet-phy@2 {
...
phandle = <0x16>;
};
Maybe a check for gpio-hogs should be added?
Something like the following before the call to
of_count_phandle_with_args().
if (strcmp(prop->name, "gpios") == 0 &&
of_property_present(curr, "gpio-hog"))
continue;
> + if (count <= 0)
> + continue;
> +
> + for (i = 0; i < count; i++) {
> + struct device_node *np __free(device_node) = NULL;
> +
> + ret = of_parse_phandle_with_args(curr, prop->name,
> + "#gpio-cells", i,
> + &args);
> + if (ret)
> + continue;
> +
> + np = args.np;
> +
> + if (!of_property_present(np, "gpio-controller"))
> + continue;
> +
> + /*
> + * We support 1, 2 and 3 cell GPIO bindings in the
> + * kernel currently. There's only one old MIPS dts that
> + * has a one-cell binding but there's no associated
> + * consumer so it may as well be an error. There don't
> + * seem to be any 3-cell users of non-exclusive GPIOs,
> + * so we can skip this as well. Let's occupy ourselves
> + * with the predominant 2-cell binding with the first
> + * cell indicating the hardware offset of the GPIO and
> + * the second defining the GPIO flags of the request.
> + */
> + if (args.args_count != 2)
> + continue;
> +
> + fwnode = of_fwnode_handle(args.np);
> + offset = args.args[0];
> +
> + entry = gpio_shared_find_entry(fwnode, offset);
> + if (!entry) {
> + entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> + if (!entry)
> + return -ENOMEM;
> +
> + entry->fwnode = fwnode_handle_get(fwnode);
> + entry->offset = offset;
> + entry->index = count;
> + INIT_LIST_HEAD(&entry->refs);
> +
> + list_add_tail(&entry->list, &gpio_shared_list);
> + }
> +
> + struct gpio_shared_ref *ref __free(kfree) =
> + kzalloc(sizeof(*ref), GFP_KERNEL);
> + if (!ref)
> + return -ENOMEM;
> +
> + ref->fwnode = fwnode_handle_get(of_fwnode_handle(curr));
> + ref->flags = args.args[1];
> +
> + if (strends(prop->name, "gpios"))
> + suffix = "-gpios";
> + else if (strends(prop->name, "gpio"))
> + suffix = "-gpio";
> + else
> + suffix = NULL;
> + if (!suffix)
> + continue;
> +
> + /* We only set con_id if there's actually one. */
> + if (strcmp(prop->name, "gpios") && strcmp(prop->name, "gpio")) {
> + ref->con_id = kstrdup(prop->name, GFP_KERNEL);
> + if (!ref->con_id)
> + return -ENOMEM;
> +
> + con_id_len = strlen(ref->con_id);
> + suffix_len = strlen(suffix);
> +
> + ref->con_id[con_id_len - suffix_len] = '\0';
> + }
> +
> + ref->dev_id = ida_alloc(&gpio_shared_ida, GFP_KERNEL);
> + if (ref->dev_id < 0) {
> + kfree(ref->con_id);
> + return -ENOMEM;
> + }
> +
> + if (!list_empty(&entry->refs))
> + pr_debug("GPIO %u at %s is shared by multiple firmware nodes\n",
> + entry->offset, fwnode_get_name(entry->fwnode));
> +
> + list_add_tail(&no_free_ptr(ref)->list, &entry->refs);
> + }
> + }
> +
> + for_each_child_of_node_scoped(curr, child) {
> + ret = gpio_shared_of_traverse(child);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int gpio_shared_of_scan(void)
> +{
> + return gpio_shared_of_traverse(of_root);
> +}
> +#else
> +static int gpio_shared_of_scan(void)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static void gpio_shared_adev_release(struct device *dev)
> +{
> +
> +}
> +
> +static int gpio_shared_make_adev(struct gpio_device *gdev,
> + struct gpio_shared_ref *ref)
> +{
> + struct auxiliary_device *adev = &ref->adev;
> + int ret;
> +
> + lockdep_assert_held(&gpio_shared_lock);
> +
> + memset(adev, 0, sizeof(*adev));
> +
> + adev->id = ref->dev_id;
> + adev->name = "proxy";
> + adev->dev.parent = gdev->dev.parent;
> + adev->dev.release = gpio_shared_adev_release;
> +
> + ret = auxiliary_device_init(adev);
> + if (ret)
> + return ret;
> +
> + ret = auxiliary_device_add(adev);
> + if (ret) {
> + auxiliary_device_uninit(adev);
> + return ret;
> + }
> +
> + pr_debug("Created an auxiliary GPIO proxy %s for GPIO device %s\n",
> + dev_name(&adev->dev), gpio_device_get_label(gdev));
> +
> + return 0;
> +}
> +
> +int gpio_shared_add_proxy_lookup(struct device *consumer, unsigned long lflags)
> +{
> + const char *dev_id = dev_name(consumer);
> + struct gpio_shared_entry *entry;
> + struct gpio_shared_ref *ref;
> +
> + struct gpiod_lookup_table *lookup __free(kfree) =
> + kzalloc(struct_size(lookup, table, 2), GFP_KERNEL);
> + if (!lookup)
> + return -ENOMEM;
> +
> + guard(mutex)(&gpio_shared_lock);
> +
> + list_for_each_entry(entry, &gpio_shared_list, list) {
> + list_for_each_entry(ref, &entry->refs, list) {
> + if (!device_match_fwnode(consumer, ref->fwnode))
> + continue;
> +
> + /* We've already done that on a previous request. */
> + if (ref->lookup)
> + return 0;
> +
> + char *key __free(kfree) =
> + kasprintf(GFP_KERNEL,
> + KBUILD_MODNAME ".proxy.%u",
> + ref->adev.id);
> + if (!key)
> + return -ENOMEM;
> +
> + pr_debug("Adding machine lookup entry for a shared GPIO for consumer %s, with key '%s' and con_id '%s'\n",
> + dev_id, key, ref->con_id ?: "none");
> +
> + lookup->dev_id = dev_id;
> + lookup->table[0] = GPIO_LOOKUP(no_free_ptr(key), 0,
> + ref->con_id, lflags);
> +
> + gpiod_add_lookup_table(no_free_ptr(lookup));
> +
> + return 0;
> + }
> + }
> +
> + /* We warn here because this can only happen if the programmer borked. */
> + WARN_ON(1);
> + return -ENOENT;
> +}
> +
> +static void gpio_shared_remove_adev(struct auxiliary_device *adev)
> +{
> + lockdep_assert_held(&gpio_shared_lock);
> +
> + auxiliary_device_uninit(adev);
> + auxiliary_device_delete(adev);
> +}
> +
> +int gpio_device_setup_shared(struct gpio_device *gdev)
> +{
> + struct gpio_shared_entry *entry;
> + struct gpio_shared_ref *ref;
> + unsigned long *flags;
> + int ret;
> +
> + guard(mutex)(&gpio_shared_lock);
> +
> + list_for_each_entry(entry, &gpio_shared_list, list) {
> + if (!device_match_fwnode(&gdev->dev, entry->fwnode))
> + continue;
> +
> + if (list_count_nodes(&entry->refs) <= 1)
> + continue;
> +
> + flags = &gdev->descs[entry->offset].flags;
> +
> + __set_bit(GPIOD_FLAG_SHARED, flags);
> + /*
> + * Shared GPIOs are not requested via the normal path. Make
> + * them inaccessible to anyone even before we register the
> + * chip.
> + */
> + __set_bit(GPIOD_FLAG_REQUESTED, flags);
> +
> + pr_debug("GPIO %u owned by %s is shared by multiple consumers\n",
> + entry->offset, gpio_device_get_label(gdev));
> +
> + list_for_each_entry(ref, &entry->refs, list) {
> + pr_debug("Setting up a shared GPIO entry for %s\n",
> + fwnode_get_name(ref->fwnode));
> +
> + ret = gpio_shared_make_adev(gdev, ref);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +void gpio_device_teardown_shared(struct gpio_device *gdev)
> +{
> + struct gpio_shared_entry *entry;
> + struct gpio_shared_ref *ref;
> +
> + guard(mutex)(&gpio_shared_lock);
> +
> + list_for_each_entry(entry, &gpio_shared_list, list) {
> + if (!device_match_fwnode(&gdev->dev, entry->fwnode))
> + continue;
> +
> + list_for_each_entry(ref, &entry->refs, list) {
> + gpiod_remove_lookup_table(ref->lookup);
> + kfree(ref->lookup->table[0].key);
> + kfree(ref->lookup);
> + ref->lookup = NULL;
> + gpio_shared_remove_adev(&ref->adev);
> + }
> + }
> +}
> +
> +static void gpio_shared_release(struct kref *kref)
> +{
> + struct gpio_shared_entry *entry =
> + container_of(kref, struct gpio_shared_entry, ref);
> + struct gpio_shared_desc *shared_desc = entry->shared_desc;
> +
> + guard(mutex)(&gpio_shared_lock);
> +
> + gpio_device_put(shared_desc->desc->gdev);
> + if (shared_desc->can_sleep)
> + mutex_destroy(&shared_desc->mutex);
> + kfree(shared_desc);
> + entry->shared_desc = NULL;
> +}
> +
> +static void gpiod_shared_put(void *data)
> +{
> + struct gpio_shared_entry *entry = data;
> +
> + lockdep_assert_not_held(&gpio_shared_lock);
> +
> + kref_put(&entry->ref, gpio_shared_release);
> +}
> +
> +static struct gpio_shared_desc *
> +gpiod_shared_desc_create(struct gpio_shared_entry *entry)
> +{
> + struct gpio_shared_desc *shared_desc;
> + struct gpio_device *gdev;
> +
> + shared_desc = kzalloc(sizeof(*shared_desc), GFP_KERNEL);
> + if (!shared_desc)
> + return ERR_PTR(-ENOMEM);
> +
> + gdev = gpio_device_find_by_fwnode(entry->fwnode);
> + if (!gdev) {
> + kfree(shared_desc);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + shared_desc->desc = &gdev->descs[entry->offset];
> + shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> + if (shared_desc->can_sleep)
> + mutex_init(&shared_desc->mutex);
> + else
> + spin_lock_init(&shared_desc->spinlock);
> +
> + return shared_desc;
> +}
> +
> +static struct gpio_shared_entry *gpiod_shared_find(struct auxiliary_device *adev)
> +{
> + struct gpio_shared_desc *shared_desc;
> + struct gpio_shared_entry *entry;
> + struct gpio_shared_ref *ref;
> +
> + guard(mutex)(&gpio_shared_lock);
> +
> + list_for_each_entry(entry, &gpio_shared_list, list) {
> + list_for_each_entry(ref, &entry->refs, list) {
> + if (adev != &ref->adev)
> + continue;
> +
> + if (entry->shared_desc) {
> + kref_get(&entry->ref);
> + return entry;
> + }
> +
> + shared_desc = gpiod_shared_desc_create(entry);
> + if (IS_ERR(shared_desc))
> + return ERR_CAST(shared_desc);
> +
> + kref_init(&entry->ref);
> + entry->shared_desc = shared_desc;
> +
> + pr_debug("Device %s acquired a reference to the shared GPIO %u owned by %s\n",
> + dev_name(&adev->dev), gpiod_hwgpio(shared_desc->desc),
> + gpio_device_get_label(shared_desc->desc->gdev));
> +
> +
> + return entry;
> + }
> + }
> +
> + return ERR_PTR(-ENOENT);
> +}
> +
> +struct gpio_shared_desc *devm_gpiod_shared_get(struct device *dev)
> +{
> + struct gpio_shared_entry *entry;
> + int ret;
> +
> + entry = gpiod_shared_find(to_auxiliary_dev(dev));
> + if (IS_ERR(entry))
> + return ERR_CAST(entry);
> +
> + ret = devm_add_action_or_reset(dev, gpiod_shared_put, entry);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + return entry->shared_desc;
> +}
> +EXPORT_SYMBOL_GPL(devm_gpiod_shared_get);
> +
> +static void gpio_shared_drop_ref(struct gpio_shared_ref *ref)
> +{
> + list_del(&ref->list);
> + kfree(ref->con_id);
> + ida_free(&gpio_shared_ida, ref->dev_id);
> + fwnode_handle_put(ref->fwnode);
> + kfree(ref);
> +}
> +
> +static void gpio_shared_drop_entry(struct gpio_shared_entry *entry)
> +{
> + list_del(&entry->list);
> + fwnode_handle_put(entry->fwnode);
> + kfree(entry);
> +}
> +
> +/*
> + * This is only called if gpio_shared_init() fails so it's in fact __init and
> + * not __exit.
> + */
> +static void __init gpio_shared_teardown(void)
> +{
> + struct gpio_shared_entry *entry, *epos;
> + struct gpio_shared_ref *ref, *rpos;
> +
> + list_for_each_entry_safe(entry, epos, &gpio_shared_list, list) {
> + list_for_each_entry_safe(ref, rpos, &entry->refs, list)
> + gpio_shared_drop_ref(ref);
> +
> + gpio_shared_drop_entry(entry);
> + }
> +}
> +
> +static void gpio_shared_free_exclusive(void)
> +{
> + struct gpio_shared_entry *entry, *epos;
> +
> + list_for_each_entry_safe(entry, epos, &gpio_shared_list, list) {
> + if (list_count_nodes(&entry->refs) > 1)
> + continue;
> +
> + gpio_shared_drop_ref(list_first_entry(&entry->refs,
> + struct gpio_shared_ref,
> + list));
> + gpio_shared_drop_entry(entry);
> + }
> +}
> +
> +static int __init gpio_shared_init(void)
> +{
> + int ret;
> +
> + /* Right now, we only support OF-based systems. */
> + ret = gpio_shared_of_scan();
> + if (ret) {
> + gpio_shared_teardown();
> + pr_err("Failed to scan OF nodes for shared GPIOs: %d\n", ret);
> + return ret;
> + }
> +
> + gpio_shared_free_exclusive();
> +
> + pr_debug("Finished scanning firmware nodes for shared GPIOs\n");
> + return 0;
> +}
> +postcore_initcall(gpio_shared_init);
> diff --git a/drivers/gpio/gpiolib-shared.h b/drivers/gpio/gpiolib-shared.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..667dbdff3585066b7cbe2ebe476725fe7d683d84
> --- /dev/null
> +++ b/drivers/gpio/gpiolib-shared.h
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __LINUX_GPIO_SHARED_H
> +#define __LINUX_GPIO_SHARED_H
> +
> +#include <linux/cleanup.h>
> +#include <linux/lockdep.h>
> +#include <linux/mutex.h>
> +#include <linux/spinlock.h>
> +
> +struct gpio_device;
> +struct gpio_desc;
> +struct device;
> +
> +#if IS_ENABLED(CONFIG_GPIO_SHARED)
> +
> +int gpio_device_setup_shared(struct gpio_device *gdev);
> +void gpio_device_teardown_shared(struct gpio_device *gdev);
> +int gpio_shared_add_proxy_lookup(struct device *consumer, unsigned long lflags);
> +
> +#else
> +
> +static inline int gpio_device_setup_shared(struct gpio_device *gdev)
> +{
> + return 0;
> +}
> +
> +static inline void gpio_device_teardown_shared(struct gpio_device *gdev) { }
> +
> +static inline int gpio_shared_add_proxy_lookup(struct device *consumer,
> + unsigned long lflags)
> +{
> + return 0;
> +}
> +
> +#endif /* CONFIG_GPIO_SHARED */
> +
> +struct gpio_shared_desc {
> + struct gpio_desc *desc;
> + bool can_sleep;
> + unsigned long cfg;
> + unsigned int usecnt;
> + unsigned int highcnt;
> + union {
> + struct mutex mutex;
> + spinlock_t spinlock;
> + };
> +};
> +
> +struct gpio_shared_desc *devm_gpiod_shared_get(struct device *dev);
> +
> +DEFINE_LOCK_GUARD_1(gpio_shared_desc_lock, struct gpio_shared_desc,
> + if (_T->lock->can_sleep)
> + mutex_lock(&_T->lock->mutex);
> + else
> + spin_lock_irqsave(&_T->lock->spinlock, _T->flags),
> + if (_T->lock->can_sleep)
> + mutex_unlock(&_T->lock->mutex);
> + else
> + spin_unlock_irqrestore(&_T->lock->spinlock, _T->flags),
> + unsigned long flags)
> +
> +static inline void gpio_shared_lockdep_assert(struct gpio_shared_desc *shared_desc)
> +{
> + if (shared_desc->can_sleep)
> + lockdep_assert_held(&shared_desc->mutex);
> + else
> + lockdep_assert_held(&shared_desc->spinlock);
> +}
> +
> +#endif /* __LINUX_GPIO_SHARED_H */
>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 15:33 ` Bartosz Golaszewski
@ 2025-11-26 15:47 ` Jon Hunter
2025-11-26 16:00 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2025-11-26 15:47 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On 26/11/2025 15:33, Bartosz Golaszewski wrote:
> On Wed, Nov 26, 2025 at 4:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>>>
>>>
>>> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
>>> Kconfig and post the entire kernel log on pastebin?
>>
>> The kernel log is here: https://pastebin.com/7rBh3T3T
>
> This is not telling me much, can you try again with the printk() I
> posted earlier, please?
Yes, sorry I missed that before kicking off the last test. With
this print I see ...
[ 0.120432] gpio_shared_of_traverse: /bus@0/ethernet@2490000 phy-reset-gpios
[ 0.121407] gpio_shared_of_traverse: /bus@0/mmc@3400000 cd-gpios
[ 0.121891] gpio_shared_of_traverse: /bus@0/host1x@13e00000/sor@15b80000 nvidia,hpd-gpio
[ 0.122035] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 reset-gpios
[ 0.122075] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 nvidia,refclk-select-gpios
[ 0.122342] gpio_shared_of_traverse: /regulator-vdd-hdmi gpio
[ 0.122381] gpio_shared_of_traverse: /regulator-vdd-3v3-pcie gpio
[ 0.122420] gpio_shared_of_traverse: /regulator-vdd-12v-pcie gpio
[ 0.122453] gpio_shared_of_traverse: /regulator-vdd-5v0-sata gpio
[ 0.122486] gpio_shared_of_traverse: /gpio-keys/key-force-recovery gpios
[ 0.122551] gpio_shared_of_traverse: /gpio-keys/key-power gpios
[ 0.122615] gpio_shared_of_traverse: /__symbols__ gpio
[ 0.122672] OF: /__symbols__: could not find phandle 794981747
[ 0.122701] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #21 PREEMPT
[ 0.122739] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[ 0.122747] Call trace:
[ 0.122753] show_stack+0x18/0x24 (C)
[ 0.122772] dump_stack_lvl+0x74/0x8c
[ 0.122788] dump_stack+0x18/0x24
[ 0.122801] of_phandle_iterator_next+0x18c/0x1c4
[ 0.122819] of_count_phandle_with_args+0xa0/0xc8
[ 0.122832] gpio_shared_of_traverse+0xd4/0x4c8
[ 0.122848] gpio_shared_of_traverse+0x178/0x4c8
[ 0.122860] gpio_shared_init+0x11c/0x1f8
[ 0.122878] do_one_initcall+0x7c/0x1c0
[ 0.122892] kernel_init_freeable+0x204/0x2e0
[ 0.122908] kernel_init+0x20/0x1d8
[ 0.122923] ret_from_fork+0x10/0x20
[ 0.123055] gpiolib_shared: Finished scanning firmware nodes for shared GPIOs
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2025-11-26 15:34 ` Cosmin Tanislav
@ 2025-11-26 15:47 ` Bartosz Golaszewski
0 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 15:47 UTC (permalink / raw)
To: Cosmin Tanislav
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Nov 26, 2025 at 4:34 PM Cosmin Tanislav <demonsingur@gmail.com> wrote:
>
> > +
> > + count = of_count_phandle_with_args(curr, prop->name,
> > + "#gpio-cells");
>
> This call causes error messages to be printed for gpio-hog entries, like
> this one from arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi:
>
Thanks for the report.
Please trim your responses to just the relevant context though, you
included the entire huge patch.
> sdhi0-emmc-iovs-hog {
> gpio-hog;
> gpios = <RZT2H_GPIO(2, 6) GPIO_ACTIVE_HIGH>;
> output-high;
> line-name = "SD0_IOVS";
> };
>
> For gpio-hog entries, the first element is not a phandle (gpio-hog is
> already under its parent).
>
> of_count_phandle_with_args() will however try to interpret it as a
> parent either way, causing the following error to be printed.
>
> OF: /soc/pinctrl@802c0000/sdhi0-emmc-iovs-hog: could not get #gpio-cells
> for /soc/ethernet@92010000/mdio/ethernet-phy@2
>
> RZT2H_GPIO(2, 6) expands to 22, or 0x16.
>
> Coincidentally, in the decompiled dts file we have:
>
> ethernet-phy@2 {
> ...
> phandle = <0x16>;
> };
>
Yes, because behind the scenes, a phandle really is nothing more than
an integer.
> Maybe a check for gpio-hogs should be added?
>
> Something like the following before the call to
> of_count_phandle_with_args().
>
> if (strcmp(prop->name, "gpios") == 0 &&
> of_property_present(curr, "gpio-hog"))
> continue;
>
Yes, that's a good idea, thanks. Let me cook up a patch.
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-26 15:47 ` Jon Hunter
@ 2025-11-26 16:00 ` Bartosz Golaszewski
0 siblings, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 16:00 UTC (permalink / raw)
To: Jon Hunter
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Wed, Nov 26, 2025 at 4:47 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
>
> On 26/11/2025 15:33, Bartosz Golaszewski wrote:
> > On Wed, Nov 26, 2025 at 4:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>
> >>>>
> >>>
> >>> Is the device-tree used here upstream? Can you enable DEBUG_GPIO in
> >>> Kconfig and post the entire kernel log on pastebin?
> >>
> >> The kernel log is here: https://pastebin.com/7rBh3T3T
> >
> > This is not telling me much, can you try again with the printk() I
> > posted earlier, please?
>
> Yes, sorry I missed that before kicking off the last test. With
> this print I see ...
>
> [ 0.120432] gpio_shared_of_traverse: /bus@0/ethernet@2490000 phy-reset-gpios
> [ 0.121407] gpio_shared_of_traverse: /bus@0/mmc@3400000 cd-gpios
> [ 0.121891] gpio_shared_of_traverse: /bus@0/host1x@13e00000/sor@15b80000 nvidia,hpd-gpio
> [ 0.122035] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 reset-gpios
> [ 0.122075] gpio_shared_of_traverse: /bus@0/pcie-ep@141a0000 nvidia,refclk-select-gpios
> [ 0.122342] gpio_shared_of_traverse: /regulator-vdd-hdmi gpio
> [ 0.122381] gpio_shared_of_traverse: /regulator-vdd-3v3-pcie gpio
> [ 0.122420] gpio_shared_of_traverse: /regulator-vdd-12v-pcie gpio
> [ 0.122453] gpio_shared_of_traverse: /regulator-vdd-5v0-sata gpio
> [ 0.122486] gpio_shared_of_traverse: /gpio-keys/key-force-recovery gpios
> [ 0.122551] gpio_shared_of_traverse: /gpio-keys/key-power gpios
> [ 0.122615] gpio_shared_of_traverse: /__symbols__ gpio
So I have no idea why the special __symbols__ node has a "gpio"
property but as this is a special case, I think we should just
explicitly ignore it.
Let me send a patch.
Bart
> [ 0.122672] OF: /__symbols__: could not find phandle 794981747
> [ 0.122701] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc7-next-20251126-00002-g1cd98992c487-dirty #21 PREEMPT
> [ 0.122739] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
> [ 0.122747] Call trace:
> [ 0.122753] show_stack+0x18/0x24 (C)
> [ 0.122772] dump_stack_lvl+0x74/0x8c
> [ 0.122788] dump_stack+0x18/0x24
> [ 0.122801] of_phandle_iterator_next+0x18c/0x1c4
> [ 0.122819] of_count_phandle_with_args+0xa0/0xc8
> [ 0.122832] gpio_shared_of_traverse+0xd4/0x4c8
> [ 0.122848] gpio_shared_of_traverse+0x178/0x4c8
> [ 0.122860] gpio_shared_init+0x11c/0x1f8
> [ 0.122878] do_one_initcall+0x7c/0x1c0
> [ 0.122892] kernel_init_freeable+0x204/0x2e0
> [ 0.122908] kernel_init+0x20/0x1d8
> [ 0.122923] ret_from_fork+0x10/0x20
> [ 0.123055] gpiolib_shared: Finished scanning firmware nodes for shared GPIOs
>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (14 preceding siblings ...)
2025-11-21 0:27 ` Val Packett
@ 2025-11-26 16:27 ` Dmitry Baryshkov
2025-11-26 16:49 ` Bartosz Golaszewski
2026-01-07 11:47 ` Manivannan Sadhasivam
2026-01-08 14:46 ` Michael Walle
16 siblings, 2 replies; 71+ messages in thread
From: Dmitry Baryshkov @ 2025-11-26 16:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Nov 12, 2025 at 02:55:29PM +0100, Bartosz Golaszewski wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> Problem statement: GPIOs are implemented as a strictly exclusive
> resource in the kernel but there are lots of platforms on which single
> pin is shared by multiple devices which don't communicate so need some
> way of properly sharing access to a GPIO. What we have now is the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> doesn't do any locking or arbitration of access - it literally just hand
> the same GPIO descriptor to all interested users.
>
> The proposed solution is composed of three major parts: the high-level,
> shared GPIO proxy driver that arbitrates access to the shared pin and
> exposes a regular GPIO chip interface to consumers, a low-level shared
> GPIOLIB module that scans firmware nodes and creates auxiliary devices
> that attach to the proxy driver and finally a set of core GPIOLIB
> changes that plug the former into the GPIO lookup path.
>
> The changes are implemented in a way that allows to seamlessly compile
> out any code related to sharing GPIOs for systems that don't need it.
>
> The practical use-case for this are the powerdown GPIOs shared by
> speakers on Qualcomm db845c platform, however I have also extensively
> tested it using gpio-virtuser on arm64 qemu with various DT
> configurations.
>
> I'm Cc'ing some people that may help with reviewing/be interested in
> this: OF maintainers (because the main target are OF systems initially),
> Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> in audio or regulator drivers and one of the goals of this series is
> dropping the hand-crafted GPIO enable counting via struct
> regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> to also cover ACPI (even though I don't know about any ACPI platform that
> would need this at the moment, I think it makes sense to make the
> solution complete), Dmitry (same thing but for software nodes), Mani
> (because you have a somewhat related use-case for the PERST# signal and
> I'd like to hear your input on whether this is something you can use or
> maybe it needs a separate, implicit gpio-perst driver similar to what
> Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> last week in person and I also use the auxiliary bus for the proxy
> devices).
Hi,
I'm sorry if this was already reported and fixed. On Qualcomm RB5
platform with this patchset in place I'm getting the following backtrace
(and then a lockup):
[ 4.298346] gpiolib_shared: GPIO 130 owned by f100000.pinctrl is shared by multiple consumers
[ 4.307157] gpiolib_shared: Setting up a shared GPIO entry for speaker@0,3
[ 4.314604]
[ 4.316146] ============================================
[ 4.321600] WARNING: possible recursive locking detected
[ 4.327054] 6.18.0-rc7-next-20251125-g3f300d0674f6-dirty #3887 Not tainted
[ 4.334115] --------------------------------------------
[ 4.339566] kworker/u32:3/71 is trying to acquire lock:
[ 4.344931] ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: devm_gpiod_shared_get+0x34/0x2e0
[ 4.354057]
[ 4.354057] but task is already holding lock:
[ 4.360041] ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: gpio_device_setup_shared+0x30/0x268
[ 4.369421]
[ 4.369421] other info that might help us debug this:
[ 4.376126] Possible unsafe locking scenario:
[ 4.376126]
[ 4.382198] CPU0
[ 4.384711] ----
[ 4.387223] lock(gpio_shared_lock);
[ 4.390992] lock(gpio_shared_lock);
[ 4.394761]
[ 4.394761] *** DEADLOCK ***
[ 4.394761]
[ 4.400832] May be due to missing lock nesting notation
[ 4.400832]
[ 4.407802] 5 locks held by kworker/u32:3/71:
[ 4.412279] #0: ffff000080020948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x194/0x64c
[ 4.422650] #1: ffff800080963d60 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1bc/0x64c
[ 4.432117] #2: ffff00008165c8f8 (&dev->mutex){....}-{4:4}, at: __device_attach+0x3c/0x198
[ 4.440700] #3: ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: gpio_device_setup_shared+0x30/0x268
[ 4.450523] #4: ffff0000810fe918 (&dev->mutex){....}-{4:4}, at: __device_attach+0x3c/0x198
[ 4.459103]
[ 4.459103] stack backtrace:
[ 4.463581] CPU: 6 UID: 0 PID: 71 Comm: kworker/u32:3 Not tainted 6.18.0-rc7-next-20251125-g3f300d0674f6-dirty #3887 PREEMPT
[ 4.463589] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 4.463593] Workqueue: events_unbound deferred_probe_work_func
[ 4.463602] Call trace:
[ 4.463604] show_stack+0x18/0x24 (C)
[ 4.463617] dump_stack_lvl+0x70/0x98
[ 4.463627] dump_stack+0x18/0x24
[ 4.463636] print_deadlock_bug+0x224/0x238
[ 4.463643] __lock_acquire+0xe4c/0x15f0
[ 4.463648] lock_acquire+0x1cc/0x344
[ 4.463653] __mutex_lock+0xb8/0x840
[ 4.463661] mutex_lock_nested+0x24/0x30
[ 4.463667] devm_gpiod_shared_get+0x34/0x2e0
[ 4.463674] gpio_shared_proxy_probe+0x18/0x138
[ 4.463682] auxiliary_bus_probe+0x40/0x78
[ 4.463688] really_probe+0xbc/0x2c0
[ 4.463694] __driver_probe_device+0x78/0x120
[ 4.463701] driver_probe_device+0x3c/0x160
[ 4.463708] __device_attach_driver+0xb8/0x140
[ 4.463716] bus_for_each_drv+0x88/0xe8
[ 4.463723] __device_attach+0xa0/0x198
[ 4.463729] device_initial_probe+0x14/0x20
[ 4.463737] bus_probe_device+0xb4/0xc0
[ 4.463743] device_add+0x578/0x76c
[ 4.463747] __auxiliary_device_add+0x40/0xac
[ 4.463752] gpio_device_setup_shared+0x1f8/0x268
[ 4.463758] gpiochip_add_data_with_key+0xdac/0x10ac
[ 4.463763] devm_gpiochip_add_data_with_key+0x30/0x80
[ 4.463768] msm_pinctrl_probe+0x4b0/0x5e0
[ 4.463779] sm8250_pinctrl_probe+0x18/0x40
[ 4.463784] platform_probe+0x5c/0xa4
[ 4.463793] really_probe+0xbc/0x2c0
[ 4.463800] __driver_probe_device+0x78/0x120
[ 4.463807] driver_probe_device+0x3c/0x160
[ 4.463814] __device_attach_driver+0xb8/0x140
[ 4.463821] bus_for_each_drv+0x88/0xe8
[ 4.463827] __device_attach+0xa0/0x198
[ 4.463834] device_initial_probe+0x14/0x20
[ 4.463841] bus_probe_device+0xb4/0xc0
[ 4.463847] deferred_probe_work_func+0x90/0xcc
[ 4.463854] process_one_work+0x214/0x64c
[ 4.463860] worker_thread+0x1bc/0x360
[ 4.463866] kthread+0x14c/0x220
[ 4.463871] ret_from_fork+0x10/0x20
[ 77.265041] random: crng init done
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> Changes in v4:
> - Collect tags
> - Extend Cc list
> - Link to v3: https://lore.kernel.org/r/20251029-gpio-shared-v3-0-71c568acf47c@linaro.org
>
> Changes in v3:
> - Make strends() a static inline function
> - Use an empty release() callback for auxiliary devices
> - Refactor the code for finding the shared descriptors in the GPIOLIB
> shared module, split it into several smaller functions
> - Use str_high_low() where applicable
> - Use non-atomic bit ops where atomicity is not required
> - Link to v2: https://lore.kernel.org/r/20251022-gpio-shared-v2-0-d34aa1fbdf06@linaro.org
>
> Changes in v2:
> - Fix a memory leak in error path in gpiolib-shared
> - Drop the gpio-wcd934x fix that already went upstream
> - Free resources used during scanning by GPIOs that turned out to be
> unique
> - Rework the OF property scanning
> - Add patches making the regulator subsystem aware of shared GPIOs
> managed by GPIOLIB
> - Link to v1: https://lore.kernel.org/r/20250924-gpio-shared-v1-0-775e7efeb1a3@linaro.org
>
> ---
> Bartosz Golaszewski (10):
> string: provide strends()
> gpiolib: define GPIOD_FLAG_SHARED
> gpiolib: implement low-level, shared GPIO support
> gpio: shared-proxy: implement the shared GPIO proxy driver
> gpiolib: support shared GPIOs in core subsystem code
> gpio: provide gpiod_is_shared()
> arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
> ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
> ASoC: wsa883x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup
> regulator: make the subsystem aware of shared GPIOs
>
> arch/arm64/Kconfig.platforms | 1 +
> drivers/gpio/Kconfig | 17 ++
> drivers/gpio/Makefile | 2 +
> drivers/gpio/gpio-shared-proxy.c | 333 +++++++++++++++++++++++
> drivers/gpio/gpiolib-shared.c | 558 +++++++++++++++++++++++++++++++++++++++
> drivers/gpio/gpiolib-shared.h | 71 +++++
> drivers/gpio/gpiolib.c | 70 ++++-
> drivers/gpio/gpiolib.h | 2 +
> drivers/regulator/core.c | 8 +
> include/linux/gpio/consumer.h | 9 +
> include/linux/string.h | 18 ++
> lib/tests/string_kunit.c | 13 +
> sound/soc/codecs/wsa881x.c | 3 +-
> sound/soc/codecs/wsa883x.c | 7 +-
> 14 files changed, 1096 insertions(+), 16 deletions(-)
> ---
> base-commit: 96bf1bb63977b67d1a3e4a3645f857bc3fa03f48
> change-id: 20250908-gpio-shared-67ec352884b6
>
> Best regards,
> --
> Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-26 16:27 ` Dmitry Baryshkov
@ 2025-11-26 16:49 ` Bartosz Golaszewski
2026-01-07 11:47 ` Manivannan Sadhasivam
1 sibling, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2025-11-26 16:49 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Nov 26, 2025 at 5:27 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> I'm sorry if this was already reported and fixed. On Qualcomm RB5
> platform with this patchset in place I'm getting the following backtrace
> (and then a lockup):
>
> [ 4.298346] gpiolib_shared: GPIO 130 owned by f100000.pinctrl is shared by multiple consumers
> [ 4.307157] gpiolib_shared: Setting up a shared GPIO entry for speaker@0,3
> [ 4.314604]
> [ 4.316146] ============================================
> [ 4.321600] WARNING: possible recursive locking detected
> [ 4.327054] 6.18.0-rc7-next-20251125-g3f300d0674f6-dirty #3887 Not tainted
> [ 4.334115] --------------------------------------------
> [ 4.339566] kworker/u32:3/71 is trying to acquire lock:
> [ 4.344931] ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: devm_gpiod_shared_get+0x34/0x2e0
> [ 4.354057]
> [ 4.354057] but task is already holding lock:
> [ 4.360041] ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: gpio_device_setup_shared+0x30/0x268
> [ 4.369421]
Ah, I missed the use-case where the auxiliary device is bound right
after it gets added and we're still holding the shared_gpio_lock. I
think we should prepare the proxy devices but only add them after
releasing the lock. I will fix it first thing tomorrow morning.
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
` (3 preceding siblings ...)
2025-11-26 14:24 ` Jon Hunter
@ 2026-01-07 11:06 ` Pankaj Patil
2026-01-07 12:38 ` Bartosz Golaszewski
4 siblings, 1 reply; 71+ messages in thread
From: Pankaj Patil @ 2026-01-07 11:06 UTC (permalink / raw)
To: Bartosz Golaszewski, Linus Walleij, Manivannan Sadhasivam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio
Cc: linux-gpio, linux-arm-kernel, linux-arm-msm
On 11/12/2025 7:25 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Some qualcomm platforms use shared GPIOs. Enable support for them by
> selecting the Kconfig switch provided by GPIOLIB.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -316,6 +316,7 @@ config ARCH_QCOM
> select GPIOLIB
> select PINCTRL
> select HAVE_PWRCTRL if PCI
> + select HAVE_SHARED_GPIOS
> help
> This enables support for the ARMv8 based Qualcomm chipsets.
>
>
Enabling shared gpios is breaking hamoa and glymur boot on next-20260106
For hamoa - reg_fixed_voltage_probe which calls gpio api is breaking
Please find the log here - https://lava-oss.qualcomm.com/scheduler/job/24722#L3514
For Glymur - qcom_pcie_parse_perst calls the gpio api <4>[ 2.910982] WARNING: drivers/gpio/gpiolib-shared.c:493 at gpio_shared_add_proxy_lookup+0x160/0x24c, CPU#1: kworker/u75:0/109 <4>[ 2.911027] Call trace: <4>[ 2.911028] gpio_shared_add_proxy_lookup+0x160/0x24c (P) <4>[ 2.911030] gpiod_find_and_request+0x1c0/0x504 <4>[ 2.911032] devm_fwnode_gpiod_get_index+0x1c/0x6c <4>[ 2.911034] qcom_pcie_parse_perst+0x70/0x150 <4>[ 2.911037] qcom_pcie_probe+0x414/0x804 <4>[ 2.911039] platform_probe+0x5c/0x98 <4>[ 2.911042] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd18 not found, using dummy regulator <4>[ 2.911043] really_probe+0xbc/0x298 <4>[ 2.911045] __driver_probe_device+0x78/0x12c <4>[ 2.911047] driver_probe_device+0x3c/0x15c <4>[ 2.911049] __device_attach_driver+0xb8/0x134 <4>[ 2.911050] bus_for_each_drv+0x84/0xe0 <4>[ 2.911052] __device_attach_async_helper+0xac/0xd0 <4>[ 2.911053] async_run_entry_fn+0x34/0xe0
<4>[ 2.911055] process_one_work+0x14c/0x28c <4>[ 2.911058] worker_thread+0x188/0x304 <4>[ 2.911059] kthread+0x11c/0x128 <4>[ 2.911060] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd3 not found, using dummy regulator <4>[ 2.911061] ret_from_fork+0x10/0x20 <4>[ 2.911063] ---[ end trace 0000000000000000 ]--- <3>[ 2.911065] qcom-pcie 1b40000.pci: error -ENOENT: Failed to parse Root Port: -2 <3>[ 2.911069] qcom-pcie 1b40000.pci: probe with driver qcom-pcie failed with error -2
Reverting this commit fixes the boot on both platforms
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-26 16:27 ` Dmitry Baryshkov
2025-11-26 16:49 ` Bartosz Golaszewski
@ 2026-01-07 11:47 ` Manivannan Sadhasivam
2026-01-07 12:12 ` Dmitry Baryshkov
1 sibling, 1 reply; 71+ messages in thread
From: Manivannan Sadhasivam @ 2026-01-07 11:47 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski, Dmitry Baryshkov
On Wed, Nov 26, 2025 at 06:27:13PM +0200, Dmitry Baryshkov wrote:
> On Wed, Nov 12, 2025 at 02:55:29PM +0100, Bartosz Golaszewski wrote:
> > Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> > came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> > this series however impacts Qualcomm platforms. It's a runtime dependency
> > of patches 8 and 9. Would you mind Acking it so that I can take it into
> > an immutable branch that I'll make available to Mark Brown for him to
> > take patches 8-10 through the ASoC and regulator trees for v6.19?
> >
> > Problem statement: GPIOs are implemented as a strictly exclusive
> > resource in the kernel but there are lots of platforms on which single
> > pin is shared by multiple devices which don't communicate so need some
> > way of properly sharing access to a GPIO. What we have now is the
> > GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> > doesn't do any locking or arbitration of access - it literally just hand
> > the same GPIO descriptor to all interested users.
> >
> > The proposed solution is composed of three major parts: the high-level,
> > shared GPIO proxy driver that arbitrates access to the shared pin and
> > exposes a regular GPIO chip interface to consumers, a low-level shared
> > GPIOLIB module that scans firmware nodes and creates auxiliary devices
> > that attach to the proxy driver and finally a set of core GPIOLIB
> > changes that plug the former into the GPIO lookup path.
> >
> > The changes are implemented in a way that allows to seamlessly compile
> > out any code related to sharing GPIOs for systems that don't need it.
> >
> > The practical use-case for this are the powerdown GPIOs shared by
> > speakers on Qualcomm db845c platform, however I have also extensively
> > tested it using gpio-virtuser on arm64 qemu with various DT
> > configurations.
> >
> > I'm Cc'ing some people that may help with reviewing/be interested in
> > this: OF maintainers (because the main target are OF systems initially),
> > Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> > in audio or regulator drivers and one of the goals of this series is
> > dropping the hand-crafted GPIO enable counting via struct
> > regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> > to also cover ACPI (even though I don't know about any ACPI platform that
> > would need this at the moment, I think it makes sense to make the
> > solution complete), Dmitry (same thing but for software nodes), Mani
> > (because you have a somewhat related use-case for the PERST# signal and
> > I'd like to hear your input on whether this is something you can use or
> > maybe it needs a separate, implicit gpio-perst driver similar to what
> > Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> > last week in person and I also use the auxiliary bus for the proxy
> > devices).
>
> Hi,
>
> I'm sorry if this was already reported and fixed. On Qualcomm RB5
> platform with this patchset in place I'm getting the following backtrace
> (and then a lockup):
>
On Rb3Gen2 this breaks UFS:
ufshcd-qcom 1d84000.ufshc: cannot find GPIO chip gpiolib_shared.proxy.4, deferring
But MMC acquired the GPIO successfully,
sdhci_msm 8804000.mmc: Got CD GPIO
But I can see gpiochips registered as well:
(initramfs) ls /dev/gpio*
crw------- 1 0 0 254,0 /dev/gpiochip0
crw------- 1 0 0 254,1 /dev/gpiochip1
crw------- 1 0 0 254,2 /dev/gpiochip2
crw------- 1 0 0 254,3 /dev/gpiochip3
crw------- 1 0 0 254,4 /dev/gpiochip4
Let me know if you need more info.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2026-01-07 11:47 ` Manivannan Sadhasivam
@ 2026-01-07 12:12 ` Dmitry Baryshkov
2026-01-07 12:23 ` Manivannan Sadhasivam
0 siblings, 1 reply; 71+ messages in thread
From: Dmitry Baryshkov @ 2026-01-07 12:12 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Jan 07, 2026 at 05:17:09PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Nov 26, 2025 at 06:27:13PM +0200, Dmitry Baryshkov wrote:
> > On Wed, Nov 12, 2025 at 02:55:29PM +0100, Bartosz Golaszewski wrote:
> > > Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> > > came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> > > this series however impacts Qualcomm platforms. It's a runtime dependency
> > > of patches 8 and 9. Would you mind Acking it so that I can take it into
> > > an immutable branch that I'll make available to Mark Brown for him to
> > > take patches 8-10 through the ASoC and regulator trees for v6.19?
> > >
> > > Problem statement: GPIOs are implemented as a strictly exclusive
> > > resource in the kernel but there are lots of platforms on which single
> > > pin is shared by multiple devices which don't communicate so need some
> > > way of properly sharing access to a GPIO. What we have now is the
> > > GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> > > doesn't do any locking or arbitration of access - it literally just hand
> > > the same GPIO descriptor to all interested users.
> > >
> > > The proposed solution is composed of three major parts: the high-level,
> > > shared GPIO proxy driver that arbitrates access to the shared pin and
> > > exposes a regular GPIO chip interface to consumers, a low-level shared
> > > GPIOLIB module that scans firmware nodes and creates auxiliary devices
> > > that attach to the proxy driver and finally a set of core GPIOLIB
> > > changes that plug the former into the GPIO lookup path.
> > >
> > > The changes are implemented in a way that allows to seamlessly compile
> > > out any code related to sharing GPIOs for systems that don't need it.
> > >
> > > The practical use-case for this are the powerdown GPIOs shared by
> > > speakers on Qualcomm db845c platform, however I have also extensively
> > > tested it using gpio-virtuser on arm64 qemu with various DT
> > > configurations.
> > >
> > > I'm Cc'ing some people that may help with reviewing/be interested in
> > > this: OF maintainers (because the main target are OF systems initially),
> > > Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> > > in audio or regulator drivers and one of the goals of this series is
> > > dropping the hand-crafted GPIO enable counting via struct
> > > regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> > > to also cover ACPI (even though I don't know about any ACPI platform that
> > > would need this at the moment, I think it makes sense to make the
> > > solution complete), Dmitry (same thing but for software nodes), Mani
> > > (because you have a somewhat related use-case for the PERST# signal and
> > > I'd like to hear your input on whether this is something you can use or
> > > maybe it needs a separate, implicit gpio-perst driver similar to what
> > > Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> > > last week in person and I also use the auxiliary bus for the proxy
> > > devices).
> >
> > Hi,
> >
> > I'm sorry if this was already reported and fixed. On Qualcomm RB5
> > platform with this patchset in place I'm getting the following backtrace
> > (and then a lockup):
> >
>
> On Rb3Gen2 this breaks UFS:
>
> ufshcd-qcom 1d84000.ufshc: cannot find GPIO chip gpiolib_shared.proxy.4, deferring
CONFIG_GPIO_SHARED_PROXY=y ?
>
> But MMC acquired the GPIO successfully,
>
> sdhci_msm 8804000.mmc: Got CD GPIO
>
> But I can see gpiochips registered as well:
>
> (initramfs) ls /dev/gpio*
> crw------- 1 0 0 254,0 /dev/gpiochip0
> crw------- 1 0 0 254,1 /dev/gpiochip1
> crw------- 1 0 0 254,2 /dev/gpiochip2
> crw------- 1 0 0 254,3 /dev/gpiochip3
> crw------- 1 0 0 254,4 /dev/gpiochip4
>
> Let me know if you need more info.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2026-01-07 12:12 ` Dmitry Baryshkov
@ 2026-01-07 12:23 ` Manivannan Sadhasivam
0 siblings, 0 replies; 71+ messages in thread
From: Manivannan Sadhasivam @ 2026-01-07 12:23 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Wed, Jan 07, 2026 at 02:12:28PM +0200, Dmitry Baryshkov wrote:
> On Wed, Jan 07, 2026 at 05:17:09PM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Nov 26, 2025 at 06:27:13PM +0200, Dmitry Baryshkov wrote:
> > > On Wed, Nov 12, 2025 at 02:55:29PM +0100, Bartosz Golaszewski wrote:
> > > > Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> > > > came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> > > > this series however impacts Qualcomm platforms. It's a runtime dependency
> > > > of patches 8 and 9. Would you mind Acking it so that I can take it into
> > > > an immutable branch that I'll make available to Mark Brown for him to
> > > > take patches 8-10 through the ASoC and regulator trees for v6.19?
> > > >
> > > > Problem statement: GPIOs are implemented as a strictly exclusive
> > > > resource in the kernel but there are lots of platforms on which single
> > > > pin is shared by multiple devices which don't communicate so need some
> > > > way of properly sharing access to a GPIO. What we have now is the
> > > > GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> > > > doesn't do any locking or arbitration of access - it literally just hand
> > > > the same GPIO descriptor to all interested users.
> > > >
> > > > The proposed solution is composed of three major parts: the high-level,
> > > > shared GPIO proxy driver that arbitrates access to the shared pin and
> > > > exposes a regular GPIO chip interface to consumers, a low-level shared
> > > > GPIOLIB module that scans firmware nodes and creates auxiliary devices
> > > > that attach to the proxy driver and finally a set of core GPIOLIB
> > > > changes that plug the former into the GPIO lookup path.
> > > >
> > > > The changes are implemented in a way that allows to seamlessly compile
> > > > out any code related to sharing GPIOs for systems that don't need it.
> > > >
> > > > The practical use-case for this are the powerdown GPIOs shared by
> > > > speakers on Qualcomm db845c platform, however I have also extensively
> > > > tested it using gpio-virtuser on arm64 qemu with various DT
> > > > configurations.
> > > >
> > > > I'm Cc'ing some people that may help with reviewing/be interested in
> > > > this: OF maintainers (because the main target are OF systems initially),
> > > > Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> > > > in audio or regulator drivers and one of the goals of this series is
> > > > dropping the hand-crafted GPIO enable counting via struct
> > > > regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> > > > to also cover ACPI (even though I don't know about any ACPI platform that
> > > > would need this at the moment, I think it makes sense to make the
> > > > solution complete), Dmitry (same thing but for software nodes), Mani
> > > > (because you have a somewhat related use-case for the PERST# signal and
> > > > I'd like to hear your input on whether this is something you can use or
> > > > maybe it needs a separate, implicit gpio-perst driver similar to what
> > > > Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> > > > last week in person and I also use the auxiliary bus for the proxy
> > > > devices).
> > >
> > > Hi,
> > >
> > > I'm sorry if this was already reported and fixed. On Qualcomm RB5
> > > platform with this patchset in place I'm getting the following backtrace
> > > (and then a lockup):
> > >
> >
> > On Rb3Gen2 this breaks UFS:
> >
> > ufshcd-qcom 1d84000.ufshc: cannot find GPIO chip gpiolib_shared.proxy.4, deferring
>
> CONFIG_GPIO_SHARED_PROXY=y ?
>
Ah, it was selected as =m and not part of initramfs, so it didn't get loaded.
Building it as =y fixed the issue. But that was such an implicit dependency.
Also, it should only be used for shared GPIOs, isn't it? But on my board, UFS is
not using a shared GPIO. So why is it coming into the picture?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2026-01-07 11:06 ` Pankaj Patil
@ 2026-01-07 12:38 ` Bartosz Golaszewski
2026-01-08 6:49 ` Pankaj Patil
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-01-07 12:38 UTC (permalink / raw)
To: Pankaj Patil
Cc: Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio,
linux-gpio, linux-arm-kernel, linux-arm-msm
On Wed, Jan 7, 2026 at 12:07 PM Pankaj Patil
<pankaj.patil@oss.qualcomm.com> wrote:
>
> On 11/12/2025 7:25 PM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Some qualcomm platforms use shared GPIOs. Enable support for them by
> > selecting the Kconfig switch provided by GPIOLIB.
> >
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> > arch/arm64/Kconfig.platforms | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -316,6 +316,7 @@ config ARCH_QCOM
> > select GPIOLIB
> > select PINCTRL
> > select HAVE_PWRCTRL if PCI
> > + select HAVE_SHARED_GPIOS
> > help
> > This enables support for the ARMv8 based Qualcomm chipsets.
> >
> >
> Enabling shared gpios is breaking hamoa and glymur boot on next-20260106
> For hamoa - reg_fixed_voltage_probe which calls gpio api is breaking
> Please find the log here - https://lava-oss.qualcomm.com/scheduler/job/24722#L3514
>
> For Glymur - qcom_pcie_parse_perst calls the gpio api <4>[ 2.910982] WARNING: drivers/gpio/gpiolib-shared.c:493 at gpio_shared_add_proxy_lookup+0x160/0x24c, CPU#1: kworker/u75:0/109 <4>[ 2.911027] Call trace: <4>[ 2.911028] gpio_shared_add_proxy_lookup+0x160/0x24c (P) <4>[ 2.911030] gpiod_find_and_request+0x1c0/0x504 <4>[ 2.911032] devm_fwnode_gpiod_get_index+0x1c/0x6c <4>[ 2.911034] qcom_pcie_parse_perst+0x70/0x150 <4>[ 2.911037] qcom_pcie_probe+0x414/0x804 <4>[ 2.911039] platform_probe+0x5c/0x98 <4>[ 2.911042] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd18 not found, using dummy regulator <4>[ 2.911043] really_probe+0xbc/0x298 <4>[ 2.911045] __driver_probe_device+0x78/0x12c <4>[ 2.911047] driver_probe_device+0x3c/0x15c <4>[ 2.911049] __device_attach_driver+0xb8/0x134 <4>[ 2.911050] bus_for_each_drv+0x84/0xe0 <4>[ 2.911052] __device_attach_async_helper+0xac/0xd0 <4>[ 2.911053] async_run_entry_fn+0x34/0xe0
> <4>[ 2.911055] process_one_work+0x14c/0x28c <4>[ 2.911058] worker_thread+0x188/0x304 <4>[ 2.911059] kthread+0x11c/0x128 <4>[ 2.911060] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd3 not found, using dummy regulator <4>[ 2.911061] ret_from_fork+0x10/0x20 <4>[ 2.911063] ---[ end trace 0000000000000000 ]--- <3>[ 2.911065] qcom-pcie 1b40000.pci: error -ENOENT: Failed to parse Root Port: -2 <3>[ 2.911069] qcom-pcie 1b40000.pci: probe with driver qcom-pcie failed with error -2
> Reverting this commit fixes the boot on both platforms
>
Hi!
This is not really the offending commit, it's a recent one in the
implementation. The issue should be fixed by the following series[1]
that will be in the next next tag. Can you give it a try?
Bart
[1] https://lore.kernel.org/all/20260106-gpio-shared-fixes-v2-0-c7091d2f7581@oss.qualcomm.com/
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2026-01-07 12:38 ` Bartosz Golaszewski
@ 2026-01-08 6:49 ` Pankaj Patil
2026-01-08 8:45 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Pankaj Patil @ 2026-01-08 6:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio,
linux-gpio, linux-arm-kernel, linux-arm-msm
On 1/7/2026 6:08 PM, Bartosz Golaszewski wrote:
> On Wed, Jan 7, 2026 at 12:07 PM Pankaj Patil
> <pankaj.patil@oss.qualcomm.com> wrote:
>>
>> On 11/12/2025 7:25 PM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>> selecting the Kconfig switch provided by GPIOLIB.
>>>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>> ---
>>> arch/arm64/Kconfig.platforms | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>> --- a/arch/arm64/Kconfig.platforms
>>> +++ b/arch/arm64/Kconfig.platforms
>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>> select GPIOLIB
>>> select PINCTRL
>>> select HAVE_PWRCTRL if PCI
>>> + select HAVE_SHARED_GPIOS
>>> help
>>> This enables support for the ARMv8 based Qualcomm chipsets.
>>>
>>>
>> Enabling shared gpios is breaking hamoa and glymur boot on next-20260106
>> For hamoa - reg_fixed_voltage_probe which calls gpio api is breaking
>> Please find the log here - https://lava-oss.qualcomm.com/scheduler/job/24722#L3514
>>
>> For Glymur - qcom_pcie_parse_perst calls the gpio api <4>[ 2.910982] WARNING: drivers/gpio/gpiolib-shared.c:493 at gpio_shared_add_proxy_lookup+0x160/0x24c, CPU#1: kworker/u75:0/109 <4>[ 2.911027] Call trace: <4>[ 2.911028] gpio_shared_add_proxy_lookup+0x160/0x24c (P) <4>[ 2.911030] gpiod_find_and_request+0x1c0/0x504 <4>[ 2.911032] devm_fwnode_gpiod_get_index+0x1c/0x6c <4>[ 2.911034] qcom_pcie_parse_perst+0x70/0x150 <4>[ 2.911037] qcom_pcie_probe+0x414/0x804 <4>[ 2.911039] platform_probe+0x5c/0x98 <4>[ 2.911042] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd18 not found, using dummy regulator <4>[ 2.911043] really_probe+0xbc/0x298 <4>[ 2.911045] __driver_probe_device+0x78/0x12c <4>[ 2.911047] driver_probe_device+0x3c/0x15c <4>[ 2.911049] __device_attach_driver+0xb8/0x134 <4>[ 2.911050] bus_for_each_drv+0x84/0xe0 <4>[ 2.911052] __device_attach_async_helper+0xac/0xd0 <4>[ 2.911053] async_run_entry_fn+0x34/0xe0
>> <4>[ 2.911055] process_one_work+0x14c/0x28c <4>[ 2.911058] worker_thread+0x188/0x304 <4>[ 2.911059] kthread+0x11c/0x128 <4>[ 2.911060] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd3 not found, using dummy regulator <4>[ 2.911061] ret_from_fork+0x10/0x20 <4>[ 2.911063] ---[ end trace 0000000000000000 ]--- <3>[ 2.911065] qcom-pcie 1b40000.pci: error -ENOENT: Failed to parse Root Port: -2 <3>[ 2.911069] qcom-pcie 1b40000.pci: probe with driver qcom-pcie failed with error -2
>> Reverting this commit fixes the boot on both platforms
>>
>
> Hi!
>
> This is not really the offending commit, it's a recent one in the
> implementation. The issue should be fixed by the following series[1]
> that will be in the next next tag. Can you give it a try?
>
> Bart
>
> [1] https://lore.kernel.org/all/20260106-gpio-shared-fixes-v2-0-c7091d2f7581@oss.qualcomm.com/
With the linked patchset applied I still see the same issue
Pankaj
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2026-01-08 6:49 ` Pankaj Patil
@ 2026-01-08 8:45 ` Bartosz Golaszewski
2026-01-08 9:43 ` Pankaj Patil
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-01-08 8:45 UTC (permalink / raw)
To: Pankaj Patil
Cc: Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio,
linux-gpio, linux-arm-kernel, linux-arm-msm
On Thu, Jan 8, 2026 at 7:49 AM Pankaj Patil
<pankaj.patil@oss.qualcomm.com> wrote:
>
> On 1/7/2026 6:08 PM, Bartosz Golaszewski wrote:
> > On Wed, Jan 7, 2026 at 12:07 PM Pankaj Patil
> > <pankaj.patil@oss.qualcomm.com> wrote:
> >>
> >> On 11/12/2025 7:25 PM, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>
> >>> Some qualcomm platforms use shared GPIOs. Enable support for them by
> >>> selecting the Kconfig switch provided by GPIOLIB.
> >>>
> >>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>> ---
> >>> arch/arm64/Kconfig.platforms | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> >>> --- a/arch/arm64/Kconfig.platforms
> >>> +++ b/arch/arm64/Kconfig.platforms
> >>> @@ -316,6 +316,7 @@ config ARCH_QCOM
> >>> select GPIOLIB
> >>> select PINCTRL
> >>> select HAVE_PWRCTRL if PCI
> >>> + select HAVE_SHARED_GPIOS
> >>> help
> >>> This enables support for the ARMv8 based Qualcomm chipsets.
> >>>
> >>>
> >> Enabling shared gpios is breaking hamoa and glymur boot on next-20260106
> >> For hamoa - reg_fixed_voltage_probe which calls gpio api is breaking
> >> Please find the log here - https://lava-oss.qualcomm.com/scheduler/job/24722#L3514
> >>
> >> For Glymur - qcom_pcie_parse_perst calls the gpio api <4>[ 2.910982] WARNING: drivers/gpio/gpiolib-shared.c:493 at gpio_shared_add_proxy_lookup+0x160/0x24c, CPU#1: kworker/u75:0/109 <4>[ 2.911027] Call trace: <4>[ 2.911028] gpio_shared_add_proxy_lookup+0x160/0x24c (P) <4>[ 2.911030] gpiod_find_and_request+0x1c0/0x504 <4>[ 2.911032] devm_fwnode_gpiod_get_index+0x1c/0x6c <4>[ 2.911034] qcom_pcie_parse_perst+0x70/0x150 <4>[ 2.911037] qcom_pcie_probe+0x414/0x804 <4>[ 2.911039] platform_probe+0x5c/0x98 <4>[ 2.911042] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd18 not found, using dummy regulator <4>[ 2.911043] really_probe+0xbc/0x298 <4>[ 2.911045] __driver_probe_device+0x78/0x12c <4>[ 2.911047] driver_probe_device+0x3c/0x15c <4>[ 2.911049] __device_attach_driver+0xb8/0x134 <4>[ 2.911050] bus_for_each_drv+0x84/0xe0 <4>[ 2.911052] __device_attach_async_helper+0xac/0xd0 <4>[ 2.911053] async_run_entry_fn+0x34/0xe0
> >> <4>[ 2.911055] process_one_work+0x14c/0x28c <4>[ 2.911058] worker_thread+0x188/0x304 <4>[ 2.911059] kthread+0x11c/0x128 <4>[ 2.911060] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd3 not found, using dummy regulator <4>[ 2.911061] ret_from_fork+0x10/0x20 <4>[ 2.911063] ---[ end trace 0000000000000000 ]--- <3>[ 2.911065] qcom-pcie 1b40000.pci: error -ENOENT: Failed to parse Root Port: -2 <3>[ 2.911069] qcom-pcie 1b40000.pci: probe with driver qcom-pcie failed with error -2
> >> Reverting this commit fixes the boot on both platforms
> >>
> >
> > Hi!
> >
> > This is not really the offending commit, it's a recent one in the
> > implementation. The issue should be fixed by the following series[1]
> > that will be in the next next tag. Can you give it a try?
> >
> > Bart
> >
> > [1] https://lore.kernel.org/all/20260106-gpio-shared-fixes-v2-0-c7091d2f7581@oss.qualcomm.com/
>
> With the linked patchset applied I still see the same issue
>
> Pankaj
>
Is the gpio-shared-proxy module available? If not, can you change the
config to make it built-in like CONFIG_GPIO_SHARED_PROXY=y?
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2026-01-08 8:45 ` Bartosz Golaszewski
@ 2026-01-08 9:43 ` Pankaj Patil
2026-01-08 10:52 ` Bartosz Golaszewski
2026-01-08 14:37 ` Bartosz Golaszewski
0 siblings, 2 replies; 71+ messages in thread
From: Pankaj Patil @ 2026-01-08 9:43 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio,
linux-gpio, linux-arm-kernel, linux-arm-msm
On 1/8/2026 2:15 PM, Bartosz Golaszewski wrote:
> On Thu, Jan 8, 2026 at 7:49 AM Pankaj Patil
> <pankaj.patil@oss.qualcomm.com> wrote:
>>
>> On 1/7/2026 6:08 PM, Bartosz Golaszewski wrote:
>>> On Wed, Jan 7, 2026 at 12:07 PM Pankaj Patil
>>> <pankaj.patil@oss.qualcomm.com> wrote:
>>>>
>>>> On 11/12/2025 7:25 PM, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
>>>>> selecting the Kconfig switch provided by GPIOLIB.
>>>>>
>>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>> ---
>>>>> arch/arm64/Kconfig.platforms | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
>>>>> select GPIOLIB
>>>>> select PINCTRL
>>>>> select HAVE_PWRCTRL if PCI
>>>>> + select HAVE_SHARED_GPIOS
>>>>> help
>>>>> This enables support for the ARMv8 based Qualcomm chipsets.
>>>>>
>>>>>
>>>> Enabling shared gpios is breaking hamoa and glymur boot on next-20260106
>>>> For hamoa - reg_fixed_voltage_probe which calls gpio api is breaking
>>>> Please find the log here - https://lava-oss.qualcomm.com/scheduler/job/24722#L3514
>>>>
>>>> For Glymur - qcom_pcie_parse_perst calls the gpio api <4>[ 2.910982] WARNING: drivers/gpio/gpiolib-shared.c:493 at gpio_shared_add_proxy_lookup+0x160/0x24c, CPU#1: kworker/u75:0/109 <4>[ 2.911027] Call trace: <4>[ 2.911028] gpio_shared_add_proxy_lookup+0x160/0x24c (P) <4>[ 2.911030] gpiod_find_and_request+0x1c0/0x504 <4>[ 2.911032] devm_fwnode_gpiod_get_index+0x1c/0x6c <4>[ 2.911034] qcom_pcie_parse_perst+0x70/0x150 <4>[ 2.911037] qcom_pcie_probe+0x414/0x804 <4>[ 2.911039] platform_probe+0x5c/0x98 <4>[ 2.911042] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd18 not found, using dummy regulator <4>[ 2.911043] really_probe+0xbc/0x298 <4>[ 2.911045] __driver_probe_device+0x78/0x12c <4>[ 2.911047] driver_probe_device+0x3c/0x15c <4>[ 2.911049] __device_attach_driver+0xb8/0x134 <4>[ 2.911050] bus_for_each_drv+0x84/0xe0 <4>[ 2.911052] __device_attach_async_helper+0xac/0xd0 <4>[ 2.911053] async_run_entry_fn+0x34/0xe0
>>>> <4>[ 2.911055] process_one_work+0x14c/0x28c <4>[ 2.911058] worker_thread+0x188/0x304 <4>[ 2.911059] kthread+0x11c/0x128 <4>[ 2.911060] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd3 not found, using dummy regulator <4>[ 2.911061] ret_from_fork+0x10/0x20 <4>[ 2.911063] ---[ end trace 0000000000000000 ]--- <3>[ 2.911065] qcom-pcie 1b40000.pci: error -ENOENT: Failed to parse Root Port: -2 <3>[ 2.911069] qcom-pcie 1b40000.pci: probe with driver qcom-pcie failed with error -2
>>>> Reverting this commit fixes the boot on both platforms
>>>>
>>>
>>> Hi!
>>>
>>> This is not really the offending commit, it's a recent one in the
>>> implementation. The issue should be fixed by the following series[1]
>>> that will be in the next next tag. Can you give it a try?
>>>
>>> Bart
>>>
>>> [1] https://lore.kernel.org/all/20260106-gpio-shared-fixes-v2-0-c7091d2f7581@oss.qualcomm.com/
>>
>> With the linked patchset applied I still see the same issue
>>
>> Pankaj
>>
>
> Is the gpio-shared-proxy module available? If not, can you change the
> config to make it built-in like CONFIG_GPIO_SHARED_PROXY=y?
>
> Bartosz
With CONFIG_GPIO_SHARED_PROXY=y the issue remains the same
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2026-01-08 9:43 ` Pankaj Patil
@ 2026-01-08 10:52 ` Bartosz Golaszewski
2026-01-08 14:37 ` Bartosz Golaszewski
1 sibling, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-01-08 10:52 UTC (permalink / raw)
To: Pankaj Patil
Cc: Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio,
linux-gpio, linux-arm-kernel, linux-arm-msm
On Thu, Jan 8, 2026 at 10:44 AM Pankaj Patil
<pankaj.patil@oss.qualcomm.com> wrote:
>
> On 1/8/2026 2:15 PM, Bartosz Golaszewski wrote:
> > On Thu, Jan 8, 2026 at 7:49 AM Pankaj Patil
> > <pankaj.patil@oss.qualcomm.com> wrote:
> >>
> >> On 1/7/2026 6:08 PM, Bartosz Golaszewski wrote:
> >>> On Wed, Jan 7, 2026 at 12:07 PM Pankaj Patil
> >>> <pankaj.patil@oss.qualcomm.com> wrote:
> >>>>
> >>>> On 11/12/2025 7:25 PM, Bartosz Golaszewski wrote:
> >>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>>>
> >>>>> Some qualcomm platforms use shared GPIOs. Enable support for them by
> >>>>> selecting the Kconfig switch provided by GPIOLIB.
> >>>>>
> >>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>>> ---
> >>>>> arch/arm64/Kconfig.platforms | 1 +
> >>>>> 1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>>>> index 13173795c43d4f28e2d47acc700f80a165d44671..3dbff0261f0add0516d8cb3fd0f29e277af94f20 100644
> >>>>> --- a/arch/arm64/Kconfig.platforms
> >>>>> +++ b/arch/arm64/Kconfig.platforms
> >>>>> @@ -316,6 +316,7 @@ config ARCH_QCOM
> >>>>> select GPIOLIB
> >>>>> select PINCTRL
> >>>>> select HAVE_PWRCTRL if PCI
> >>>>> + select HAVE_SHARED_GPIOS
> >>>>> help
> >>>>> This enables support for the ARMv8 based Qualcomm chipsets.
> >>>>>
> >>>>>
> >>>> Enabling shared gpios is breaking hamoa and glymur boot on next-20260106
> >>>> For hamoa - reg_fixed_voltage_probe which calls gpio api is breaking
> >>>> Please find the log here - https://lava-oss.qualcomm.com/scheduler/job/24722#L3514
> >>>>
> >>>> For Glymur - qcom_pcie_parse_perst calls the gpio api <4>[ 2.910982] WARNING: drivers/gpio/gpiolib-shared.c:493 at gpio_shared_add_proxy_lookup+0x160/0x24c, CPU#1: kworker/u75:0/109 <4>[ 2.911027] Call trace: <4>[ 2.911028] gpio_shared_add_proxy_lookup+0x160/0x24c (P) <4>[ 2.911030] gpiod_find_and_request+0x1c0/0x504 <4>[ 2.911032] devm_fwnode_gpiod_get_index+0x1c/0x6c <4>[ 2.911034] qcom_pcie_parse_perst+0x70/0x150 <4>[ 2.911037] qcom_pcie_probe+0x414/0x804 <4>[ 2.911039] platform_probe+0x5c/0x98 <4>[ 2.911042] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd18 not found, using dummy regulator <4>[ 2.911043] really_probe+0xbc/0x298 <4>[ 2.911045] __driver_probe_device+0x78/0x12c <4>[ 2.911047] driver_probe_device+0x3c/0x15c <4>[ 2.911049] __device_attach_driver+0xb8/0x134 <4>[ 2.911050] bus_for_each_drv+0x84/0xe0 <4>[ 2.911052] __device_attach_async_helper+0xac/0xd0 <4>[ 2.911053] async_run_entry_fn+0x34/0xe0
> >>>> <4>[ 2.911055] process_one_work+0x14c/0x28c <4>[ 2.911058] worker_thread+0x188/0x304 <4>[ 2.911059] kthread+0x11c/0x128 <4>[ 2.911060] qcom-eusb2-repeater c448000.spmi:pmic@9:phy@fd00: supply vdd3 not found, using dummy regulator <4>[ 2.911061] ret_from_fork+0x10/0x20 <4>[ 2.911063] ---[ end trace 0000000000000000 ]--- <3>[ 2.911065] qcom-pcie 1b40000.pci: error -ENOENT: Failed to parse Root Port: -2 <3>[ 2.911069] qcom-pcie 1b40000.pci: probe with driver qcom-pcie failed with error -2
> >>>> Reverting this commit fixes the boot on both platforms
> >>>>
> >>>
> >>> Hi!
> >>>
> >>> This is not really the offending commit, it's a recent one in the
> >>> implementation. The issue should be fixed by the following series[1]
> >>> that will be in the next next tag. Can you give it a try?
> >>>
> >>> Bart
> >>>
> >>> [1] https://lore.kernel.org/all/20260106-gpio-shared-fixes-v2-0-c7091d2f7581@oss.qualcomm.com/
> >>
> >> With the linked patchset applied I still see the same issue
> >>
> >> Pankaj
> >>
> >
> > Is the gpio-shared-proxy module available? If not, can you change the
> > config to make it built-in like CONFIG_GPIO_SHARED_PROXY=y?
> >
> > Bartosz
>
> With CONFIG_GPIO_SHARED_PROXY=y the issue remains the same
Ok, I believe there must be an issue with environment differences
because I'm not seeing this.
Can you enable CONFIG_DEBUG_GPIO in config and post the entire kernel
log to some pastebin? Can you also post the output of gpiodetect and
gpioinfo?
Thanks
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM
2026-01-08 9:43 ` Pankaj Patil
2026-01-08 10:52 ` Bartosz Golaszewski
@ 2026-01-08 14:37 ` Bartosz Golaszewski
1 sibling, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-01-08 14:37 UTC (permalink / raw)
To: Pankaj Patil
Cc: Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Will Deacon,
Srinivas Kandagatla, Mark Brown, Bjorn Andersson, Konrad Dybcio,
linux-gpio, linux-arm-kernel, linux-arm-msm
On Thu, Jan 8, 2026 at 10:44 AM Pankaj Patil
<pankaj.patil@oss.qualcomm.com> wrote:
>
> >>>
> >>> Hi!
> >>>
> >>> This is not really the offending commit, it's a recent one in the
> >>> implementation. The issue should be fixed by the following series[1]
> >>> that will be in the next next tag. Can you give it a try?
> >>>
> >>> Bart
> >>>
> >>> [1] https://lore.kernel.org/all/20260106-gpio-shared-fixes-v2-0-c7091d2f7581@oss.qualcomm.com/
> >>
> >> With the linked patchset applied I still see the same issue
> >>
> >> Pankaj
> >>
> >
> > Is the gpio-shared-proxy module available? If not, can you change the
> > config to make it built-in like CONFIG_GPIO_SHARED_PROXY=y?
> >
> > Bartosz
>
> With CONFIG_GPIO_SHARED_PROXY=y the issue remains the same
Can you try this patch as well in addition to the other ones and on
top of current next?
https://lore.kernel.org/all/20260108-gpio-shared-false-positive-v1-1-5dbf8d1b2f7d@oss.qualcomm.com/
Thanks,
Bartosz
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
` (15 preceding siblings ...)
2025-11-26 16:27 ` Dmitry Baryshkov
@ 2026-01-08 14:46 ` Michael Walle
2026-01-08 15:50 ` Bartosz Golaszewski
16 siblings, 1 reply; 71+ messages in thread
From: Michael Walle @ 2026-01-08 14:46 UTC (permalink / raw)
To: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]
Hi Bartosz,
On Wed Nov 12, 2025 at 2:55 PM CET, Bartosz Golaszewski wrote:
> Bjorn, Konrad: I should have Cc'ed you on v1 but I just went with what
> came out of b4 --auto-to-cc. It only gave me arm-msm. :( Patch 7 from
> this series however impacts Qualcomm platforms. It's a runtime dependency
> of patches 8 and 9. Would you mind Acking it so that I can take it into
> an immutable branch that I'll make available to Mark Brown for him to
> take patches 8-10 through the ASoC and regulator trees for v6.19?
>
> Problem statement: GPIOs are implemented as a strictly exclusive
> resource in the kernel but there are lots of platforms on which single
> pin is shared by multiple devices which don't communicate so need some
> way of properly sharing access to a GPIO. What we have now is the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
> doesn't do any locking or arbitration of access - it literally just hand
> the same GPIO descriptor to all interested users.
>
> The proposed solution is composed of three major parts: the high-level,
> shared GPIO proxy driver that arbitrates access to the shared pin and
> exposes a regular GPIO chip interface to consumers, a low-level shared
> GPIOLIB module that scans firmware nodes and creates auxiliary devices
> that attach to the proxy driver and finally a set of core GPIOLIB
> changes that plug the former into the GPIO lookup path.
>
> The changes are implemented in a way that allows to seamlessly compile
> out any code related to sharing GPIOs for systems that don't need it.
The problem here is that the aarch64 defconfig has ARCH_QCOM enabled
and thus it will get enabled for any platforms, right?
I haven't grokked everything, but does GPIO_SHARED=y makes any sense
without GPIO_SHARED_PROXY? It seems to me that the probing of shared
pins will be deferred indefinitely.
> The practical use-case for this are the powerdown GPIOs shared by
> speakers on Qualcomm db845c platform, however I have also extensively
> tested it using gpio-virtuser on arm64 qemu with various DT
> configurations.
>
> I'm Cc'ing some people that may help with reviewing/be interested in
> this: OF maintainers (because the main target are OF systems initially),
> Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> in audio or regulator drivers and one of the goals of this series is
> dropping the hand-crafted GPIO enable counting via struct
> regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> to also cover ACPI (even though I don't know about any ACPI platform that
> would need this at the moment, I think it makes sense to make the
> solution complete), Dmitry (same thing but for software nodes), Mani
> (because you have a somewhat related use-case for the PERST# signal and
> I'd like to hear your input on whether this is something you can use or
> maybe it needs a separate, implicit gpio-perst driver similar to what
> Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> last week in person and I also use the auxiliary bus for the proxy
> devices).
This broke my board (using the arm64 defconfig, works without
GPIO_SHARED of course). I'm seeing two issues here with my board
(arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67*):
(1) It's GPIO controller (gpio-davinci) doesn't support
.get_direction so I'm getting ENOTSUPP during probing of the
(some?) shared GPIOs.
(2) GPIO_SHARED_PROXY is default m in the defconfig, but I need the
pins for the root filesystem medium, i.e. the SD card regulators.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2026-01-08 14:46 ` Michael Walle
@ 2026-01-08 15:50 ` Bartosz Golaszewski
2026-01-09 14:41 ` Michael Walle
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-01-08 15:50 UTC (permalink / raw)
To: Michael Walle
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Thu, Jan 8, 2026 at 3:46 PM Michael Walle <mwalle@kernel.org> wrote:
>
> >
> > The changes are implemented in a way that allows to seamlessly compile
> > out any code related to sharing GPIOs for systems that don't need it.
>
> The problem here is that the aarch64 defconfig has ARCH_QCOM enabled
> and thus it will get enabled for any platforms, right?
>
On arm64 with defconfig, yes. I want to make it transparent for
platforms that don't have shared GPIOs though. I'm aware of issues and
am actively fixing all that are reported to me. Another set of fixes
will be in tomorrow's linux-next.
> I haven't grokked everything, but does GPIO_SHARED=y makes any sense
> without GPIO_SHARED_PROXY? It seems to me that the probing of shared
> pins will be deferred indefinitely.
>
Do you have a use-case where there are shared GPIOs that are needed at
boot time when there are no modules? I am aware of the issue where
false-positive shared GPIOs are detected, I posted a fix for that too.
Without logs, I can't really tell if that's the case for you though.
:(
> > The practical use-case for this are the powerdown GPIOs shared by
> > speakers on Qualcomm db845c platform, however I have also extensively
> > tested it using gpio-virtuser on arm64 qemu with various DT
> > configurations.
> >
> > I'm Cc'ing some people that may help with reviewing/be interested in
> > this: OF maintainers (because the main target are OF systems initially),
> > Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
> > in audio or regulator drivers and one of the goals of this series is
> > dropping the hand-crafted GPIO enable counting via struct
> > regulator_enable_gpio in regulator core), Andy and Mika because I'd like
> > to also cover ACPI (even though I don't know about any ACPI platform that
> > would need this at the moment, I think it makes sense to make the
> > solution complete), Dmitry (same thing but for software nodes), Mani
> > (because you have a somewhat related use-case for the PERST# signal and
> > I'd like to hear your input on whether this is something you can use or
> > maybe it needs a separate, implicit gpio-perst driver similar to what
> > Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
> > last week in person and I also use the auxiliary bus for the proxy
> > devices).
>
> This broke my board (using the arm64 defconfig, works without
> GPIO_SHARED of course). I'm seeing two issues here with my board
> (arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67*):
>
> (1) It's GPIO controller (gpio-davinci) doesn't support
> .get_direction so I'm getting ENOTSUPP during probing of the
> (some?) shared GPIOs.
>
Unless this board really shares GPIOs, it may be due to the
false-positives that will be fixed by this patch[1]. If you enable
CONFIG_DEBUG_GPIO and post the kernel log, I'll be able to tell for
sure.
Though thanks for bringing this to my attention as I now see there is
indeed an issue when the proxied chip doesn't support .get_direction()
as well as a duplicated check in GPIO core. I'll fix it too.
> (2) GPIO_SHARED_PROXY is default m in the defconfig, but I need the
> pins for the root filesystem medium, i.e. the SD card regulators.
>
I'll take care of this is you confirm, the issue persists even with patch[1].
Thanks,
Bartosz
[1] https://lore.kernel.org/all/20260108-gpio-shared-false-positive-v1-1-5dbf8d1b2f7d@oss.qualcomm.com/
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2026-01-08 15:50 ` Bartosz Golaszewski
@ 2026-01-09 14:41 ` Michael Walle
2026-01-09 14:50 ` Bartosz Golaszewski
0 siblings, 1 reply; 71+ messages in thread
From: Michael Walle @ 2026-01-09 14:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
[-- Attachment #1: Type: text/plain, Size: 69088 bytes --]
Hi,
On Thu Jan 8, 2026 at 4:50 PM CET, Bartosz Golaszewski wrote:
> On Thu, Jan 8, 2026 at 3:46 PM Michael Walle <mwalle@kernel.org> wrote:
>>
>> >
>> > The changes are implemented in a way that allows to seamlessly compile
>> > out any code related to sharing GPIOs for systems that don't need it.
>>
>> The problem here is that the aarch64 defconfig has ARCH_QCOM enabled
>> and thus it will get enabled for any platforms, right?
>>
>
> On arm64 with defconfig, yes. I want to make it transparent for
> platforms that don't have shared GPIOs though. I'm aware of issues and
> am actively fixing all that are reported to me. Another set of fixes
> will be in tomorrow's linux-next.
>
>> I haven't grokked everything, but does GPIO_SHARED=y makes any sense
>> without GPIO_SHARED_PROXY? It seems to me that the probing of shared
>> pins will be deferred indefinitely.
>>
>
> Do you have a use-case where there are shared GPIOs that are needed at
> boot time when there are no modules?
See below.
> I am aware of the issue where
> false-positive shared GPIOs are detected, I posted a fix for that too.
> Without logs, I can't really tell if that's the case for you though.
> :(
What I mean is, GPIO_SHARED is automatically selected by ARCH_QCOM (and
probably others in the future). But GPIO_SHARED_PROXY is
selectable by the user and it can be deselected. But you cannot
specifically deactivate GPIO_SHARED. So there is no way to go back
to the former hacky shared gpio handling; which might be intended :)
If so, shouldn't be GPIO_SHARED_PROXY be either y or m if GPIO_SHARED=y ?
I.e. don't allow it to be deselected.
>> > The practical use-case for this are the powerdown GPIOs shared by
>> > speakers on Qualcomm db845c platform, however I have also extensively
>> > tested it using gpio-virtuser on arm64 qemu with various DT
>> > configurations.
>> >
>> > I'm Cc'ing some people that may help with reviewing/be interested in
>> > this: OF maintainers (because the main target are OF systems initially),
>> > Mark Brown because most users of GPIOD_FLAGS_BIT_NONEXCLUSIVE live
>> > in audio or regulator drivers and one of the goals of this series is
>> > dropping the hand-crafted GPIO enable counting via struct
>> > regulator_enable_gpio in regulator core), Andy and Mika because I'd like
>> > to also cover ACPI (even though I don't know about any ACPI platform that
>> > would need this at the moment, I think it makes sense to make the
>> > solution complete), Dmitry (same thing but for software nodes), Mani
>> > (because you have a somewhat related use-case for the PERST# signal and
>> > I'd like to hear your input on whether this is something you can use or
>> > maybe it needs a separate, implicit gpio-perst driver similar to what
>> > Krzysztof did for reset-gpios) and Greg (because I mentioned this to you
>> > last week in person and I also use the auxiliary bus for the proxy
>> > devices).
>>
>> This broke my board (using the arm64 defconfig, works without
>> GPIO_SHARED of course). I'm seeing two issues here with my board
>> (arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67*):
>>
>> (1) It's GPIO controller (gpio-davinci) doesn't support
>> .get_direction so I'm getting ENOTSUPP during probing of the
>> (some?) shared GPIOs.
>>
>
> Unless this board really shares GPIOs, it may be due to the
> false-positives that will be fixed by this patch[1]. If you enable
Yeah this board shares an enable GPIO for two regulators
(regulator-5 and regulator-6,
arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts).
> CONFIG_DEBUG_GPIO and post the kernel log, I'll be able to tell for
> sure.
See end of this mail. I've applied the mentioned patch.
> Though thanks for bringing this to my attention as I now see there is
> indeed an issue when the proxied chip doesn't support .get_direction()
> as well as a duplicated check in GPIO core. I'll fix it too.
>
>> (2) GPIO_SHARED_PROXY is default m in the defconfig, but I need the
>> pins for the root filesystem medium, i.e. the SD card regulators.
>>
>
> I'll take care of this is you confirm, the issue persists even with patch[1].
Not sure this is still valid. Because I've just learned that
apparently, the arm64 Image shall be made smaller and thus "need
a driver for rootfs" isn't a valid reason for =y anymore.
-michael
kernel boot log:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 6.19.0-rc4-next-20260109-00037-g6143d690c7d2 (mwalle@mwalle01) (aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #3137 SMP Fri Jan 9 15:16:54 CET 2026
[ 0.000000] KASLR enabled
[ 0.000000] Machine model: Kontron SMARC-sAM67
[ 0.000000] efi: UEFI not found.
[ 0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!
[ 0.000000] Reserved memory: created CMA memory pool at 0x00000009f0000000, size 256 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] OF: reserved mem: 0x00000009f0000000..0x00000009ffffffff (262144 KiB) map reusable linux,cma
[ 0.000000] OF: reserved mem: 0x000000009e800000..0x000000009fffffff (24576 KiB) nomap non-reusable optee@9e800000
[ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) nomap non-reusable tfa@80000000
[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a0100000, size 15 MiB
[ 0.000000] OF: reserved mem: initialized node r5f-memory@a0100000, compatible id shared-dma-pool
[ 0.000000] OF: reserved mem: 0x00000000a0100000..0x00000000a0ffffff (15360 KiB) nomap non-reusable r5f-memory@a0100000
[ 0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x00000009ffffffff]
[ 0.000000] NODE_DATA(0) allocated [mem 0x9eefb5d00-0x9eefb7d3f]
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: Trusted OS migration not required
[ 0.000000] psci: SMC Calling Convention v1.5
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000080000000-0x00000000ffffffff]
[ 0.000000] DMA32 empty
[ 0.000000] Normal [mem 0x0000000100000000-0x00000009ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080000000-0x000000008007ffff]
[ 0.000000] node 0: [mem 0x0000000080080000-0x000000009e7fffff]
[ 0.000000] node 0: [mem 0x000000009e800000-0x000000009fffffff]
[ 0.000000] node 0: [mem 0x00000000a0000000-0x00000000a00fffff]
[ 0.000000] node 0: [mem 0x00000000a0100000-0x00000000a0ffffff]
[ 0.000000] node 0: [mem 0x00000000a1000000-0x00000000ffffffff]
[ 0.000000] node 0: [mem 0x0000000880000000-0x00000009ffffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000009ffffffff]
[ 0.000000] percpu: Embedded 32 pages/cpu s91416 r8192 d31464 u131072
[ 0.000000] pcpu-alloc: s91416 r8192 d31464 u131072 alloc=32*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: detected: GICv3 CPU interface
[ 0.000000] CPU features: kernel page table isolation forced ON by KASLR
[ 0.000000] CPU features: detected: Kernel page table isolation (KPTI)
[ 0.000000] CPU features: detected: ARM erratum 845719
[ 0.000000] alternatives: applying boot alternatives
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyS1,115200n8 panic=3 debug
[ 0.000000] printk: log buffer data + meta data: 131072 + 458752 = 589824 bytes
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[ 0.000000] software IO TLB: area num 4.
[ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
[ 0.000000] Fallback order for Node 0: 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2097152
[ 0.000000] Policy zone: Normal
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] stackdepot: allocating hash table via alloc_large_system_hash
[ 0.000000] stackdepot hash table entries: 524288 (order: 11, 8388608 bytes, linear)
[ 0.000000] stackdepot: allocating space for 8192 stack pools via memblock
[ 0.000000] **********************************************************
[ 0.000000] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.000000] ** **
[ 0.000000] ** This system shows unhashed kernel memory addresses **
[ 0.000000] ** via the console, logs, and other interfaces. This **
[ 0.000000] ** might reduce the security of your system. **
[ 0.000000] ** **
[ 0.000000] ** If you see this message and you are not debugging **
[ 0.000000] ** the kernel, report this immediately to your system **
[ 0.000000] ** administrator! **
[ 0.000000] ** **
[ 0.000000] ** Use hash_pointers=always to force this mode off **
[ 0.000000] ** **
[ 0.000000] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.000000] **********************************************************
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 77902 entries in 306 pages
[ 0.000000] ftrace: allocated 306 pages with 4 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] RCU Tasks Rude: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[ 0.000000] GICv3: 256 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] Root IRQ handler: gic_handle_irq
[ 0.000000] GICv3: GICv3 features: 16 PPIs
[ 0.000000] GICv3: GICD_CTLR.DS=0, SCR_EL3.FIQ=1
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000001880000
[ 0.000000] ITS [mem 0x01820000-0x0182ffff]
[ 0.000000] GIC: enabling workaround for ITS: Socionext Synquacer pre-ITS
[ 0.000000] ITS@0x0000000001820000: Devices Table too large, reduce ids 20->19
[ 0.000000] ITS@0x0000000001820000: allocated 524288 Devices @880800000 (flat, esz 8, psz 64K, shr 0)
[ 0.000000] ITS: using cache flushing for cmd queue
[ 0.000000] GICv3: using LPI property table @0x0000000880350000
[ 0.000000] GIC: using cache flushing for LPI property table
[ 0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000880360000
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] arch_timer: cp15 timer running at 200.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0x3ffffffffffffff max_cycles: 0x2e2049d3e8, max_idle_ns: 440795210634 ns
[ 0.000000] sched_clock: 58 bits at 200MHz, resolution 5ns, wraps every 4398046511102ns
[ 0.000768] Console: colour dummy device 80x25
[ 0.000905] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=800000)
[ 0.000915] pid_max: default: 32768 minimum: 301
[ 0.001293] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 0.001319] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 0.004990] rcu: Hierarchical SRCU implementation.
[ 0.005003] rcu: Max phase no-delay instances is 1000.
[ 0.005338] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[ 0.005539] EFI services will not be available.
[ 0.005897] smp: Bringing up secondary CPUs ...
[ 0.014795] Detected VIPT I-cache on CPU1
[ 0.014915] GICv3: CPU1: found redistributor 1 region 0:0x00000000018a0000
[ 0.014929] GICv3: CPU1: using allocated LPI pending table @0x0000000880370000
[ 0.014977] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[ 0.024011] Detected VIPT I-cache on CPU2
[ 0.024110] GICv3: CPU2: found redistributor 2 region 0:0x00000000018c0000
[ 0.024123] GICv3: CPU2: using allocated LPI pending table @0x0000000880380000
[ 0.024159] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[ 0.033103] Detected VIPT I-cache on CPU3
[ 0.033195] GICv3: CPU3: found redistributor 3 region 0:0x00000000018e0000
[ 0.033208] GICv3: CPU3: using allocated LPI pending table @0x0000000880390000
[ 0.033244] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[ 0.033354] smp: Brought up 1 node, 4 CPUs
[ 0.033360] SMP: Total of 4 processors activated.
[ 0.033362] CPU: All CPU(s) started at EL2
[ 0.033392] CPU features: detected: 32-bit EL0 Support
[ 0.033395] CPU features: detected: 32-bit EL1 Support
[ 0.033399] CPU features: detected: CRC32 instructions
[ 0.033408] CPU features: detected: PMUv3
[ 0.033449] alternatives: applying system-wide alternatives
[ 0.035494] Memory: 7795152K/8388608K available (24448K kernel code, 3286K rwdata, 12924K rodata, 3200K init, 527K bss, 320344K reserved, 262144K cma-reserved)
[ 0.036917] devtmpfs: initialized
[ 0.073902] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.073946] posixtimers hash table entries: 2048 (order: 3, 32768 bytes, linear)
[ 0.073995] futex hash table entries: 1024 (65536 bytes on 1 NUMA nodes, total 64 KiB, linear).
[ 0.077302] 2G module region forced by RANDOMIZE_MODULE_REGION_FULL
[ 0.077338] 0 pages in range for non-PLT usage
[ 0.077343] 513136 pages in range for PLT usage
[ 0.080465]
[ 0.080475] *************************************************************
[ 0.080477] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.080479] ** **
[ 0.080481] ** IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS KERNEL **
[ 0.080483] ** **
[ 0.080484] ** This means that this kernel is built to expose internal **
[ 0.080486] ** IOMMU data structures, which may compromise security on **
[ 0.080488] ** your system. **
[ 0.080490] ** **
[ 0.080492] ** If you see this message and you are not debugging the **
[ 0.080493] ** kernel, report this immediately to your vendor! **
[ 0.080496] ** **
[ 0.080497] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
[ 0.080499] *************************************************************
[ 0.080914] DMI not present or invalid.
[ 0.083305] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.084747] DMA: preallocated 1024 KiB GFP_KERNEL pool for atomic allocations
[ 0.084897] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[ 0.085026] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[ 0.085126] audit: initializing netlink subsys (disabled)
[ 0.085468] audit: type=2000 audit(0.084:1): state=initialized audit_enabled=0 res=1
[ 0.086125] gpiolib_shared: Created a secondary shared GPIO reference for potential reset-gpio device for GPIO 10 at gpio@600000
[ 0.086372] gpiolib_shared: Created a secondary shared GPIO reference for potential reset-gpio device for GPIO 15 at gpio@601000
[ 0.086528] gpiolib_shared: GPIO 7 at gpio@600000 is shared by multiple firmware nodes
[ 0.086583] gpiolib_shared: GPIO 4 at pmic@44 is shared by multiple firmware nodes
[ 0.086753] gpiolib_shared: Finished scanning firmware nodes for shared GPIOs
[ 0.088766] thermal_sys: Registered thermal governor 'step_wise'
[ 0.088884] cpuidle: using governor menu
[ 0.089362] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 0.089468] ASID allocator initialised with 32768 entries
[ 0.090816] Serial: AMBA PL011 UART driver
[ 0.097535] /bus@f0000/interrupt-controller@1800000: Fixed dependency cycle(s) with /bus@f0000/interrupt-controller@1800000
[ 0.097672] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.097684] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /connector-2
[ 0.098118] /bus@f0000/dss@30220000: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.098148] /bus@f0000/dsi@30500000: Fixed dependency cycle(s) with /bus@f0000/i2c@20000000/bridge@2c
[ 0.098161] /bus@f0000/dsi@30500000: Fixed dependency cycle(s) with /bus@f0000/dss@30220000
[ 0.109935] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.109956] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /connector-2
[ 0.115336] /bus@f0000/dss@30220000: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.115784] /bus@f0000/dss@30220000: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.115965] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.116148] /bus@f0000/dsi@30500000: Fixed dependency cycle(s) with /bus@f0000/i2c@20000000/bridge@2c
[ 0.116163] /bus@f0000/dsi@30500000: Fixed dependency cycle(s) with /bus@f0000/dss@30220000
[ 0.117744] /bus@f0000/pcie@f102000: Fixed dependency cycle(s) with /bus@f0000/pcie@f102000/interrupt-controller
[ 0.118873] /bus@f0000/usb@f900000/usb@31000000: Fixed dependency cycle(s) with /connector-1
[ 0.119081] /connector-1: Fixed dependency cycle(s) with /bus@f0000/usb@f900000/usb@31000000
[ 0.125763] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
[ 0.125776] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
[ 0.125780] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
[ 0.125783] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page
[ 0.125786] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.125789] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
[ 0.125792] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
[ 0.125795] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
[ 0.130707] ACPI: Interpreter disabled.
[ 0.131890] k3-chipinfo 43000014.chipid: Family:J722S rev:SR1.0 JTAGID[0x0bba002f] Detected
[ 0.132924] reg-fixed-voltage regulator-1: using DT '/regulator-1' for '(default)' GPIO lookup
[ 0.132979] of_get_named_gpiod_flags: can't parse 'gpios' property of node '/regulator-1[0]'
[ 0.133013] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/regulator-1[0]'
[ 0.133023] reg-fixed-voltage regulator-1: using lookup tables for GPIO lookup
[ 0.133028] reg-fixed-voltage regulator-1: No GPIO consumer (default) found
[ 0.133595] reg-fixed-voltage regulator-2: using DT '/regulator-2' for '(default)' GPIO lookup
[ 0.133638] of_get_named_gpiod_flags: can't parse 'gpios' property of node '/regulator-2[0]'
[ 0.133672] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/regulator-2[0]'
[ 0.133681] reg-fixed-voltage regulator-2: using lookup tables for GPIO lookup
[ 0.133685] reg-fixed-voltage regulator-2: No GPIO consumer (default) found
[ 0.133829] iommu: Default domain type: Translated
[ 0.133837] iommu: DMA domain TLB invalidation policy: strict mode
[ 0.133874] reg-fixed-voltage regulator-3: using DT '/regulator-3' for '(default)' GPIO lookup
[ 0.133917] of_get_named_gpiod_flags: can't parse 'gpios' property of node '/regulator-3[0]'
[ 0.133950] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/regulator-3[0]'
[ 0.133959] reg-fixed-voltage regulator-3: using lookup tables for GPIO lookup
[ 0.133963] reg-fixed-voltage regulator-3: No GPIO consumer (default) found
[ 0.135533] SCSI subsystem initialized
[ 0.135968] libata version 3.00 loaded.
[ 0.136684] usbcore: registered new interface driver usbfs
[ 0.136834] usbcore: registered new interface driver hub
[ 0.136928] usbcore: registered new device driver usb
[ 0.138760] mc: Linux media interface: v0.10
[ 0.138894] videodev: Linux video capture interface: v2.00
[ 0.139094] pps_core: LinuxPPS API ver. 1 registered
[ 0.139098] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.139148] PTP clock support registered
[ 0.139258] EDAC MC: Ver: 3.0.0
[ 0.141796] FPGA manager framework
[ 0.142162] Advanced Linux Sound Architecture Driver Initialized.
[ 0.144034] nfc: nfc_init: NFC Core ver 0.1
[ 0.144211] NET: Registered PF_NFC protocol family
[ 0.144855] vgaarb: loaded
[ 0.145797] clocksource: Switched to clocksource arch_sys_counter
[ 0.146836] VFS: Disk quotas dquot_6.6.0
[ 0.146886] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.148369] pnp: PnP ACPI: disabled
[ 0.163926] NET: Registered PF_INET protocol family
[ 0.164248] IP idents hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 0.169154] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear)
[ 0.169223] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.169264] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
[ 0.169655] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
[ 0.171216] TCP: Hash tables configured (established 65536 bind 65536)
[ 0.171485] UDP hash table entries: 4096 (order: 6, 262144 bytes, linear)
[ 0.171699] UDP-Lite hash table entries: 4096 (order: 6, 262144 bytes, linear)
[ 0.172205] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.173282] RPC: Registered named UNIX socket transport module.
[ 0.173292] RPC: Registered udp transport module.
[ 0.173295] RPC: Registered tcp transport module.
[ 0.173297] RPC: Registered tcp-with-tls transport module.
[ 0.173299] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.174931] PCI: CLS 0 bytes, default 64
[ 0.185302] kvm [1]: nv: 568 coarse grained trap handlers
[ 0.185910] kvm [1]: IPA Size Limit: 40 bits
[ 0.188173] kvm [1]: vgic-v2@100020000
[ 0.188197] kvm [1]: GICv3 sysreg trapping enabled ([C], reduced performance)
[ 0.188219] kvm [1]: GIC system register CPU interface enabled
[ 0.188269] kvm [1]: vgic interrupt IRQ9
[ 0.188300] kvm [1]: Hyp nVHE mode initialized successfully
[ 0.192252] Initialise system trusted keyrings
[ 0.192682] workingset: timestamp_bits=44 max_order=21 bucket_order=0
[ 0.197812] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.198605] NFS: Registering the id_resolver key type
[ 0.198649] Key type id_resolver registered
[ 0.198653] Key type id_legacy registered
[ 0.198717] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.198733] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 0.199201] 9p: Installing v9fs 9p2000 file system support
[ 0.199930] cryptd: max_cpu_qlen set to 1000
[ 0.249756] NET: Registered PF_ALG protocol family
[ 0.249790] Key type asymmetric registered
[ 0.249793] Asymmetric key parser 'x509' registered
[ 0.250006] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[ 0.250015] io scheduler mq-deadline registered
[ 0.250018] io scheduler kyber registered
[ 0.265257] pinctrl-single 4084000.pinctrl: 34 pins, size 136
[ 0.267673] pinctrl-single f4000.pinctrl: 172 pins, size 688
[ 0.286821] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.311058] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled
[ 0.328232] display-connector connector-2: using DT '/connector-2' for 'hpd' GPIO lookup
[ 0.328326] display-connector connector-2: No GPIO consumer hpd found
[ 0.346493] loop: module loaded
[ 0.359757] mdio_bus fixed-0: using lookup tables for GPIO lookup
[ 0.359771] mdio_bus fixed-0: No GPIO consumer reset found
[ 0.370734] tun: Universal TUN/TAP device driver, 1.6
[ 0.371335] CAN device driver interface
[ 0.375208] e1000: Intel(R) PRO/1000 Network Driver
[ 0.375217] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 0.375347] e1000e: Intel(R) PRO/1000 Network Driver
[ 0.375350] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 0.375476] igb: Intel(R) Gigabit Ethernet Network Driver
[ 0.375479] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 0.375600] Intel(R) 2.5G Ethernet Linux Driver
[ 0.375603] Copyright(c) 2018 Intel Corporation.
[ 0.375727] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver
[ 0.375730] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[ 0.376248] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[ 0.376256] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
[ 0.380214] usbcore: registered new interface driver rt2500usb
[ 0.381193] VFIO - User Level meta-driver version: 0.3
[ 0.386365] usbcore: registered new interface driver usb-storage
[ 0.388916] UDC core: g_ether: couldn't find an available UDC
[ 0.389015] UDC core: g_mass_storage: couldn't find an available UDC
[ 0.389102] UDC core: g_serial: couldn't find an available UDC
[ 0.391916] i2c_dev: i2c /dev entries driver
[ 0.399157] device-mapper: ioctl: 4.50.0-ioctl (2025-04-28) initialised: dm-devel@lists.linux.dev
[ 0.399546] device-mapper: multipath round-robin: version 1.2.0 loaded
[ 0.399557] device-mapper: multipath queue-length: version 0.2.0 loaded
[ 0.399565] device-mapper: multipath service-time: version 0.3.0 loaded
[ 0.399573] device-mapper: multipath historical-service-time: version 0.1.1 loaded
[ 0.401855] sdhci: Secure Digital Host Controller Interface driver
[ 0.401863] sdhci: Copyright(c) Pierre Ossman
[ 0.402880] Synopsys Designware Multimedia Card Interface Driver
[ 0.403621] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.405431] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....
[ 0.408699] usbcore: registered new interface driver usbhid
[ 0.408709] usbhid: USB HID core driver
[ 0.409111] gpib_common: GPIB core driver
[ 0.422122] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 (0,8000003f) counters available
[ 0.424854] optee: probing for conduit method.
[ 0.424888] optee: revision 4.7
[ 0.441736] optee: dynamic shared memory is enabled
[ 0.442760] optee: initialized driver
[ 0.442800] random: crng init done
[ 0.448117] drop_monitor: Initializing network drop monitor service
[ 0.448591] NET: Registered PF_INET6 protocol family
[ 0.450331] Segment Routing with IPv6
[ 0.450462] In-situ OAM (IOAM) with IPv6
[ 0.450574] NET: Registered PF_PACKET protocol family
[ 0.450943] can: controller area network core
[ 0.451023] NET: Registered PF_CAN protocol family
[ 0.451028] can: raw protocol
[ 0.451033] can: broadcast manager protocol
[ 0.451043] can: netlink gateway - max_hops=1
[ 0.451211] 8021q: 802.1Q VLAN Support v1.8
[ 0.451275] 9pnet: Installing 9P2000 support
[ 0.451428] Key type dns_resolver registered
[ 0.489596] registered taskstats version 1
[ 0.489619] Loading compiled-in X.509 certificates
[ 0.523182] Demotion targets for Node 0: null
[ 0.524429] Key type encrypted registered
[ 0.539208] display-connector connector-2: using DT '/connector-2' for 'hpd' GPIO lookup
[ 0.539269] display-connector connector-2: No GPIO consumer hpd found
[ 0.550927] ti-sci 44043000.system-controller: ABI: 4.0 (firmware rev 0x000b '11.1.9--v11.01.09 (Fancy Rat)')
[ 0.671150] i2c i2c-0: using DT '/bus@f0000/bus@4000000/i2c@4900000' for 'scl' GPIO lookup
[ 0.671219] of_get_named_gpiod_flags: can't parse 'scl-gpios' property of node '/bus@f0000/bus@4000000/i2c@4900000[0]'
[ 0.671257] of_get_named_gpiod_flags: can't parse 'scl-gpio' property of node '/bus@f0000/bus@4000000/i2c@4900000[0]'
[ 0.671269] i2c i2c-0: using lookup tables for GPIO lookup
[ 0.671274] i2c i2c-0: No GPIO consumer scl found
[ 0.671290] i2c i2c-0: using DT '/bus@f0000/bus@4000000/i2c@4900000' for 'sda' GPIO lookup
[ 0.671331] of_get_named_gpiod_flags: can't parse 'sda-gpios' property of node '/bus@f0000/bus@4000000/i2c@4900000[0]'
[ 0.671366] of_get_named_gpiod_flags: can't parse 'sda-gpio' property of node '/bus@f0000/bus@4000000/i2c@4900000[0]'
[ 0.671377] i2c i2c-0: using lookup tables for GPIO lookup
[ 0.671380] i2c i2c-0: No GPIO consumer sda found
[ 0.671685] omap_i2c 4900000.i2c: bus 0 rev0.12 at 100 kHz
[ 0.674478] i2c i2c-1: using DT '/bus@f0000/bus@b00000/i2c@2b200000' for 'scl' GPIO lookup
[ 0.674538] of_get_named_gpiod_flags: can't parse 'scl-gpios' property of node '/bus@f0000/bus@b00000/i2c@2b200000[0]'
[ 0.674575] of_get_named_gpiod_flags: can't parse 'scl-gpio' property of node '/bus@f0000/bus@b00000/i2c@2b200000[0]'
[ 0.674588] i2c i2c-1: using lookup tables for GPIO lookup
[ 0.674592] i2c i2c-1: No GPIO consumer scl found
[ 0.674608] i2c i2c-1: using DT '/bus@f0000/bus@b00000/i2c@2b200000' for 'sda' GPIO lookup
[ 0.674647] of_get_named_gpiod_flags: can't parse 'sda-gpios' property of node '/bus@f0000/bus@b00000/i2c@2b200000[0]'
[ 0.674681] of_get_named_gpiod_flags: can't parse 'sda-gpio' property of node '/bus@f0000/bus@b00000/i2c@2b200000[0]'
[ 0.674692] i2c i2c-1: using lookup tables for GPIO lookup
[ 0.674695] i2c i2c-1: No GPIO consumer sda found
[ 0.674722] omap_i2c 2b200000.i2c: bus 1 rev0.12 at 100 kHz
[ 0.676227] i2c i2c-2: using DT '/bus@f0000/i2c@20000000' for 'scl' GPIO lookup
[ 0.676277] of_get_named_gpiod_flags: can't parse 'scl-gpios' property of node '/bus@f0000/i2c@20000000[0]'
[ 0.676313] of_get_named_gpiod_flags: can't parse 'scl-gpio' property of node '/bus@f0000/i2c@20000000[0]'
[ 0.676323] i2c i2c-2: using lookup tables for GPIO lookup
[ 0.676327] i2c i2c-2: No GPIO consumer scl found
[ 0.676343] i2c i2c-2: using DT '/bus@f0000/i2c@20000000' for 'sda' GPIO lookup
[ 0.676378] of_get_named_gpiod_flags: can't parse 'sda-gpios' property of node '/bus@f0000/i2c@20000000[0]'
[ 0.676411] of_get_named_gpiod_flags: can't parse 'sda-gpio' property of node '/bus@f0000/i2c@20000000[0]'
[ 0.676420] i2c i2c-2: using lookup tables for GPIO lookup
[ 0.676424] i2c i2c-2: No GPIO consumer sda found
[ 0.677271] /bus@f0000/dsi@30500000: Fixed dependency cycle(s) with /bus@f0000/i2c@20000000/bridge@2c
[ 0.677457] /connector-2: Fixed dependency cycle(s) with /bus@f0000/i2c@20000000/bridge@2c
[ 0.677751] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /bus@f0000/dsi@30500000
[ 0.677923] /bus@f0000/i2c@20000000/bridge@2c: Fixed dependency cycle(s) with /connector-2
[ 0.695532] sl28cpld-wdt 20000000.i2c:system-controller@4a:watchdog@4: initial timeout 10 sec
[ 0.697244] omap_i2c 20000000.i2c: bus 2 rev0.12 at 100 kHz
[ 0.699285] i2c i2c-3: using DT '/bus@f0000/i2c@20020000' for 'scl' GPIO lookup
[ 0.699343] of_get_named_gpiod_flags: can't parse 'scl-gpios' property of node '/bus@f0000/i2c@20020000[0]'
[ 0.699377] of_get_named_gpiod_flags: can't parse 'scl-gpio' property of node '/bus@f0000/i2c@20020000[0]'
[ 0.699388] i2c i2c-3: using lookup tables for GPIO lookup
[ 0.699392] i2c i2c-3: No GPIO consumer scl found
[ 0.699408] i2c i2c-3: using DT '/bus@f0000/i2c@20020000' for 'sda' GPIO lookup
[ 0.699446] of_get_named_gpiod_flags: can't parse 'sda-gpios' property of node '/bus@f0000/i2c@20020000[0]'
[ 0.699479] of_get_named_gpiod_flags: can't parse 'sda-gpio' property of node '/bus@f0000/i2c@20020000[0]'
[ 0.699487] i2c i2c-3: using lookup tables for GPIO lookup
[ 0.699491] i2c i2c-3: No GPIO consumer sda found
[ 0.700196] omap_i2c 20020000.i2c: bus 3 rev0.12 at 100 kHz
[ 0.702043] i2c i2c-4: using DT '/bus@f0000/i2c@20030000' for 'scl' GPIO lookup
[ 0.702098] of_get_named_gpiod_flags: can't parse 'scl-gpios' property of node '/bus@f0000/i2c@20030000[0]'
[ 0.702133] of_get_named_gpiod_flags: can't parse 'scl-gpio' property of node '/bus@f0000/i2c@20030000[0]'
[ 0.702145] i2c i2c-4: using lookup tables for GPIO lookup
[ 0.702149] i2c i2c-4: No GPIO consumer scl found
[ 0.702165] i2c i2c-4: using DT '/bus@f0000/i2c@20030000' for 'sda' GPIO lookup
[ 0.702199] of_get_named_gpiod_flags: can't parse 'sda-gpios' property of node '/bus@f0000/i2c@20030000[0]'
[ 0.702232] of_get_named_gpiod_flags: can't parse 'sda-gpio' property of node '/bus@f0000/i2c@20030000[0]'
[ 0.702241] i2c i2c-4: using lookup tables for GPIO lookup
[ 0.702245] i2c i2c-4: No GPIO consumer sda found
[ 0.702271] omap_i2c 20030000.i2c: bus 4 rev0.12 at 100 kHz
[ 0.702758] ti-sci-intr 4210000.interrupt-controller: Interrupt Router 5 domain created
[ 0.703079] ti-sci-intr bus@f0000:interrupt-controller@a00000: Interrupt Router 3 domain created
[ 0.703497] debugfs: ':bus@f0000:bus@48000000:interrupt-controller@48000000' already exists in 'domains'
[ 0.703560] ti-sci-inta 48000000.interrupt-controller: Interrupt Aggregator domain 28 created
[ 0.704088] debugfs: ':bus@f0000:bus@4e000000:interrupt-controller@4e400000' already exists in 'domains'
[ 0.704139] ti-sci-inta 4e400000.interrupt-controller: Interrupt Aggregator domain 200 created
[ 0.706053] wiz bus@f0000:phy@f000000: using DT '/bus@f0000/phy@f000000' for 'typec-dir' GPIO lookup
[ 0.706103] of_get_named_gpiod_flags: can't parse 'typec-dir-gpios' property of node '/bus@f0000/phy@f000000[0]'
[ 0.706138] of_get_named_gpiod_flags: can't parse 'typec-dir-gpio' property of node '/bus@f0000/phy@f000000[0]'
[ 0.706149] wiz bus@f0000:phy@f000000: using lookup tables for GPIO lookup
[ 0.706153] wiz bus@f0000:phy@f000000: No GPIO consumer typec-dir found
[ 0.709256] wiz bus@f0000:phy@f010000: using DT '/bus@f0000/phy@f010000' for 'typec-dir' GPIO lookup
[ 0.709303] of_get_named_gpiod_flags: can't parse 'typec-dir-gpios' property of node '/bus@f0000/phy@f010000[0]'
[ 0.709339] of_get_named_gpiod_flags: can't parse 'typec-dir-gpio' property of node '/bus@f0000/phy@f010000[0]'
[ 0.709350] wiz bus@f0000:phy@f010000: using lookup tables for GPIO lookup
[ 0.709355] wiz bus@f0000:phy@f010000: No GPIO consumer typec-dir found
[ 0.712757] ti-udma 485c0100.dma-controller: Number of rings: 82
[ 0.719444] ti-udma 485c0100.dma-controller: Channels: 44 (bchan: 16, tchan: 12, rchan: 16)
[ 0.726107] ti-udma 485c0000.dma-controller: Number of rings: 150
[ 0.738618] ti-udma 485c0000.dma-controller: Channels: 35 (tchan: 20, rchan: 15)
[ 0.744113] ti-udma 4e230000.dma-controller: Number of rings: 40
[ 0.748079] ti-udma 4e230000.dma-controller: Channels: 20 (bchan: 0, tchan: 8, rchan: 12)
[ 0.752858] omap8250 4a00000.serial: using DT '/bus@f0000/bus@4000000/serial@4a00000' for 'rs485-term' GPIO lookup
[ 0.752920] of_get_named_gpiod_flags: can't parse 'rs485-term-gpios' property of node '/bus@f0000/bus@4000000/serial@4a00000[0]'
[ 0.752958] of_get_named_gpiod_flags: can't parse 'rs485-term-gpio' property of node '/bus@f0000/bus@4000000/serial@4a00000[0]'
[ 0.752970] omap8250 4a00000.serial: using lookup tables for GPIO lookup
[ 0.752975] omap8250 4a00000.serial: No GPIO consumer rs485-term found
[ 0.752980] omap8250 4a00000.serial: using DT '/bus@f0000/bus@4000000/serial@4a00000' for 'rs485-rx-during-tx' GPIO lookup
[ 0.753020] of_get_named_gpiod_flags: can't parse 'rs485-rx-during-tx-gpios' property of node '/bus@f0000/bus@4000000/serial@4a00000[0]'
[ 0.753055] of_get_named_gpiod_flags: can't parse 'rs485-rx-during-tx-gpio' property of node '/bus@f0000/bus@4000000/serial@4a00000[0]'
[ 0.753066] omap8250 4a00000.serial: using lookup tables for GPIO lookup
[ 0.753069] omap8250 4a00000.serial: No GPIO consumer rs485-rx-during-tx found
[ 0.753624] 4a00000.serial: ttyS0 at MMIO 0x4a00000 (irq = 273, base_baud = 3000000) is a 8250
[ 0.756162] omap8250 2800000.serial: using DT '/bus@f0000/serial@2800000' for 'rs485-term' GPIO lookup
[ 0.756219] of_get_named_gpiod_flags: can't parse 'rs485-term-gpios' property of node '/bus@f0000/serial@2800000[0]'
[ 0.756256] of_get_named_gpiod_flags: can't parse 'rs485-term-gpio' property of node '/bus@f0000/serial@2800000[0]'
[ 0.756267] omap8250 2800000.serial: using lookup tables for GPIO lookup
[ 0.756271] omap8250 2800000.serial: No GPIO consumer rs485-term found
[ 0.756276] omap8250 2800000.serial: using DT '/bus@f0000/serial@2800000' for 'rs485-rx-during-tx' GPIO lookup
[ 0.756312] of_get_named_gpiod_flags: can't parse 'rs485-rx-during-tx-gpios' property of node '/bus@f0000/serial@2800000[0]'
[ 0.756346] of_get_named_gpiod_flags: can't parse 'rs485-rx-during-tx-gpio' property of node '/bus@f0000/serial@2800000[0]'
[ 0.756355] omap8250 2800000.serial: using lookup tables for GPIO lookup
[ 0.756358] omap8250 2800000.serial: No GPIO consumer rs485-rx-during-tx found
[ 0.756869] 2800000.serial: ttyS1 at MMIO 0x2800000 (irq = 274, base_baud = 3000000) is a 8250
[ 0.756922] printk: legacy console [ttyS1] enabled
[ 3.713285] omap8250 2850000.serial: using DT '/bus@f0000/serial@2850000' for 'rs485-term' GPIO lookup
[ 3.722659] of_get_named_gpiod_flags: can't parse 'rs485-term-gpios' property of node '/bus@f0000/serial@2850000[0]'
[ 3.733205] of_get_named_gpiod_flags: can't parse 'rs485-term-gpio' property of node '/bus@f0000/serial@2850000[0]'
[ 3.743633] omap8250 2850000.serial: using lookup tables for GPIO lookup
[ 3.750327] omap8250 2850000.serial: No GPIO consumer rs485-term found
[ 3.756847] omap8250 2850000.serial: using DT '/bus@f0000/serial@2850000' for 'rs485-rx-during-tx' GPIO lookup
[ 3.766866] of_get_named_gpiod_flags: can't parse 'rs485-rx-during-tx-gpios' property of node '/bus@f0000/serial@2850000[0]'
[ 3.778101] of_get_named_gpiod_flags: can't parse 'rs485-rx-during-tx-gpio' property of node '/bus@f0000/serial@2850000[0]'
[ 3.789221] omap8250 2850000.serial: using lookup tables for GPIO lookup
[ 3.795914] omap8250 2850000.serial: No GPIO consumer rs485-rx-during-tx found
[ 3.803680] 2850000.serial: ttyS2 at MMIO 0x2850000 (irq = 275, base_baud = 3000000) is a 8250
[ 3.813756] display-connector connector-2: using DT '/connector-2' for 'hpd' GPIO lookup
[ 3.822222] display-connector connector-2: No GPIO consumer hpd found
[ 3.838689] powervr fd80000.gpu: [drm] loaded firmware powervr/rogue_36.53.104.796_v1.fw
[ 3.846822] powervr fd80000.gpu: [drm] FW version v1.0 (build 6734358 OS)
[ 3.860510] [drm] Initialized powervr 1.0.0 for fd80000.gpu on minor 0
[ 3.872418] m_can_platform 4e08000.can: using DT '/bus@f0000/bus@4000000/can@4e08000' for 'termination' GPIO lookup
[ 3.882959] of_get_named_gpiod_flags: can't parse 'termination-gpios' property of node '/bus@f0000/bus@4000000/can@4e08000[0]'
[ 3.894377] of_get_named_gpiod_flags: can't parse 'termination-gpio' property of node '/bus@f0000/bus@4000000/can@4e08000[0]'
[ 3.905677] m_can_platform 4e08000.can: using lookup tables for GPIO lookup
[ 3.912633] m_can_platform 4e08000.can: No GPIO consumer termination found
[ 3.920481] m_can_platform 4e08000.can can0: device registered (irq=280, version=32)
[ 3.930159] m_can_platform 4e18000.can: using DT '/bus@f0000/bus@4000000/can@4e18000' for 'termination' GPIO lookup
[ 3.940679] of_get_named_gpiod_flags: can't parse 'termination-gpios' property of node '/bus@f0000/bus@4000000/can@4e18000[0]'
[ 3.952092] of_get_named_gpiod_flags: can't parse 'termination-gpio' property of node '/bus@f0000/bus@4000000/can@4e18000[0]'
[ 3.963394] m_can_platform 4e18000.can: using lookup tables for GPIO lookup
[ 3.970351] m_can_platform 4e18000.can: No GPIO consumer termination found
[ 3.978188] m_can_platform 4e18000.can can1: device registered (irq=281, version=32)
[ 3.987587] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01903, cpsw version 0x6BA81903 Ports: 3 quirks:00000002
[ 4.003869] /connector-1: Fixed dependency cycle(s) with /bus@f0000/usb@f900000/usb@31000000
[ 4.012702] /bus@f0000/usb@f900000/usb@31000000: Fixed dependency cycle(s) with /connector-1
[ 4.027804] rtc-ti-k3 2b1f0000.rtc: Clock rate 32552 is not 32768! Could misbehave!
[ 4.030149] g_ether gadget.0: HOST MAC 8e:c7:a5:36:aa:f4
[ 4.037551] rtc-ti-k3 2b1f0000.rtc: registered as rtc1
[ 4.040801] g_ether gadget.0: MAC 4e:a1:cb:72:69:f9
[ 4.045954] rtc-ti-k3 2b1f0000.rtc: using DT '/bus@f0000/bus@b00000/rtc@2b1f0000' for 'wp' GPIO lookup
[ 4.051060] g_ether gadget.0: Ethernet Gadget, version: Memorial Day 2008
[ 4.060135] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/bus@f0000/bus@b00000/rtc@2b1f0000[0]'
[ 4.066872] g_ether gadget.0: g_ether ready
[ 4.077478] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/bus@f0000/bus@b00000/rtc@2b1f0000[0]'
[ 4.092140] rtc-ti-k3 2b1f0000.rtc: using lookup tables for GPIO lookup
[ 4.098755] rtc-ti-k3 2b1f0000.rtc: No GPIO consumer wp found
[ 4.106169] vdec 30210000.video-codec: sram node not found
[ 4.115238] vdec 30210000.video-codec: Added wave5 driver with caps: 'ENCODE' 'DECODE'
[ 4.123202] vdec 30210000.video-codec: Product Code: 0x521c
[ 4.129213] vdec 30210000.video-codec: Firmware Revision: 363254
[ 4.153362] sdhci-am654 fa10000.mmc: using DT '/bus@f0000/mmc@fa10000' for 'cd' GPIO lookup
[ 4.161830] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/bus@f0000/mmc@fa10000[0]'
[ 4.171442] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/bus@f0000/mmc@fa10000[0]'
[ 4.180924] sdhci-am654 fa10000.mmc: using lookup tables for GPIO lookup
[ 4.187625] sdhci-am654 fa10000.mmc: No GPIO consumer cd found
[ 4.193460] sdhci-am654 fa10000.mmc: using DT '/bus@f0000/mmc@fa10000' for 'wp' GPIO lookup
[ 4.201842] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/bus@f0000/mmc@fa10000[0]'
[ 4.211447] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/bus@f0000/mmc@fa10000[0]'
[ 4.220927] sdhci-am654 fa10000.mmc: using lookup tables for GPIO lookup
[ 4.227627] sdhci-am654 fa10000.mmc: No GPIO consumer wp found
[ 4.233736] mmc0: CQHCI version 5.10
[ 4.238614] gpiochip_find_base_unlocked: found new base at 512
[ 4.244548] gpio gpiochip0: (4201000.gpio): created GPIO range 0->20 ==> 4084000.pinctrl PIN 0->20
[ 4.253526] gpio gpiochip0: (4201000.gpio): created GPIO range 21->21 ==> 4084000.pinctrl PIN 23->23
[ 4.262660] gpio gpiochip0: (4201000.gpio): created GPIO range 22->23 ==> 4084000.pinctrl PIN 32->33
[ 4.272162] gpio gpiochip0: (4201000.gpio): added GPIO chardev (254:0)
[ 4.279015] gpio gpiochip0: registered GPIOs 512 to 535 on 4201000.gpio
[ 4.289182] gpiochip_find_base_unlocked: found new base at 536
[ 4.295124] gpio gpiochip1: (600000.gpio): created GPIO range 0->31 ==> f4000.pinctrl PIN 0->31
[ 4.303836] gpio gpiochip1: (600000.gpio): created GPIO range 32->69 ==> f4000.pinctrl PIN 33->70
[ 4.312710] gpio gpiochip1: (600000.gpio): created GPIO range 70->86 ==> f4000.pinctrl PIN 72->88
[ 4.312796] mmc0: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit
[ 4.321583] gpiolib_shared: GPIO 7 owned by 600000.gpio is shared by multiple consumers
[ 4.337049] gpiolib_shared: Setting up a shared GPIO entry for regulator-5 (con_id: '(none)')
[ 4.345868] gpiolib_shared: Created an auxiliary GPIO proxy gpiolib_shared.proxy.9 for GPIO device 600000.gpio
[ 4.355865] gpiolib_shared: Setting up a shared GPIO entry for regulator-6 (con_id: 'enable')
[ 4.364570] gpiolib_shared: Created an auxiliary GPIO proxy gpiolib_shared.proxy.10 for GPIO device 600000.gpio
[ 4.375011] gpio gpiochip1: (600000.gpio): added GPIO chardev (254:1)
[ 4.381881] gpio gpiochip1: registered GPIOs 536 to 622 on 600000.gpio
[ 4.388708] mmc0: Command Queue Engine enabled
[ 4.393217] mmc0: new HS200 MMC card at address 0001
[ 4.398947] gpiochip_find_base_unlocked: found new base at 623
[ 4.399898] mmcblk0: mmc0:0001 0IM20F 59.3 GiB
[ 4.404893] gpio gpiochip2: (601000.gpio): created GPIO range 7->31 ==> f4000.pinctrl PIN 101->125
[ 4.418294] gpio gpiochip2: (601000.gpio): created GPIO range 42->46 ==> f4000.pinctrl PIN 137->141
[ 4.419153] GPT:disk_guids don't match.
[ 4.427365] gpio gpiochip2: (601000.gpio): created GPIO range 47->49 ==> f4000.pinctrl PIN 143->145
[ 4.431185] GPT: Use GNU Parted to correct GPT errors.
[ 4.440238] gpio gpiochip2: (601000.gpio): created GPIO range 50->51 ==> f4000.pinctrl PIN 149->150
[ 4.445382] mmcblk0: p1 p2
[ 4.454788] gpio gpiochip2: (601000.gpio): added GPIO chardev (254:2)
[ 4.458896] mmcblk0boot0: mmc0:0001 0IM20F 31.5 MiB
[ 4.463948] gpio gpiochip2: registered GPIOs 623 to 695 on 601000.gpio
[ 4.475568] mmcblk0boot1: mmc0:0001 0IM20F 31.5 MiB
[ 4.483984] reg-fixed-voltage regulator-5: using DT '/regulator-5' for '(default)' GPIO lookup
[ 4.485057] reg-fixed-voltage regulator-7: using DT '/regulator-7' for '(default)' GPIO lookup
[ 4.486253] mmcblk0rpmb: mmc0:0001 0IM20F 4.00 MiB, cha)
[ 4.488136] reg-fixed-voltage regulator-10: using DT '/regulator-10' for '(default)' GPIO lookup
[ 4.488239] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-10[0]' - status (0)
[ 4.488277] gpio gpiochip1: Persistence not supported for GPIO 30
[ 4.489059] reg-fixed-voltage regulator-11: using DT '/regulator-11' for '(default)' GPIO lookup
[ 4.489129] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-11[0]' - status (0)
[ 4.489165] gpio gpiochip2: Persistence not supported for GPIO 19
[ 4.490325] reg-fixed-voltage regulator-12: using DT '/regulator-12' for '(default)' GPIO lookup
[ 4.490467] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-12[0]' - status (0)
[ 4.490508] gpio gpiochip2: Persistence not supported for GPIO 50
[ 4.492734] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-5[0]' - status (0)
[ 4.501302] of_get_named_gpiod_flags: can't parse 'gpios' property of node '/regulator-7[0]'
[ 4.507547] gpiolib_shared: Adding machine lookup entry for a shared GPIO for consumer regulator-5, with key 'gpiolib_shared.proxy.9' and con_id 'none'
[ 4.516336] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/regulator-7[0]'
[ 4.525510] reg-fixed-voltage regulator-5: using lookup tables for GPIO lookup
[ 4.531592] reg-fixed-voltage regulator-7: using lookup tables for GPIO lookup
[ 4.540355] reg-fixed-voltage regulator-5: cannot find GPIO chip gpiolib_shared.proxy.9, deferring
[ 4.568523] gpiochip_find_base_unlocked: found new base at 696
[ 4.573600] reg-fixed-voltage regulator-5: No GPIO consumer (default) found
[ 4.573601] reg-fixed-voltage regulator-7: No GPIO consumer (default) found
[ 4.664886] gpiolib_shared: GPIO 4 owned by 2-0044 is shared by multiple consumers
[ 4.672471] gpiolib_shared: Setting up a shared GPIO entry for regulator-8 (con_id: '(none)')
[ 4.681268] gpiolib_shared: Created an auxiliary GPIO proxy gpiolib_shared.proxy.12 for GPIO device 2-0044
[ 4.690927] gpiolib_shared: Setting up a shared GPIO entry for regulator-9 (con_id: '(none)')
[ 4.699598] gpiolib_shared: Created an auxiliary GPIO proxy gpiolib_shared.proxy.13 for GPIO device 2-0044
[ 4.709601] gpio gpiochip3: (2-0044): added GPIO chardev (254:3)
[ 4.715933] gpio gpiochip3: registered GPIOs 696 to 701 on 2-0044
[ 4.740727] input: tps6594-pwrbutton as /devices/platform/bus@f0000/20000000.i2c/i2c-2/2-0044/tps6594-pwrbutton.4.auto/input/input0
[ 4.755360] reset_gpio reset.gpio.0: using swnode 'node0' for 'reset' GPIO lookup
[ 4.762877] gpiolib: swnode: swnode_find_gpio: parsed 'reset-gpios' property of node 'node0[0]' - status (0)
[ 4.772716] gpio gpiochip1: Persistence not supported for GPIO 10
[ 4.794592] i2c i2c-3: Added multiplexed i2c bus 5
[ 4.799831] i2c i2c-3: Added multiplexed i2c bus 6
[ 4.805044] i2c i2c-3: Added multiplexed i2c bus 7
[ 4.810252] i2c i2c-3: Added multiplexed i2c bus 8
[ 4.815065] pca954x 3-0070: registered 4 multiplexed busses for I2C switch pca9546
[ 4.824283] i2c i2c-9: using DT '/bus@f0000/i2c@fe80000' for 'scl' GPIO lookup
[ 4.831611] of_get_named_gpiod_flags: can't parse 'scl-gpios' property of node '/bus@f0000/i2c@fe80000[0]'
[ 4.841296] of_get_named_gpiod_flags: can't parse 'scl-gpio' property of node '/bus@f0000/i2c@fe80000[0]'
[ 4.850862] i2c i2c-9: using lookup tables for GPIO lookup
[ 4.856343] i2c i2c-9: No GPIO consumer scl found
[ 4.861058] i2c i2c-9: using DT '/bus@f0000/i2c@fe80000' for 'sda' GPIO lookup
[ 4.868309] of_get_named_gpiod_flags: can't parse 'sda-gpios' property of node '/bus@f0000/i2c@fe80000[0]'
[ 4.877985] of_get_named_gpiod_flags: can't parse 'sda-gpio' property of node '/bus@f0000/i2c@fe80000[0]'
[ 4.887547] i2c i2c-9: using lookup tables for GPIO lookup
[ 4.893027] i2c i2c-9: No GPIO consumer sda found
[ 4.897760] omap_i2c fe80000.i2c: bus 9 rev0.12 at 100 kHz
[ 4.909299] j721e-pcie f102000.pcie: host bridge /bus@f0000/pcie@f102000 ranges:
[ 4.916763] j721e-pcie f102000.pcie: IO 0x0600001000..0x0600100fff -> 0x0000001000
[ 4.924880] j721e-pcie f102000.pcie: MEM 0x0600101000..0x06ffffffff -> 0x0000101000
[ 4.932986] j721e-pcie f102000.pcie: IB MEM 0x0000000000..0xffffffffffff -> 0x0000000000
[ 4.942029] j721e-pcie f102000.pcie: using DT '/bus@f0000/pcie@f102000' for 'reset' GPIO lookup
[ 4.950796] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/bus@f0000/pcie@f102000[0]' - status (0)
[ 4.961424] gpio gpiochip2: Persistence not supported for GPIO 15
[ 6.074781] j721e-pcie f102000.pcie: PCI host bridge to bus 0000:00
[ 6.081127] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 6.086620] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus address [0x1000-0x100fff])
[ 6.095663] pci_bus 0000:00: root bus resource [mem 0x600101000-0x6ffffffff] (bus address [0x00101000-0xffffffff])
[ 6.106051] pci 0000:00:00.0: [104c:b010] type 01 class 0x060400 PCIe Root Port
[ 6.113368] pci 0000:00:00.0: PCI bridge to [bus 00]
[ 6.118330] pci 0000:00:00.0: bridge window [io 0x0000-0x0fff]
[ 6.124418] pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff]
[ 6.131202] pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 6.138996] pci 0000:00:00.0: supports D1
[ 6.143004] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[ 6.151499] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 6.159819] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 6.166465] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 6.171432] pci_bus 0000:00: resource 4 [io 0x0000-0xfffff]
[ 6.177086] pci_bus 0000:00: resource 5 [mem 0x600101000-0x6ffffffff]
[ 6.183778] irq: no irq domain found for interrupt-controller !
[ 6.190653] pcieport 0000:00:00.0: PME: Signaling with IRQ 517
[ 6.197077] pcieport 0000:00:00.0: AER: enabled with IRQ 517
[ 6.204192] display-connector connector-2: using DT '/connector-2' for 'hpd' GPIO lookup
[ 6.212423] display-connector connector-2: No GPIO consumer hpd found
[ 6.224711] spi-nor spi0.0: using DT '/bus@f0000/bus@fc00000/spi@fc40000/flash@0' for 'reset' GPIO lookup
[ 6.234423] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/bus@f0000/bus@fc00000/spi@fc40000/flash@0[0]'
[ 6.246015] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/bus@f0000/bus@fc00000/spi@fc40000/flash@0[0]'
[ 6.257495] spi-nor spi0.0: using lookup tables for GPIO lookup
[ 6.263413] spi-nor spi0.0: No GPIO consumer reset found
[ 6.273675] 1 fixed-partitions partitions found on MTD device fc40000.spi.0
[ 6.280682] Creating 1 MTD partitions on "fc40000.spi.0":
[ 6.286096] 0x000000000000-0x000000400000 : "failsafe bootloader"
[ 6.296512] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01903, cpsw version 0x6BA81903 Ports: 3 quirks:00000002
[ 6.312449] mdio_bus 8000f00.mdio: using DT '/bus@f0000/ethernet@8000000/mdio@f00' for 'reset' GPIO lookup
[ 6.322176] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/bus@f0000/ethernet@8000000/mdio@f00[0]'
[ 6.333238] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/bus@f0000/ethernet@8000000/mdio@f00[0]'
[ 6.344185] mdio_bus 8000f00.mdio: using lookup tables for GPIO lookup
[ 6.350705] mdio_bus 8000f00.mdio: No GPIO consumer reset found
[ 6.389788] davinci_mdio 8000f00.mdio: davinci mdio revision 17.7, bus freq 1000000
[ 6.398297] mdio_bus 8000f00.mdio:00: using DT '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@0' for 'reset' GPIO lookup
[ 6.409562] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@0[0]'
[ 6.421922] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@0[0]'
[ 6.434169] mdio_bus 8000f00.mdio:00: using lookup tables for GPIO lookup
[ 6.440950] mdio_bus 8000f00.mdio:00: No GPIO consumer reset found
[ 6.448190] Broadcom BCM54210E 8000f00.mdio:00: using DT '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@0' for 'wakeup' GPIO lookup
[ 6.460417] of_get_named_gpiod_flags: can't parse 'wakeup-gpios' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@0[0]'
[ 6.472869] of_get_named_gpiod_flags: can't parse 'wakeup-gpio' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@0[0]'
[ 6.485210] Broadcom BCM54210E 8000f00.mdio:00: using lookup tables for GPIO lookup
[ 6.492856] Broadcom BCM54210E 8000f00.mdio:00: No GPIO consumer wakeup found
[ 6.503636] mdio_bus 8000f00.mdio:01: using DT '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@1' for 'reset' GPIO lookup
[ 6.514903] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@1[0]'
[ 6.527265] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@1[0]'
[ 6.539511] mdio_bus 8000f00.mdio:01: using lookup tables for GPIO lookup
[ 6.546291] mdio_bus 8000f00.mdio:01: No GPIO consumer reset found
[ 6.553426] Broadcom BCM54210E 8000f00.mdio:01: using DT '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@1' for 'wakeup' GPIO lookup
[ 6.565653] of_get_named_gpiod_flags: can't parse 'wakeup-gpios' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@1[0]'
[ 6.578107] of_get_named_gpiod_flags: can't parse 'wakeup-gpio' property of node '/bus@f0000/ethernet@8000000/mdio@f00/ethernet-phy@1[0]'
[ 6.590443] Broadcom BCM54210E 8000f00.mdio:01: using lookup tables for GPIO lookup
[ 6.598090] Broadcom BCM54210E 8000f00.mdio:01: No GPIO consumer wakeup found
[ 6.607977] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Broadcom BCM54210E
[ 6.616762] davinci_mdio 8000f00.mdio: phy[1]: device 8000f00.mdio:01, driver Broadcom BCM54210E
[ 6.625920] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5
[ 6.633051] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32
[ 6.641451] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010d, freq:500000000, add_val:1 pps:0
[ 6.663945] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
[ 6.679378] usb-conn-gpio connector-1: using DT '/connector-1' for 'id' GPIO lookup
[ 6.687125] of_get_named_gpiod_flags: parsed 'id-gpios' property of node '/connector-1[0]' - status (0)
[ 6.696538] gpio gpiochip1: Persistence not supported for GPIO 34
[ 6.702638] usb-conn-gpio connector-1: using DT '/connector-1' for 'vbus' GPIO lookup
[ 6.710493] of_get_named_gpiod_flags: can't parse 'vbus-gpios' property of node '/connector-1[0]'
[ 6.719385] of_get_named_gpiod_flags: can't parse 'vbus-gpio' property of node '/connector-1[0]'
[ 6.728168] usb-conn-gpio connector-1: using lookup tables for GPIO lookup
[ 6.735042] usb-conn-gpio connector-1: No GPIO consumer vbus found
[ 6.748242] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[ 6.753819] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 1
[ 6.763957] xhci-hcd xhci-hcd.5.auto: hcc params 0x200073c9 hci version 0x100 quirks 0x0000002000008010
[ 6.773440] xhci-hcd xhci-hcd.5.auto: irq 519, io mem 0x31210000
[ 6.779812] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[ 6.785318] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 2
[ 6.793000] xhci-hcd xhci-hcd.5.auto: Host supports USB 3.0 SuperSpeed
[ 6.801056] hub 1-0:1.0: USB hub found
[ 6.804903] hub 1-0:1.0: 1 port detected
[ 6.809613] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 6.818937] hub 2-0:1.0: USB hub found
[ 6.822763] hub 2-0:1.0: 1 port detected
[ 6.828806] gpiolib_shared: Device gpiolib_shared.proxy.9 acquired a reference to the shared GPIO 7 owned by 600000.gpio
[ 6.839806] gpiochip_find_base_unlocked: found new base at 702
[ 6.846199] gpio_stub_drv gpiochip4: (gpiolib_shared.proxy.9): added GPIO chardev (254:4)
[ 6.854699] gpio_stub_drv gpiochip4: registered GPIOs 702 to 702 on gpiolib_shared.proxy.9
[ 6.863086] gpiolib_shared: Device gpiolib_shared.proxy.10 acquired a reference to the shared GPIO 7 owned by 600000.gpio
[ 6.874130] gpiochip_find_base_unlocked: found new base at 703
[ 6.880340] gpio_stub_drv gpiochip5: (gpiolib_shared.proxy.10): added GPIO chardev (254:5)
[ 6.888902] gpio_stub_drv gpiochip5: registered GPIOs 703 to 703 on gpiolib_shared.proxy.10
[ 6.898723] reg-fixed-voltage regulator-4: using DT '/regulator-4' for '(default)' GPIO lookup
[ 6.899660] reg-fixed-voltage regulator-8: using DT '/regulator-8' for '(default)' GPIO lookup
[ 6.900542] reg-fixed-voltage regulator-9: using DT '/regulator-9' for '(default)' GPIO lookup
[ 6.900615] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-9[0]' - status (0)
[ 6.900643] gpiolib_shared: Adding machine lookup entry for a shared GPIO for consumer regulator-9, with key 'gpiolib_shared.proxy.13' and con_id 'none'
[ 6.900650] reg-fixed-voltage regulator-9: using lookup tables for GPIO lookup
[ 6.900662] reg-fixed-voltage regulator-9: cannot find GPIO chip gpiolib_shared.proxy.13, deferring
[ 6.900667] reg-fixed-voltage regulator-9: No GPIO consumer (default) found
[ 6.907439] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-4[0]' - status (0)
[ 6.914348] at24 0-0050: using DT '/bus@f0000/bus@4000000/i2c@4900000/eeprom@50' for 'wp' GPIO lookup
[ 6.914399] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/bus@f0000/bus@4000000/i2c@4900000/eeprom@50[0]'
[ 6.914438] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/bus@f0000/bus@4000000/i2c@4900000/eeprom@50[0]'
[ 6.914452] at24 0-0050: using lookup tables for GPIO lookup
[ 6.914457] at24 0-0050: No GPIO consumer wp found
[ 6.914694] at24 0-0050: 4096 byte 24c32 EEPROM, writable, 32 bytes/write
[ 6.915229] ti_sn65dsi86 2-002c: using DT '/bus@f0000/i2c@20000000/bridge@2c' for 'enable' GPIO lookup
[ 6.915289] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/bus@f0000/i2c@20000000/bridge@2c[0]' - status (0)
[ 6.915323] gpio gpiochip1: Persistence not supported for GPIO 37
[ 6.916030] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-8[0]' - status (0)
[ 6.922037] gpiochip_find_base_unlocked: found new base at 704
[ 6.922058] gpio gpiochip6: Detected name collision for GPIO name 'GPIO1'
[ 6.922069] gpio gpiochip6: Detected name collision for GPIO name 'GPIO2'
[ 6.922076] gpio gpiochip6: Detected name collision for GPIO name 'GPIO3'
[ 6.922083] gpio gpiochip6: Detected name collision for GPIO name 'GPIO4'
[ 6.922467] gpio gpiochip6: (2-002c): added GPIO chardev (254:6)
[ 6.922784] gpio gpiochip6: registered GPIOs 704 to 707 on 2-002c
[ 6.925117] gpio gpiochip3: Persistence not supported for GPIO 1
[ 6.926293] gpiolib_shared: Device gpiolib_shared.proxy.12 acquired a reference to the shared GPIO 4 owned by 2-0044
[ 6.926400] gpiochip_find_base_unlocked: found new base at 708
[ 6.926477] reg-fixed-voltage regulator-5: using DT '/regulator-5' for '(default)' GPIO lookup
[ 6.926536] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-5[0]' - status (0)
[ 6.926550] reg-fixed-voltage regulator-5: using lookup tables for GPIO lookup
[ 6.926564] gpio_shared_proxy gpiolib_shared.proxy.9: Shared GPIO requested, number of users: 1
[ 6.926582] gpio_shared_proxy gpiolib_shared.proxy.9: Only one user of this shared GPIO, allowing to set direction to output with value 'high'
[ 6.926636] gpio_shared_proxy gpiolib_shared.proxy.9: Voted for value 'high', effective value is 'high', number of votes for 'high': 1
[ 6.927871] gpio_stub_drv gpiochip7: (gpiolib_shared.proxy.12): added GPIO chardev (254:7)
[ 6.928177] gpio_stub_drv gpiochip7: registered GPIOs 708 to 708 on gpiolib_shared.proxy.12
[ 6.928289] gpiolib_shared: Device gpiolib_shared.proxy.13 acquired a reference to the shared GPIO 4 owned by 2-0044
[ 6.928362] gpiochip_find_base_unlocked: found new base at 709
[ 6.929154] gpio_stub_drv gpiochip8: (gpiolib_shared.proxy.13): added GPIO chardev (254:8)
[ 6.929433] gpio_stub_drv gpiochip8: registered GPIOs 709 to 709 on gpiolib_shared.proxy.13
[ 6.930252] display-connector connector-2: using DT '/connector-2' for 'hpd' GPIO lookup
[ 6.930355] of_get_named_gpiod_flags: parsed 'hpd-gpios' property of node '/connector-2[0]' - status (0)
[ 6.930380] gpio gpiochip6: Persistence not supported for GPIO 1
[ 6.933765] gpiolib_shared: Adding machine lookup entry for a shared GPIO for consumer regulator-8, with key 'gpiolib_shared.proxy.12' and con_id 'none'
[ 6.936865] reg-fixed-voltage regulator-9: using DT '/regulator-9' for '(default)' GPIO lookup
[ 6.936934] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-9[0]' - status (0)
[ 6.942048] [drm] Missing drm_bridge_add() before attach
[ 6.945238] [drm] Initialized tidss 1.0.0 for 30220000.dss on minor 1
[ 6.945918] tidss 30220000.dss: [drm] Cannot find any crtc or sizes
[ 6.949586] tidss 30220000.dss: [drm] Cannot find any crtc or sizes
[ 6.952296] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 6.954677] reg-fixed-voltage regulator-8: using lookup tables for GPIO lookup
[ 6.955122] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 6.955839] gpio-regulator regulator-6: using DT '/regulator-6' for '(default)' GPIO lookup
[ 6.955964] of_get_named_gpiod_flags: parsed 'gpios' property of node '/regulator-6[0]' - status (0)
[ 6.956003] gpio gpiochip1: Persistence not supported for GPIO 8
[ 6.956041] gpio-regulator regulator-6: using DT '/regulator-6' for 'enable' GPIO lookup
[ 6.956097] regulator-6 enforce active low on GPIO handle
[ 6.956101] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/regulator-6[0]' - status (0)
[ 6.956124] gpiolib_shared: Adding machine lookup entry for a shared GPIO for consumer regulator-6, with key 'gpiolib_shared.proxy.10' and con_id 'enable'
[ 6.956130] gpio-regulator regulator-6: using lookup tables for GPIO lookup
[ 6.956145] gpio_shared_proxy gpiolib_shared.proxy.10: Shared GPIO requested, number of users: 2
[ 6.956159] gpio_shared_proxy gpiolib_shared.proxy.10: Shared GPIO's configuration already set, accepting changes but users may conflict!!
[ 6.956164] gpio_shared_proxy gpiolib_shared.proxy.10: Shared GPIO's configuration already set, accepting changes but users may conflict!!
[ 6.956172] gpio_shared_proxy gpiolib_shared.proxy.10: Shared GPIO freed, number of users: 1
[ 6.956182] gpio-regulator regulator-6: setup of GPIO enable failed: -524
[ 6.956188] gpio-regulator regulator-6: probe with driver gpio-regulator failed with error -524
[ 6.956963] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 6.957168] clk: Disabling unused clocks
[ 6.957543] faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2
[ 6.957552] faux_driver regulatory: Falling back to sysfs fallback for: regulatory.db
[ 6.957862] reg-fixed-voltage regulator-9: using lookup tables for GPIO lookup
[ 6.957889] gpio_shared_proxy gpiolib_shared.proxy.13: Shared GPIO requested, number of users: 1
[ 6.958373] gpio_shared_proxy gpiolib_shared.proxy.13: Only one user of this shared GPIO, allowing to set direction to output with value 'high'
[ 6.959438] gpio_shared_proxy gpiolib_shared.proxy.13: Voted for value 'high', effective value is 'high', number of votes for 'high': 1
[ 6.964480] PM: genpd: Disabling unused power domains
[ 6.970699] gpio_shared_proxy gpiolib_shared.proxy.12: Shared GPIO requested, number of users: 2
[ 6.980105] ALSA device list:
[ 7.081795] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 7.084455] No soundcards found.
[ 7.327694] hub 1-1:1.0: USB hub found
[ 7.335021] gpio_shared_proxy gpiolib_shared.proxy.12: Shared GPIO's configuration already set, accepting changes but users may conflict!!
[ 7.340302] hub 1-1:1.0: 5 ports detected
[ 7.348542] gpio_shared_proxy gpiolib_shared.proxy.12: Shared GPIO's configuration already set, accepting changes but users may conflict!!
[ 7.401868] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 7.408066] gpio_shared_proxy gpiolib_shared.proxy.12: Voted for value 'high', effective value is 'high', number of votes for 'high': 2
[ 7.522493] hub 2-1:1.0: USB hub found
[ 7.534907] gpio_shared_proxy gpiolib_shared.proxy.12: Voted for value 'high', effective value is 'high', number of votes for 'high': 2
[ 7.548157] hub 2-1:1.0: 4 ports detected
[ 7.632519] check access for rdinit=/init failed: -2, ignoring
[ 7.655629] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 7.662988] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 7.681850] usb 1-1.2: new low-speed USB device number 3 using xhci-hcd
[ 7.784486] input: USB Optical Mouse as /devices/platform/bus@f0000/f920000.usb/31200000.usb/xhci-hcd.5.auto/usb1/1-1/1-1.2/1-1.2:1.0/0003:0461:4D15.0001/input/input1
[ 7.799726] hid-generic 0003:0461:4D15.0001: input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-xhci-hcd.5.auto-1.2/input0
[ 7.879645] EXT4-fs (mmcblk0p2): orphan cleanup on readonly fs
[ 7.885583] EXT4-fs (mmcblk0p2): recovery complete
[ 7.893223] EXT4-fs (mmcblk0p2): mounted filesystem 774529dc-27b5-495c-92be-d44ee2dbd68d ro with ordered data mode. Quota mode: none.
[ 7.905355] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 7.913045] devtmpfs: mounted
[ 7.935418] Freeing unused kernel memory: 3200K
[ 7.940162] Run /sbin/init as init process
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2026-01-09 14:41 ` Michael Walle
@ 2026-01-09 14:50 ` Bartosz Golaszewski
2026-01-09 15:08 ` Michael Walle
0 siblings, 1 reply; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-01-09 14:50 UTC (permalink / raw)
To: Michael Walle
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
On Fri, Jan 9, 2026 at 3:41 PM Michael Walle <mwalle@kernel.org> wrote:
>
> > I am aware of the issue where
> > false-positive shared GPIOs are detected, I posted a fix for that too.
> > Without logs, I can't really tell if that's the case for you though.
> > :(
>
> What I mean is, GPIO_SHARED is automatically selected by ARCH_QCOM (and
> probably others in the future). But GPIO_SHARED_PROXY is
> selectable by the user and it can be deselected. But you cannot
> specifically deactivate GPIO_SHARED. So there is no way to go back
> to the former hacky shared gpio handling; which might be intended :)
>
> If so, shouldn't be GPIO_SHARED_PROXY be either y or m if GPIO_SHARED=y ?
> I.e. don't allow it to be deselected.
>
Fair point. I'll send a patch.
> >>
> >> This broke my board (using the arm64 defconfig, works without
> >> GPIO_SHARED of course). I'm seeing two issues here with my board
> >> (arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67*):
> >>
> >> (1) It's GPIO controller (gpio-davinci) doesn't support
> >> .get_direction so I'm getting ENOTSUPP during probing of the
> >> (some?) shared GPIOs.
> >>
> >
> > Unless this board really shares GPIOs, it may be due to the
> > false-positives that will be fixed by this patch[1]. If you enable
>
> Yeah this board shares an enable GPIO for two regulators
> (regulator-5 and regulator-6,
> arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts).
>
> > CONFIG_DEBUG_GPIO and post the kernel log, I'll be able to tell for
> > sure.
>
> See end of this mail. I've applied the mentioned patch.
>
Yes, I see there are indeed shared pins.
> > Though thanks for bringing this to my attention as I now see there is
> > indeed an issue when the proxied chip doesn't support .get_direction()
> > as well as a duplicated check in GPIO core. I'll fix it too.
> >
> >> (2) GPIO_SHARED_PROXY is default m in the defconfig, but I need the
> >> pins for the root filesystem medium, i.e. the SD card regulators.
> >>
> >
> > I'll take care of this is you confirm, the issue persists even with patch[1].
>
> Not sure this is still valid. Because I've just learned that
> apparently, the arm64 Image shall be made smaller and thus "need
> a driver for rootfs" isn't a valid reason for =y anymore.
>
Is a switch to disable shared GPIO management entirely via Kconfig
(depending on CONFIG_EXPERT) good enough for you?
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs
2026-01-09 14:50 ` Bartosz Golaszewski
@ 2026-01-09 15:08 ` Michael Walle
0 siblings, 0 replies; 71+ messages in thread
From: Michael Walle @ 2026-01-09 15:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
>> Not sure this is still valid. Because I've just learned that
>> apparently, the arm64 Image shall be made smaller and thus "need
>> a driver for rootfs" isn't a valid reason for =y anymore.
>>
>
> Is a switch to disable shared GPIO management entirely via Kconfig
> (depending on CONFIG_EXPERT) good enough for you?
I don't really need that (as I'd also need a PMIC driver, which
probably won't be accepted either as =y), maybe other do. Not sure,
up to you.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2025-11-12 13:55 ` [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support Bartosz Golaszewski
2025-11-26 15:34 ` Cosmin Tanislav
@ 2026-03-11 18:38 ` Jon Hunter
2026-03-11 20:14 ` Andy Shevchenko
1 sibling, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2026-03-11 18:38 UTC (permalink / raw)
To: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio
Cc: linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
Hi Bartosz,
On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> This module scans the device tree (for now only OF nodes are supported
> but care is taken to make other fwnode implementations easy to
> integrate) and determines which GPIO lines are shared by multiple users.
> It stores that information in memory. When the GPIO chip exposing shared
> lines is registered, the shared GPIO descriptors it exposes are marked
> as shared and virtual "proxy" devices that mediate access to the shared
> lines are created. When a consumer of a shared GPIO looks it up, its
> fwnode lookup is redirected to a just-in-time machine lookup that points
> to this proxy device.
>
> This code can be compiled out on platforms which don't use shared GPIOs.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
I have observed a crash on one of our boards with Linux v6.19 and I was
able to reproduce the same crash on a recent -next. The crash log I see
is ...
Unable to handle kernel paging request at virtual address f0f21322a6ad56c5
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[f0f21322a6ad56c5] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in:
CPU: 9 UID: 0 PID: 95 Comm: kworker/u51:4 Not tainted 7.0.0-rc3-next-20260309-00004-g34a79c0d58ea-dirty #13 PREEMPT
Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS buildbrain-gcid-42974706 11/20/2025
Workqueue: events_unbound deferred_probe_work_func
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __srcu_read_lock+0x18/0x84
lr : gpiod_request_commit+0x30/0x174
sp : ffff8000843fb8d0
x29: ffff8000843fb8d0 x28: ffff800081e12000 x27: 0000000000000200
x26: 00000000000000b9 x25: ffff000080ad92d8 x24: ffff000085cdd940
x23: ffff800081e12cc0 x22: f0f21322a6ad56c5 x21: ffff800082df0528
x20: f0f21322a6ad5295 x19: f0f21322a6ad56c5 x18: 00000000ffffffff
x17: ffff000080c04d80 x16: 1fffe000101809a1 x15: ffff8000843fb530
x14: ffff000080b17192 x13: ffff000080b1718e x12: ffff0007a1e468b8
x11: ffff80008199ccf0 x10: 0000000000000000 x9 : 0000000000000000
x8 : 1fffe0001014ec41 x7 : 0000000000000fff x6 : 0000000000000fff
x5 : ffff800082df0538 x4 : ffff000081011410 x3 : ffff0000825b82b0
x2 : ffff0000816daf40 x1 : ffff800081e12cc0 x0 : f0f21322a6ad56c5
Call trace:
__srcu_read_lock+0x18/0x84 (P)
gpiod_request_commit+0x30/0x174
gpio_device_setup_shared+0x144/0x254
gpiochip_add_data_with_key+0xc38/0xeec
devm_gpiochip_add_data_with_key+0x30/0x7c
tegra186_gpio_probe+0x5cc/0x844
platform_probe+0x5c/0x98
really_probe+0xbc/0x2a8
__driver_probe_device+0x78/0x12c
driver_probe_device+0x3c/0x15c
__device_attach_driver+0xb8/0x134
bus_for_each_drv+0x84/0xe0
__device_attach+0x9c/0x188
device_initial_probe+0x50/0x54
bus_probe_device+0x38/0xa4
deferred_probe_work_func+0x88/0xc0
process_one_work+0x154/0x294
worker_thread+0x184/0x304
kthread+0x118/0x124
ret_from_fork+0x10/0x20
Code: d5384102 910003fd a90153f3 aa0003f3 (f9400014)
---[ end trace 0000000000000000 ]---
On Tegra234, the main gpio controller has a total of 164 GPIOs (see
the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
are assigned a index by the kernel from 0-163, but these GPIOs are
not contiguous with respect to the device-tree specifier.
For example, in device-tree, if I have a shared-gpio with the
following specifier ...
gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
This is greater than 164 and this is causing the above crash because
'entry->offset' in gpio_device_setup_shared() is greater than
'gdev->ngpio' and this causes us to access invalid memory.
This is what I have been able to determine so far and wanted to get
your inputs.
Thanks
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2026-03-11 18:38 ` Jon Hunter
@ 2026-03-11 20:14 ` Andy Shevchenko
2026-03-12 7:28 ` Jon Hunter
0 siblings, 1 reply; 71+ messages in thread
From: Andy Shevchenko @ 2026-03-11 20:14 UTC (permalink / raw)
To: Jon Hunter
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
...
> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
> are assigned a index by the kernel from 0-163, but these GPIOs are
> not contiguous with respect to the device-tree specifier.
If I may ask...
Why? Is it sparse because there are pads that can't be used as GPIOs?
> For example, in device-tree, if I have a shared-gpio with the
> following specifier ...
>
> gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
>
> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
To me it sounds like a bad design of the driver for this SoC/platform.
> This is greater than 164 and this is causing the above crash because
> 'entry->offset' in gpio_device_setup_shared() is greater than
> 'gdev->ngpio' and this causes us to access invalid memory.
>
> This is what I have been able to determine so far and wanted to get
> your inputs.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2026-03-11 20:14 ` Andy Shevchenko
@ 2026-03-12 7:28 ` Jon Hunter
2026-03-12 7:49 ` Chen-Yu Tsai
0 siblings, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2026-03-12 7:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Kees Cook, Mika Westerberg, Dmitry Torokhov,
Andrew Morton, Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On 11/03/2026 20:14, Andy Shevchenko wrote:
> On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
>
> ...
>
>> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
>> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
>> are assigned a index by the kernel from 0-163, but these GPIOs are
>> not contiguous with respect to the device-tree specifier.
>
> If I may ask...
>
> Why? Is it sparse because there are pads that can't be used as GPIOs?
It is purely how the different port for the GPIO controller are
configured in h/w ...
static const struct tegra_gpio_port tegra234_main_ports[] = {
TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
};
Each port can have upto 8 pins, but some don't. Note the last number in
the column indicates the number of pins for a port.
>> For example, in device-tree, if I have a shared-gpio with the
>> following specifier ...
>>
>> gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
>>
>> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
>
> To me it sounds like a bad design of the driver for this SoC/platform.
I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2026-03-12 7:28 ` Jon Hunter
@ 2026-03-12 7:49 ` Chen-Yu Tsai
2026-03-12 8:41 ` Jon Hunter
2026-03-13 14:18 ` Bartosz Golaszewski
0 siblings, 2 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2026-03-12 7:49 UTC (permalink / raw)
To: Jon Hunter, Andy Shevchenko, Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Thu, Mar 12, 2026 at 3:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 11/03/2026 20:14, Andy Shevchenko wrote:
> > On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> >
> > ...
> >
> >> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
> >> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
> >> are assigned a index by the kernel from 0-163, but these GPIOs are
> >> not contiguous with respect to the device-tree specifier.
> >
> > If I may ask...
> >
> > Why? Is it sparse because there are pads that can't be used as GPIOs?
>
> It is purely how the different port for the GPIO controller are
> configured in h/w ...
>
> static const struct tegra_gpio_port tegra234_main_ports[] = {
> TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
> TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
> TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
> TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
> TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
> TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
> TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
> TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
> TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
> TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
> TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
> TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
> TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
> TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
> TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
> TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
> TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
> TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
> TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
> TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
> TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
> TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
> TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
> TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
> TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
> };
>
> Each port can have upto 8 pins, but some don't. Note the last number in
> the column indicates the number of pins for a port.
>
> >> For example, in device-tree, if I have a shared-gpio with the
> >> following specifier ...
> >>
> >> gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
> >>
> >> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
> >
> > To me it sounds like a bad design of the driver for this SoC/platform.
>
> I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
> GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
If the hardware has uneven number of actual pins for each bank, either
you end up using the deprecated static GPIO number allocation and
have holes in the GPIO range (sunxi currently does this), or you use
dynamic allocation, which gives you no holes in the GPIO range, but
not directly calculable mapping between DT and GPIO numbers.
The driver handles the mapping by providing an .xlate callback. A
consumer shouldn't assume anything. The shared GPIO library probably
shouldn't be try parsing the property itself and use the result to
grab the GPIO descriptor, but just rely on the gpiochip's .xlate
callback in some way.
ChenYu
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2026-03-12 7:49 ` Chen-Yu Tsai
@ 2026-03-12 8:41 ` Jon Hunter
2026-03-12 9:28 ` Andy Shevchenko
2026-03-13 14:18 ` Bartosz Golaszewski
1 sibling, 1 reply; 71+ messages in thread
From: Jon Hunter @ 2026-03-12 8:41 UTC (permalink / raw)
To: wens, Andy Shevchenko, Bartosz Golaszewski
Cc: Kees Cook, Mika Westerberg, Dmitry Torokhov, Andrew Morton,
Linus Walleij, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Greg Kroah-Hartman, Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On 12/03/2026 07:49, Chen-Yu Tsai wrote:
...
>>> To me it sounds like a bad design of the driver for this SoC/platform.
>>
>> I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
>> GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
>
> If the hardware has uneven number of actual pins for each bank, either
> you end up using the deprecated static GPIO number allocation and
> have holes in the GPIO range (sunxi currently does this), or you use
> dynamic allocation, which gives you no holes in the GPIO range, but
> not directly calculable mapping between DT and GPIO numbers.
>
> The driver handles the mapping by providing an .xlate callback. A
> consumer shouldn't assume anything. The shared GPIO library probably
> shouldn't be try parsing the property itself and use the result to
> grab the GPIO descriptor, but just rely on the gpiochip's .xlate
> callback in some way.
Right. I was thinking that isn't this why we have the xlate callbacks in
the first place to handle such things and not make these assumptions?
I am curious if other platforms could have the same issue? I did not see
this immediately with v6.19 because it is only one specific platform we
have that showed this. So very much a corner case that will only be seen
if a platform uses shared GPIOs and the shared GPIO happens to be high
enough to overflow the descriptor array. Even if we don't crash, at
least for Tegra, we could be using the wrong descriptor too for shared
GPIOs.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2026-03-12 8:41 ` Jon Hunter
@ 2026-03-12 9:28 ` Andy Shevchenko
0 siblings, 0 replies; 71+ messages in thread
From: Andy Shevchenko @ 2026-03-12 9:28 UTC (permalink / raw)
To: Jon Hunter
Cc: wens, Andy Shevchenko, Bartosz Golaszewski, Kees Cook,
Mika Westerberg, Dmitry Torokhov, Andrew Morton, Linus Walleij,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Thu, Mar 12, 2026 at 08:41:03AM +0000, Jon Hunter wrote:
> On 12/03/2026 07:49, Chen-Yu Tsai wrote:
...
> > > > To me it sounds like a bad design of the driver for this SoC/platform.
> > >
> > > I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
> > > GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
You may use valid mask (which is also available via GPIO device properties) or
as said below. In any case this thread just convinces me even more that driver
has a design flaw.
> > If the hardware has uneven number of actual pins for each bank, either
> > you end up using the deprecated static GPIO number allocation and
> > have holes in the GPIO range (sunxi currently does this), or you use
> > dynamic allocation, which gives you no holes in the GPIO range, but
> > not directly calculable mapping between DT and GPIO numbers.
> >
> > The driver handles the mapping by providing an .xlate callback. A
> > consumer shouldn't assume anything. The shared GPIO library probably
> > shouldn't be try parsing the property itself and use the result to
> > grab the GPIO descriptor, but just rely on the gpiochip's .xlate
> > callback in some way.
>
> Right. I was thinking that isn't this why we have the xlate callbacks in the
> first place to handle such things and not make these assumptions?
>
> I am curious if other platforms could have the same issue? I did not see
> this immediately with v6.19 because it is only one specific platform we
> have that showed this. So very much a corner case that will only be seen if
> a platform uses shared GPIOs and the shared GPIO happens to be high enough
> to overflow the descriptor array. Even if we don't crash, at least for
> Tegra, we could be using the wrong descriptor too for shared GPIOs.
None of Intel platforms has this issue, for the rest I have no clue.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support
2026-03-12 7:49 ` Chen-Yu Tsai
2026-03-12 8:41 ` Jon Hunter
@ 2026-03-13 14:18 ` Bartosz Golaszewski
1 sibling, 0 replies; 71+ messages in thread
From: Bartosz Golaszewski @ 2026-03-13 14:18 UTC (permalink / raw)
To: wens
Cc: Jon Hunter, Andy Shevchenko, Kees Cook, Mika Westerberg,
Dmitry Torokhov, Andrew Morton, Linus Walleij,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Greg Kroah-Hartman,
Andy Shevchenko, Catalin Marinas, Will Deacon,
Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Alexey Klimov, Bjorn Andersson, Konrad Dybcio,
linux-hardening, linux-kernel, linux-gpio, linux-arm-kernel,
linux-sound, linux-arm-msm, Bartosz Golaszewski,
linux-tegra@vger.kernel.org
On Thu, Mar 12, 2026 at 8:49 AM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Thu, Mar 12, 2026 at 3:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >
> >
> > On 11/03/2026 20:14, Andy Shevchenko wrote:
> > > On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> > >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> > >
> > > ...
> > >
> > >> On Tegra234, the main gpio controller has a total of 164 GPIOs (see
> > >> the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
> > >> are assigned a index by the kernel from 0-163, but these GPIOs are
> > >> not contiguous with respect to the device-tree specifier.
> > >
> > > If I may ask...
> > >
> > > Why? Is it sparse because there are pads that can't be used as GPIOs?
> >
> > It is purely how the different port for the GPIO controller are
> > configured in h/w ...
> >
> > static const struct tegra_gpio_port tegra234_main_ports[] = {
> > TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
> > TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
> > TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
> > TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
> > TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
> > TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
> > TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
> > TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
> > TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
> > TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
> > TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
> > TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
> > TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
> > TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
> > TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
> > TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
> > TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
> > TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
> > TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
> > TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
> > TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
> > TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
> > TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
> > TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
> > TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
> > };
> >
> > Each port can have upto 8 pins, but some don't. Note the last number in
> > the column indicates the number of pins for a port.
> >
> > >> For example, in device-tree, if I have a shared-gpio with the
> > >> following specifier ...
> > >>
> > >> gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
> > >>
> > >> The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
> > >
> > > To me it sounds like a bad design of the driver for this SoC/platform.
> >
> > I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
> > GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
>
> If the hardware has uneven number of actual pins for each bank, either
> you end up using the deprecated static GPIO number allocation and
> have holes in the GPIO range (sunxi currently does this), or you use
> dynamic allocation, which gives you no holes in the GPIO range, but
> not directly calculable mapping between DT and GPIO numbers.
>
> The driver handles the mapping by providing an .xlate callback. A
> consumer shouldn't assume anything. The shared GPIO library probably
> shouldn't be try parsing the property itself and use the result to
> grab the GPIO descriptor, but just rely on the gpiochip's .xlate
> callback in some way.
>
Yes, it's a bug. I will fix it. Thanks for the report Jon.
Bart
^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2026-03-13 14:18 UTC | newest]
Thread overview: 71+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-12 13:55 [PATCH v4 00/10] gpio: improve support for shared GPIOs Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 01/10] string: provide strends() Bartosz Golaszewski
2025-11-17 20:33 ` Kees Cook
2025-11-18 9:47 ` Bartosz Golaszewski
2025-11-18 10:13 ` Andy Shevchenko
2025-11-12 13:55 ` [PATCH v4 02/10] gpiolib: define GPIOD_FLAG_SHARED Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support Bartosz Golaszewski
2025-11-26 15:34 ` Cosmin Tanislav
2025-11-26 15:47 ` Bartosz Golaszewski
2026-03-11 18:38 ` Jon Hunter
2026-03-11 20:14 ` Andy Shevchenko
2026-03-12 7:28 ` Jon Hunter
2026-03-12 7:49 ` Chen-Yu Tsai
2026-03-12 8:41 ` Jon Hunter
2026-03-12 9:28 ` Andy Shevchenko
2026-03-13 14:18 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 04/10] gpio: shared-proxy: implement the shared GPIO proxy driver Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 05/10] gpiolib: support shared GPIOs in core subsystem code Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 06/10] gpio: provide gpiod_is_shared() Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 07/10] arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM Bartosz Golaszewski
2025-11-13 8:51 ` Arnd Bergmann
2025-11-14 19:40 ` Bjorn Andersson
2025-11-18 14:06 ` Mark Brown
2025-11-18 14:13 ` Bartosz Golaszewski
2025-11-18 14:20 ` Mark Brown
2025-11-18 14:27 ` Bartosz Golaszewski
2025-11-18 19:46 ` Mark Brown
2025-11-26 14:24 ` Jon Hunter
2025-11-26 14:28 ` Bartosz Golaszewski
2025-11-26 14:51 ` Jon Hunter
2025-11-26 14:54 ` Bartosz Golaszewski
2025-11-26 14:55 ` Jon Hunter
2025-11-26 15:05 ` Bartosz Golaszewski
2025-11-26 15:29 ` Jon Hunter
2025-11-26 15:33 ` Bartosz Golaszewski
2025-11-26 15:47 ` Jon Hunter
2025-11-26 16:00 ` Bartosz Golaszewski
2026-01-07 11:06 ` Pankaj Patil
2026-01-07 12:38 ` Bartosz Golaszewski
2026-01-08 6:49 ` Pankaj Patil
2026-01-08 8:45 ` Bartosz Golaszewski
2026-01-08 9:43 ` Pankaj Patil
2026-01-08 10:52 ` Bartosz Golaszewski
2026-01-08 14:37 ` Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 08/10] ASoC: wsa881x: drop GPIOD_FLAGS_BIT_NONEXCLUSIVE flag from GPIO lookup Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 09/10] ASoC: wsa883x: " Bartosz Golaszewski
2025-11-12 13:55 ` [PATCH v4 10/10] regulator: make the subsystem aware of shared GPIOs Bartosz Golaszewski
2025-11-17 9:20 ` (subset) [PATCH v4 00/10] gpio: improve support for " Bartosz Golaszewski
2025-11-18 11:15 ` Geert Uytterhoeven
2025-11-18 11:55 ` Bartosz Golaszewski
2025-11-18 12:55 ` Geert Uytterhoeven
2025-11-18 13:21 ` Bartosz Golaszewski
2025-11-18 23:23 ` Linus Walleij
2025-11-19 8:01 ` Andy Shevchenko
2025-11-19 8:33 ` Geert Uytterhoeven
2025-11-19 14:29 ` Linus Walleij
2025-11-20 10:39 ` (subset) " Mark Brown
2025-11-20 13:36 ` Mark Brown
2025-11-21 0:27 ` Val Packett
2025-11-21 9:03 ` Bartosz Golaszewski
2025-11-21 10:20 ` Krzysztof Kozlowski
2025-11-26 16:27 ` Dmitry Baryshkov
2025-11-26 16:49 ` Bartosz Golaszewski
2026-01-07 11:47 ` Manivannan Sadhasivam
2026-01-07 12:12 ` Dmitry Baryshkov
2026-01-07 12:23 ` Manivannan Sadhasivam
2026-01-08 14:46 ` Michael Walle
2026-01-08 15:50 ` Bartosz Golaszewski
2026-01-09 14:41 ` Michael Walle
2026-01-09 14:50 ` Bartosz Golaszewski
2026-01-09 15:08 ` Michael Walle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox