[RFC,8/9] PCI/pwrseq: add a pwrseq driver for QCA6390
Commit Message
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
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
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?
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?
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?
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
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
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
"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.
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
@@ -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
@@ -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
new file mode 100644
@@ -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");