| Message ID | 20240104130123.37115-9-brgl@bgdev.pl (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
| Series | PCI: introduce the concept of power sequencing of PCIe devices | expand |
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
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");