diff mbox series

[RFC,8/9] PCI/pwrseq: add a pwrseq driver for QCA6390

Message ID 20240104130123.37115-9-brgl@bgdev.pl
State New
Headers show
Series PCI: introduce the concept of power sequencing of PCIe devices | expand

Commit Message

Bartosz Golaszewski Jan. 4, 2024, 1:01 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a PCIe power sequencing driver that's capable of correctly powering
up the ath11k module on QCA6390 using the PCIe pwrseq functionality.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/pcie/pwrseq/Kconfig               |  11 +
 drivers/pci/pcie/pwrseq/Makefile              |   1 +
 drivers/pci/pcie/pwrseq/pcie-pwrseq-qca6390.c | 197 ++++++++++++++++++
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/pci/pcie/pwrseq/pcie-pwrseq-qca6390.c

Comments

Jeff Johnson Jan. 6, 2024, 1:31 a.m. UTC | #1
On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
> index 010e31f432c9..f9fe555b8506 100644
> --- a/drivers/pci/pcie/pwrseq/Kconfig
> +++ b/drivers/pci/pcie/pwrseq/Kconfig
> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
>  	help
>  	  Say yes here to enable support for PCIe power sequencing
>  	  drivers.
> +
> +if PCIE_PWRSEQ
> +
> +config PCIE_PWRSEQ_QCA6390
> +	tristate "PCIe Power Sequencing driver for QCA6390"
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	help
> +	  Enable support for the PCIe power sequencing driver for the
> +	  ath11k module of the QCA6390 WLAN/BT chip.
> +
> +endif

As I mentioned in the 5/9 patch I'm concerned that the current
definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
the fact that QCA6390 may need additional configuration since the menu
item will only show up if you have already enabled PCIE_PWRSEQ.
Yes I see that these are set in the defconfig in 9/9 but I'm concerned
about the more generic case.

I'm wondering if there should be a separate config QCA6390 within ath11k
which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390

/jeff
Kalle Valo Jan. 9, 2024, 9:18 a.m. UTC | #2
Jeff Johnson <quic_jjohnson@quicinc.com> writes:

> On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
>> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
>> index 010e31f432c9..f9fe555b8506 100644
>> --- a/drivers/pci/pcie/pwrseq/Kconfig
>> +++ b/drivers/pci/pcie/pwrseq/Kconfig
>> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
>>  	help
>>  	  Say yes here to enable support for PCIe power sequencing
>>  	  drivers.
>> +
>> +if PCIE_PWRSEQ
>> +
>> +config PCIE_PWRSEQ_QCA6390
>> +	tristate "PCIe Power Sequencing driver for QCA6390"
>> +	depends on ARCH_QCOM || COMPILE_TEST
>> +	help
>> +	  Enable support for the PCIe power sequencing driver for the
>> +	  ath11k module of the QCA6390 WLAN/BT chip.
>> +
>> +endif
>
> As I mentioned in the 5/9 patch I'm concerned that the current
> definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
> the fact that QCA6390 may need additional configuration since the menu
> item will only show up if you have already enabled PCIE_PWRSEQ.
> Yes I see that these are set in the defconfig in 9/9 but I'm concerned
> about the more generic case.
>
> I'm wondering if there should be a separate config QCA6390 within ath11k
> which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390

Or is it possible to provide an optional dependency in Kconfig (I guess
not)? Or what about mentioning about PCIE_PWRSEQ_QCA6390 in ATH11K_PCI
help text?
Chen-Yu Tsai Jan. 9, 2024, 9:34 a.m. UTC | #3
On Tue, Jan 9, 2024 at 5:18 PM Kalle Valo <kvalo@kernel.org> wrote:
>
> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>
> > On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
> >> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
> >> index 010e31f432c9..f9fe555b8506 100644
> >> --- a/drivers/pci/pcie/pwrseq/Kconfig
> >> +++ b/drivers/pci/pcie/pwrseq/Kconfig
> >> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
> >>      help
> >>        Say yes here to enable support for PCIe power sequencing
> >>        drivers.
> >> +
> >> +if PCIE_PWRSEQ
> >> +
> >> +config PCIE_PWRSEQ_QCA6390
> >> +    tristate "PCIe Power Sequencing driver for QCA6390"
> >> +    depends on ARCH_QCOM || COMPILE_TEST
> >> +    help
> >> +      Enable support for the PCIe power sequencing driver for the
> >> +      ath11k module of the QCA6390 WLAN/BT chip.
> >> +
> >> +endif
> >
> > As I mentioned in the 5/9 patch I'm concerned that the current
> > definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
> > the fact that QCA6390 may need additional configuration since the menu
> > item will only show up if you have already enabled PCIE_PWRSEQ.
> > Yes I see that these are set in the defconfig in 9/9 but I'm concerned
> > about the more generic case.
> >
> > I'm wondering if there should be a separate config QCA6390 within ath11k
> > which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390
>
> Or is it possible to provide an optional dependency in Kconfig (I guess

imply PCIE_PWRSEQ
imply PCIE_PWRSEQ_QCA6390
?

> not)? Or what about mentioning about PCIE_PWRSEQ_QCA6390 in ATH11K_PCI
> help text?
Kalle Valo Jan. 9, 2024, 10:09 a.m. UTC | #4
Chen-Yu Tsai <wenst@chromium.org> writes:

> On Tue, Jan 9, 2024 at 5:18 PM Kalle Valo <kvalo@kernel.org> wrote:
>
>>
>> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>>
>> > On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
>> >> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
>> >> index 010e31f432c9..f9fe555b8506 100644
>> >> --- a/drivers/pci/pcie/pwrseq/Kconfig
>> >> +++ b/drivers/pci/pcie/pwrseq/Kconfig
>> >> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
>> >>      help
>> >>        Say yes here to enable support for PCIe power sequencing
>> >>        drivers.
>> >> +
>> >> +if PCIE_PWRSEQ
>> >> +
>> >> +config PCIE_PWRSEQ_QCA6390
>> >> +    tristate "PCIe Power Sequencing driver for QCA6390"
>> >> +    depends on ARCH_QCOM || COMPILE_TEST
>> >> +    help
>> >> +      Enable support for the PCIe power sequencing driver for the
>> >> +      ath11k module of the QCA6390 WLAN/BT chip.
>> >> +
>> >> +endif
>> >
>> > As I mentioned in the 5/9 patch I'm concerned that the current
>> > definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
>> > the fact that QCA6390 may need additional configuration since the menu
>> > item will only show up if you have already enabled PCIE_PWRSEQ.
>> > Yes I see that these are set in the defconfig in 9/9 but I'm concerned
>> > about the more generic case.
>> >
>> > I'm wondering if there should be a separate config QCA6390 within ath11k
>> > which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390
>>
>> Or is it possible to provide an optional dependency in Kconfig (I guess
>
> imply PCIE_PWRSEQ
> imply PCIE_PWRSEQ_QCA6390
> ?

Nice, I had forgotten imply altogether. Would 'imply
PCIE_PWRSEQ_QCA6390' in ath11k Kconfig be enough to address Jeff's
concern?
Arnd Bergmann Jan. 9, 2024, 10:14 a.m. UTC | #5
On Tue, Jan 9, 2024, at 11:09, Kalle Valo wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>> On Tue, Jan 9, 2024 at 5:18 PM Kalle Valo <kvalo@kernel.org> wrote:
>>> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>>>
>>> > On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
>>> >> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
>>> >> index 010e31f432c9..f9fe555b8506 100644
>>> >> --- a/drivers/pci/pcie/pwrseq/Kconfig
>>> >> +++ b/drivers/pci/pcie/pwrseq/Kconfig
>>> >> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
>>> >>      help
>>> >>        Say yes here to enable support for PCIe power sequencing
>>> >>        drivers.
>>> >> +
>>> >> +if PCIE_PWRSEQ
>>> >> +
>>> >> +config PCIE_PWRSEQ_QCA6390
>>> >> +    tristate "PCIe Power Sequencing driver for QCA6390"
>>> >> +    depends on ARCH_QCOM || COMPILE_TEST
>>> >> +    help
>>> >> +      Enable support for the PCIe power sequencing driver for the
>>> >> +      ath11k module of the QCA6390 WLAN/BT chip.
>>> >> +
>>> >> +endif
>>> >
>>> > As I mentioned in the 5/9 patch I'm concerned that the current
>>> > definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
>>> > the fact that QCA6390 may need additional configuration since the menu
>>> > item will only show up if you have already enabled PCIE_PWRSEQ.
>>> > Yes I see that these are set in the defconfig in 9/9 but I'm concerned
>>> > about the more generic case.
>>> >
>>> > I'm wondering if there should be a separate config QCA6390 within ath11k
>>> > which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390
>>>
>>> Or is it possible to provide an optional dependency in Kconfig (I guess
>>
>> imply PCIE_PWRSEQ
>> imply PCIE_PWRSEQ_QCA6390
>> ?
>
> Nice, I had forgotten imply altogether. Would 'imply
> PCIE_PWRSEQ_QCA6390' in ath11k Kconfig be enough to address Jeff's
> concern?

Please don't use imply (ever), it doesn't normally do
what you want. In this case, the only effect the
'imply' has is to change the default of the PCIE_PWRSEQ_QCA6390
option when a defconfig contains QCA6390.

If this is indeed what you want, it's still better to do the
equivalent expression in PCIE_PWRSEQ_QCA6390 rather than ATH11K:

config PCIE_PWRSEQ_QCA6390
      tristate "PCIe Power Sequencing driver for QCA6390"
      default ATH11K && ARCH_QCOM

      Arnd
Chen-Yu Tsai Jan. 9, 2024, 10:26 a.m. UTC | #6
On Tue, Jan 9, 2024 at 6:15 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jan 9, 2024, at 11:09, Kalle Valo wrote:
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >> On Tue, Jan 9, 2024 at 5:18 PM Kalle Valo <kvalo@kernel.org> wrote:
> >>> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
> >>>
> >>> > On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
> >>> >> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
> >>> >> index 010e31f432c9..f9fe555b8506 100644
> >>> >> --- a/drivers/pci/pcie/pwrseq/Kconfig
> >>> >> +++ b/drivers/pci/pcie/pwrseq/Kconfig
> >>> >> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
> >>> >>      help
> >>> >>        Say yes here to enable support for PCIe power sequencing
> >>> >>        drivers.
> >>> >> +
> >>> >> +if PCIE_PWRSEQ
> >>> >> +
> >>> >> +config PCIE_PWRSEQ_QCA6390
> >>> >> +    tristate "PCIe Power Sequencing driver for QCA6390"
> >>> >> +    depends on ARCH_QCOM || COMPILE_TEST
> >>> >> +    help
> >>> >> +      Enable support for the PCIe power sequencing driver for the
> >>> >> +      ath11k module of the QCA6390 WLAN/BT chip.
> >>> >> +
> >>> >> +endif
> >>> >
> >>> > As I mentioned in the 5/9 patch I'm concerned that the current
> >>> > definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
> >>> > the fact that QCA6390 may need additional configuration since the menu
> >>> > item will only show up if you have already enabled PCIE_PWRSEQ.
> >>> > Yes I see that these are set in the defconfig in 9/9 but I'm concerned
> >>> > about the more generic case.
> >>> >
> >>> > I'm wondering if there should be a separate config QCA6390 within ath11k
> >>> > which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390
> >>>
> >>> Or is it possible to provide an optional dependency in Kconfig (I guess
> >>
> >> imply PCIE_PWRSEQ
> >> imply PCIE_PWRSEQ_QCA6390
> >> ?
> >
> > Nice, I had forgotten imply altogether. Would 'imply
> > PCIE_PWRSEQ_QCA6390' in ath11k Kconfig be enough to address Jeff's
> > concern?
>
> Please don't use imply (ever), it doesn't normally do
> what you want. In this case, the only effect the
> 'imply' has is to change the default of the PCIE_PWRSEQ_QCA6390
> option when a defconfig contains QCA6390.
>
> If this is indeed what you want, it's still better to do the
> equivalent expression in PCIE_PWRSEQ_QCA6390 rather than ATH11K:
>
> config PCIE_PWRSEQ_QCA6390
>       tristate "PCIe Power Sequencing driver for QCA6390"
>       default ATH11K && ARCH_QCOM

PCIE_PWRSEQ_QCA6390 is also guarded by PCIE_PWRSEQ though. That would
require the default statement to be duplicated to the PCIE_PWRSEQ option
as well.

Presumably we'd get a few more power sequencing drivers, and the list of
default statements for PCIE_PWRSEQ would grow.

If that's acceptable then Arnd's proposal plus duplicating it to
PCIE_PWRSEQ should work as described.

ChenYu
Arnd Bergmann Jan. 9, 2024, 10:38 a.m. UTC | #7
On Tue, Jan 9, 2024, at 11:26, Chen-Yu Tsai wrote:
> On Tue, Jan 9, 2024 at 6:15 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Jan 9, 2024, at 11:09, Kalle Valo wrote:
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >> On Tue, Jan 9, 2024 at 5:18 PM Kalle Valo <kvalo@kernel.org> wrote:

>> If this is indeed what you want, it's still better to do the
>> equivalent expression in PCIE_PWRSEQ_QCA6390 rather than ATH11K:
>>
>> config PCIE_PWRSEQ_QCA6390
>>       tristate "PCIe Power Sequencing driver for QCA6390"
>>       default ATH11K && ARCH_QCOM
>
> PCIE_PWRSEQ_QCA6390 is also guarded by PCIE_PWRSEQ though. That would
> require the default statement to be duplicated to the PCIE_PWRSEQ option
> as well.
>
> Presumably we'd get a few more power sequencing drivers, and the list of
> default statements for PCIE_PWRSEQ would grow.
>
> If that's acceptable then Arnd's proposal plus duplicating it to
> PCIE_PWRSEQ should work as described.

Does PCIE_PWRSEQ need to be user-visible? If this is a hidden symbol
that gets selected by PCIE_PWRSEQ_QCA6390 and any future ones, it
would still get enabled.

Another possibility would be to have PCIE_PWRSEQ be default-enabled,
but allow it to be turned off in order to hide the other options
when users are sure they don't need it (e.g. when building a
specialized kernel for a particular board).

     Arnd
Kalle Valo Jan. 9, 2024, 4:43 p.m. UTC | #8
"Arnd Bergmann" <arnd@arndb.de> writes:

> On Tue, Jan 9, 2024, at 11:09, Kalle Valo wrote:
>
>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>> On Tue, Jan 9, 2024 at 5:18 PM Kalle Valo <kvalo@kernel.org> wrote:
>>>> Jeff Johnson <quic_jjohnson@quicinc.com> writes:
>>>>
>>>> > On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
>>>> >> diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
>>>> >> index 010e31f432c9..f9fe555b8506 100644
>>>> >> --- a/drivers/pci/pcie/pwrseq/Kconfig
>>>> >> +++ b/drivers/pci/pcie/pwrseq/Kconfig
>>>> >> @@ -6,3 +6,14 @@ menuconfig PCIE_PWRSEQ
>>>> >>      help
>>>> >>        Say yes here to enable support for PCIe power sequencing
>>>> >>        drivers.
>>>> >> +
>>>> >> +if PCIE_PWRSEQ
>>>> >> +
>>>> >> +config PCIE_PWRSEQ_QCA6390
>>>> >> +    tristate "PCIe Power Sequencing driver for QCA6390"
>>>> >> +    depends on ARCH_QCOM || COMPILE_TEST
>>>> >> +    help
>>>> >> +      Enable support for the PCIe power sequencing driver for the
>>>> >> +      ath11k module of the QCA6390 WLAN/BT chip.
>>>> >> +
>>>> >> +endif
>>>> >
>>>> > As I mentioned in the 5/9 patch I'm concerned that the current
>>>> > definition of PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390 will effectively hide
>>>> > the fact that QCA6390 may need additional configuration since the menu
>>>> > item will only show up if you have already enabled PCIE_PWRSEQ.
>>>> > Yes I see that these are set in the defconfig in 9/9 but I'm concerned
>>>> > about the more generic case.
>>>> >
>>>> > I'm wondering if there should be a separate config QCA6390 within ath11k
>>>> > which would then select PCIE_PWRSEQ and PCIE_PWRSEQ_QCA6390
>>>>
>>>> Or is it possible to provide an optional dependency in Kconfig (I guess
>>>
>>> imply PCIE_PWRSEQ
>>> imply PCIE_PWRSEQ_QCA6390
>>> ?
>>
>> Nice, I had forgotten imply altogether. Would 'imply
>> PCIE_PWRSEQ_QCA6390' in ath11k Kconfig be enough to address Jeff's
>> concern?
>
> Please don't use imply (ever), it doesn't normally do
> what you want. In this case, the only effect the
> 'imply' has is to change the default of the PCIE_PWRSEQ_QCA6390
> option when a defconfig contains QCA6390.
>
> If this is indeed what you want, it's still better to do the
> equivalent expression in PCIE_PWRSEQ_QCA6390 rather than ATH11K:
>
> config PCIE_PWRSEQ_QCA6390
>       tristate "PCIe Power Sequencing driver for QCA6390"
>       default ATH11K && ARCH_QCOM

Sounds good to me but should it be 'default ATH11K_PCI && ARCH_QCOM'? My
understanding is that we don't need PWRSEQ for ATH11K_AHB devices.
Arnd Bergmann Jan. 9, 2024, 4:46 p.m. UTC | #9
On Tue, Jan 9, 2024, at 17:43, Kalle Valo wrote:
> "Arnd Bergmann" <arnd@arndb.de> writes:
>> On Tue, Jan 9, 2024, at 11:09, Kalle Valo wrote:
>>
>> If this is indeed what you want, it's still better to do the
>> equivalent expression in PCIE_PWRSEQ_QCA6390 rather than ATH11K:
>>
>> config PCIE_PWRSEQ_QCA6390
>>       tristate "PCIe Power Sequencing driver for QCA6390"
>>       default ATH11K && ARCH_QCOM
>
> Sounds good to me but should it be 'default ATH11K_PCI && ARCH_QCOM'? My
> understanding is that we don't need PWRSEQ for ATH11K_AHB devices.

Right, that is better.

    Arnd
diff mbox series

Patch

diff --git a/drivers/pci/pcie/pwrseq/Kconfig b/drivers/pci/pcie/pwrseq/Kconfig
index 010e31f432c9..f9fe555b8506 100644
--- a/drivers/pci/pcie/pwrseq/Kconfig
+++ b/drivers/pci/pcie/pwrseq/Kconfig
@@ -6,3 +6,14 @@  menuconfig PCIE_PWRSEQ
 	help
 	  Say yes here to enable support for PCIe power sequencing
 	  drivers.
+
+if PCIE_PWRSEQ
+
+config PCIE_PWRSEQ_QCA6390
+	tristate "PCIe Power Sequencing driver for QCA6390"
+	depends on ARCH_QCOM || COMPILE_TEST
+	help
+	  Enable support for the PCIe power sequencing driver for the
+	  ath11k module of the QCA6390 WLAN/BT chip.
+
+endif
diff --git a/drivers/pci/pcie/pwrseq/Makefile b/drivers/pci/pcie/pwrseq/Makefile
index da99566594f6..da3e02063404 100644
--- a/drivers/pci/pcie/pwrseq/Makefile
+++ b/drivers/pci/pcie/pwrseq/Makefile
@@ -1,3 +1,4 @@ 
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_PCIE_PWRSEQ)		+= pwrseq.o
+obj-$(CONFIG_PCIE_PWRSEQ_QCA6390)	+= pcie-pwrseq-qca6390.o
diff --git a/drivers/pci/pcie/pwrseq/pcie-pwrseq-qca6390.c b/drivers/pci/pcie/pwrseq/pcie-pwrseq-qca6390.c
new file mode 100644
index 000000000000..e9fddbb642fe
--- /dev/null
+++ b/drivers/pci/pcie/pwrseq/pcie-pwrseq-qca6390.c
@@ -0,0 +1,197 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ */
+
+#include <linux/bitmap.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pcie-pwrseq.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+struct pcie_pwrseq_qca6390_vreg {
+	const char *name;
+	unsigned int load_uA;
+};
+
+struct pcie_pwrseq_qca6390_pdata {
+	struct pcie_pwrseq_qca6390_vreg *vregs;
+	size_t num_vregs;
+	unsigned int delay_msec;
+};
+
+struct pcie_pwrseq_qca6390_ctx {
+	struct pcie_pwrseq pwrseq;
+	const struct pcie_pwrseq_qca6390_pdata *pdata;
+	struct regulator_bulk_data *regs;
+	struct gpio_descs *en_gpios;
+	unsigned long *en_gpios_values;
+};
+
+static struct pcie_pwrseq_qca6390_vreg pcie_pwrseq_qca6390_vregs[] = {
+	{
+		.name = "vddpmu",
+		.load_uA = 1250000,
+	},
+	{
+		.name = "vddpcie1",
+		.load_uA = 35000,
+	},
+	{
+		.name = "vddpcie2",
+		.load_uA = 15000,
+	},
+};
+
+static struct pcie_pwrseq_qca6390_pdata pcie_pwrseq_qca6390_of_data = {
+	.vregs = pcie_pwrseq_qca6390_vregs,
+	.num_vregs = ARRAY_SIZE(pcie_pwrseq_qca6390_vregs),
+	.delay_msec = 16,
+};
+
+static int pcie_pwrseq_qca6390_power_on(struct pcie_pwrseq_qca6390_ctx *ctx)
+{
+	int ret;
+
+	ret = regulator_bulk_enable(ctx->pdata->num_vregs, ctx->regs);
+	if (ret)
+		return ret;
+
+	bitmap_fill(ctx->en_gpios_values, ctx->en_gpios->ndescs);
+
+	ret = gpiod_set_array_value_cansleep(ctx->en_gpios->ndescs,
+					     ctx->en_gpios->desc,
+					     ctx->en_gpios->info,
+					     ctx->en_gpios_values);
+	if (ret) {
+		regulator_bulk_disable(ctx->pdata->num_vregs, ctx->regs);
+		return ret;
+	}
+
+	if (ctx->pdata->delay_msec)
+		msleep(ctx->pdata->delay_msec);
+
+	return 0;
+}
+
+static int pcie_pwrseq_qca6390_power_off(struct pcie_pwrseq_qca6390_ctx *ctx)
+{
+	int ret;
+
+	bitmap_zero(ctx->en_gpios_values, ctx->en_gpios->ndescs);
+
+	ret = gpiod_set_array_value_cansleep(ctx->en_gpios->ndescs,
+					     ctx->en_gpios->desc,
+					     ctx->en_gpios->info,
+					     ctx->en_gpios_values);
+	if (ret)
+		return ret;
+
+	return regulator_bulk_disable(ctx->pdata->num_vregs, ctx->regs);
+}
+
+static void devm_pcie_pwrseq_qca6390_power_off(void *data)
+{
+	struct pcie_pwrseq_qca6390_ctx *ctx = data;
+
+	pcie_pwrseq_qca6390_power_off(ctx);
+}
+
+static int pcie_pwrseq_qca6309_probe(struct platform_device *pdev)
+{
+	struct pcie_pwrseq_qca6390_ctx *ctx;
+	struct device *dev = &pdev->dev;
+	int ret, i;
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->pdata = of_device_get_match_data(dev);
+	if (!ctx->pdata)
+		return dev_err_probe(dev, -ENODEV,
+				     "Failed to obtain platform data\n");
+
+	if (ctx->pdata->vregs) {
+		ctx->regs = devm_kcalloc(dev, ctx->pdata->num_vregs,
+					 sizeof(*ctx->regs), GFP_KERNEL);
+		if (!ctx->regs)
+			return -ENOMEM;
+
+		for (i = 0; i < ctx->pdata->num_vregs; i++)
+			ctx->regs[i].supply = ctx->pdata->vregs[i].name;
+
+		ret = devm_regulator_bulk_get(dev, ctx->pdata->num_vregs,
+					      ctx->regs);
+		if (ret < 0)
+			return dev_err_probe(dev, ret,
+					     "Failed to get all regulators\n");
+
+		for (i = 0; i < ctx->pdata->num_vregs; i++) {
+			ret = regulator_set_load(ctx->regs[i].consumer,
+						 ctx->pdata->vregs[i].load_uA);
+			if (ret)
+				return dev_err_probe(dev, ret,
+						     "Failed to set vreg load\n");
+		}
+	}
+
+	ctx->en_gpios = devm_gpiod_get_array_optional(dev, "enable",
+						      GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->en_gpios))
+		return dev_err_probe(dev, PTR_ERR(ctx->en_gpios),
+				     "Failed to get enable GPIOs\n");
+
+	ctx->en_gpios_values = devm_bitmap_zalloc(dev, ctx->en_gpios->ndescs,
+						  GFP_KERNEL);
+	if (!ctx->en_gpios_values)
+		return -ENOMEM;
+
+	ret = pcie_pwrseq_qca6390_power_on(ctx);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to power on the device\n");
+
+	ret = devm_add_action_or_reset(dev, devm_pcie_pwrseq_qca6390_power_off,
+				       ctx);
+	if (ret)
+		return ret;
+
+	ctx->pwrseq.dev = dev;
+
+	ret = devm_pcie_pwrseq_device_enable(dev, &ctx->pwrseq);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to register the pwrseq wrapper\n");
+
+	return 0;
+}
+
+static const struct of_device_id pcie_pwrseq_qca6309_of_match[] = {
+	{
+		.compatible = "pci17cb,1101",
+		.data = &pcie_pwrseq_qca6390_of_data,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, pcie_pwrseq_qca6309_of_match);
+
+static struct platform_driver pcie_pwrseq_qca6309_driver = {
+	.driver = {
+		.name = "pcie-pwrseq-qca6390",
+		.of_match_table = pcie_pwrseq_qca6309_of_match,
+	},
+	.probe = pcie_pwrseq_qca6309_probe,
+};
+module_platform_driver(pcie_pwrseq_qca6309_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("PCIe Power Sequencing module for QCA6390");
+MODULE_LICENSE("GPL");