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, 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
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
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 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
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>
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
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
© 2016 - 2025 Red Hat, Inc.