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(-)
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>
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
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/
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
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
>> 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
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
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 -- மணிவண்ணன் சதாசிவம்
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
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 -- மணிவண்ணன் சதாசிவம்
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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>
© 2016 - 2026 Red Hat, Inc.