The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
voltages over internal rails. Implement support for using powersequencer
for this family of ATH10k devices in addition to using regulators.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
2 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index b3f6424c17d3..3600c8eb19a3 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -11,6 +11,7 @@
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/property.h>
+#include <linux/pwrseq/consumer.h>
#include <linux/regulator/consumer.h>
#include <linux/remoteproc/qcom_rproc.h>
#include <linux/of_reserved_mem.h>
@@ -1023,9 +1024,15 @@ static int ath10k_hw_power_on(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
+ if (ar_snoc->pwrseq) {
+ ret = pwrseq_power_on(ar_snoc->pwrseq);
+ if (ret)
+ return ret;
+ }
+
ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
if (ret)
- return ret;
+ goto pwrseq_off;
ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
if (ret)
@@ -1035,18 +1042,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
vreg_off:
regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
+pwrseq_off:
+ pwrseq_power_off(ar_snoc->pwrseq);
+
return ret;
}
static int ath10k_hw_power_off(struct ath10k *ar)
{
struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
+ int ret_seq = 0;
+ int ret_vreg;
ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
- return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
+ ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
+
+ if (ar_snoc->pwrseq)
+ ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
+
+ return ret_vreg ? : ret_seq;
}
static void ath10k_snoc_wlan_disable(struct ath10k *ar)
@@ -1762,7 +1779,38 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
goto err_release_resource;
}
- ar_snoc->num_vregs = ARRAY_SIZE(ath10k_regulators);
+ /*
+ * devm_pwrseq_get() can return -EPROBE_DEFER in two cases:
+ * - it is not supposed to be used
+ * - it is supposed to be used, but the driver hasn't probed yet.
+ *
+ * There is no simple way to distinguish between these two cases, but:
+ * - if it is not supposed to be used, then regulator_bulk_get() will
+ * return all regulators as expected, continuing the probe
+ * - if it is supposed to be used, but wasn't probed yet, we will get
+ * -EPROBE_DEFER from regulator_bulk_get() too.
+ *
+ * For backwards compatibility with DTs specifying regulators directly
+ * rather than using the PMU device, ignore the defer error from
+ * pwrseq.
+ */
+ ar_snoc->pwrseq = devm_pwrseq_get(&pdev->dev, "wlan");
+ if (IS_ERR(ar_snoc->pwrseq)) {
+ ret = PTR_ERR(ar_snoc->pwrseq);
+ ar_snoc->pwrseq = NULL;
+ if (ret != -EPROBE_DEFER)
+ goto err_free_irq;
+
+ ar_snoc->num_vregs = ARRAY_SIZE(ath10k_regulators);
+ } else {
+ /*
+ * The first regulator (vdd-0.8-cx-mx) is used to power on part
+ * of the SoC rather than the PMU on WCN399x, the rest are
+ * handled via pwrseq.
+ */
+ ar_snoc->num_vregs = 1;
+ }
+
ar_snoc->vregs = devm_kcalloc(&pdev->dev, ar_snoc->num_vregs,
sizeof(*ar_snoc->vregs), GFP_KERNEL);
if (!ar_snoc->vregs) {
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index d4bce1707696..eeaa1c009cb0 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -53,6 +53,7 @@ enum ath10k_snoc_flags {
};
struct clk_bulk_data;
+struct pwrseq_desc;
struct regulator_bulk_data;
struct ath10k_snoc {
@@ -73,6 +74,7 @@ struct ath10k_snoc {
struct ath10k_snoc_ce_irq ce_irqs[CE_COUNT_MAX];
struct ath10k_ce ce;
struct timer_list rx_post_retry;
+ struct pwrseq_desc *pwrseq;
struct regulator_bulk_data *vregs;
size_t num_vregs;
struct clk_bulk_data *clks;
--
2.47.3On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
> @@ -1023,9 +1024,15 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
>
> + if (ar_snoc->pwrseq) {
> + ret = pwrseq_power_on(ar_snoc->pwrseq);
> + if (ret)
> + return ret;
> + }
> +
> ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> if (ret)
> - return ret;
> + goto pwrseq_off;
>
> ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
> if (ret)
> @@ -1035,18 +1042,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> vreg_off:
> regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +pwrseq_off:
> + pwrseq_power_off(ar_snoc->pwrseq);
in this function you conditionally call pwrseq_power_on()
but on error you unconditionally call pwrseq_power_off()
in the below function you conditionally call pwrseq_power_off()
so there is inconsistency.
note that both pwrseq_power_on() and pwrseq_power_off() handle a NULL
pwrseq_desc so is there any reason to not just call both both functions
unconditionally everywhere?
> +
> return ret;
> }
>
> static int ath10k_hw_power_off(struct ath10k *ar)
> {
> struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> + int ret_seq = 0;
> + int ret_vreg;
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
>
> clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
>
> - return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> + ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +
> + if (ar_snoc->pwrseq)
> + ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
> +
> + return ret_vreg ? : ret_seq;
> }
>
> static void ath10k_snoc_wlan_disable(struct ath10k *ar)
On Thu, Jan 15, 2026 at 03:12:19PM -0800, Jeff Johnson wrote:
> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
> > @@ -1023,9 +1024,15 @@ static int ath10k_hw_power_on(struct ath10k *ar)
> >
> > ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
> >
> > + if (ar_snoc->pwrseq) {
> > + ret = pwrseq_power_on(ar_snoc->pwrseq);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> > if (ret)
> > - return ret;
> > + goto pwrseq_off;
> >
> > ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
> > if (ret)
> > @@ -1035,18 +1042,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
> >
> > vreg_off:
> > regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> > +pwrseq_off:
> > + pwrseq_power_off(ar_snoc->pwrseq);
>
> in this function you conditionally call pwrseq_power_on()
> but on error you unconditionally call pwrseq_power_off()
>
> in the below function you conditionally call pwrseq_power_off()
>
> so there is inconsistency.
>
> note that both pwrseq_power_on() and pwrseq_power_off() handle a NULL
> pwrseq_desc so is there any reason to not just call both both functions
> unconditionally everywhere?
Indeed, it should not be necessary. I'll send a new iteration (and also
update the copyright).
>
> > +
> > return ret;
> > }
> >
> > static int ath10k_hw_power_off(struct ath10k *ar)
> > {
> > struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> > + int ret_seq = 0;
> > + int ret_vreg;
> >
> > ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
> >
> > clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
> >
> > - return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> > + ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> > +
> > + if (ar_snoc->pwrseq)
> > + ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
> > +
> > + return ret_vreg ? : ret_seq;
> > }
> >
> > static void ath10k_snoc_wlan_disable(struct ath10k *ar)
--
With best wishes
Dmitry
On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote: > The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading > voltages over internal rails. Implement support for using powersequencer > for this family of ATH10k devices in addition to using regulators. > > Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > --- > drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++-- > drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ My automation flagged: * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright * 2 copyright issues I'll add these manually in my 'pending' branch /jeff
On 15/01/2026 23:30, Jeff Johnson wrote: > On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote: >> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading >> voltages over internal rails. Implement support for using powersequencer >> for this family of ATH10k devices in addition to using regulators. >> >> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> >> --- >> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++-- >> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ > > My automation flagged: > * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright > * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright > * 2 copyright issues > > I'll add these manually in my 'pending' branch > And why is this a problem? You are not here to impose Qualcomm rules, bu care about Linux kernel. You cannot add copyrights based on what exactly? Best regards, Krzysztof
On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote: > On 15/01/2026 23:30, Jeff Johnson wrote: >> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote: >>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading >>> voltages over internal rails. Implement support for using powersequencer >>> for this family of ATH10k devices in addition to using regulators. >>> >>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> >>> --- >>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++-- >>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ >> >> My automation flagged: >> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright >> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright >> * 2 copyright issues >> >> I'll add these manually in my 'pending' branch >> > > And why is this a problem? You are not here to impose Qualcomm rules, bu > care about Linux kernel. You cannot add copyrights based on what exactly? I am a maintainer that is paid by Qualcomm to perform that role, and hence I have a duty to enforce the legal guidance from Qualcomm when it comes to contributions from other Qualcomm employees. /jeff
On 16/01/2026 16:18, Jeff Johnson wrote: > On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote: >> On 15/01/2026 23:30, Jeff Johnson wrote: >>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote: >>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading >>>> voltages over internal rails. Implement support for using powersequencer >>>> for this family of ATH10k devices in addition to using regulators. >>>> >>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> >>>> --- >>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++-- >>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ >>> >>> My automation flagged: >>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright >>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright >>> * 2 copyright issues >>> >>> I'll add these manually in my 'pending' branch >>> >> >> And why is this a problem? You are not here to impose Qualcomm rules, bu >> care about Linux kernel. You cannot add copyrights based on what exactly? > > I am a maintainer that is paid by Qualcomm to perform that role, and hence I > have a duty to enforce the legal guidance from Qualcomm when it comes to > contributions from other Qualcomm employees. No, it's not your duty to enforce rules from some other departments or business units. Especially not without agreement of that person. You cannot just add copyrights to other people's commits just because you think that such copyrights should be there. Only the copyright owner - which you did not identify here and email address of contributor does not imply that (you don't even know what work contract a person has) - can add such copyrights. Best regards, Krzysztof
On Fri, Jan 16, 2026 at 05:08:58PM +0100, Krzysztof Kozlowski wrote: > On 16/01/2026 16:18, Jeff Johnson wrote: > > On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote: > >> On 15/01/2026 23:30, Jeff Johnson wrote: > >>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote: > >>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading > >>>> voltages over internal rails. Implement support for using powersequencer > >>>> for this family of ATH10k devices in addition to using regulators. > >>>> > >>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> > >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > >>>> --- > >>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++-- > >>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ > >>> > >>> My automation flagged: > >>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright > >>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright > >>> * 2 copyright issues > >>> > >>> I'll add these manually in my 'pending' branch > >>> > >> > >> And why is this a problem? You are not here to impose Qualcomm rules, bu > >> care about Linux kernel. You cannot add copyrights based on what exactly? > > > > I am a maintainer that is paid by Qualcomm to perform that role, and hence I > > have a duty to enforce the legal guidance from Qualcomm when it comes to > > contributions from other Qualcomm employees. > > No, it's not your duty to enforce rules from some other departments or > business units. Especially not without agreement of that person. You > cannot just add copyrights to other people's commits just because you > think that such copyrights should be there. Only the copyright owner - > which you did not identify here and email address of contributor does > not imply that (you don't even know what work contract a person has) - > can add such copyrights. In this particular usecase Jeff has enough knowledge about me and my working place. I will have to resend the series anyway, but otherwise it was perfectly fine for him to correct the copyright. -- With best wishes Dmitry
On 16/01/2026 17:41, Dmitry Baryshkov wrote: > On Fri, Jan 16, 2026 at 05:08:58PM +0100, Krzysztof Kozlowski wrote: >> On 16/01/2026 16:18, Jeff Johnson wrote: >>> On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote: >>>> On 15/01/2026 23:30, Jeff Johnson wrote: >>>>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote: >>>>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading >>>>>> voltages over internal rails. Implement support for using powersequencer >>>>>> for this family of ATH10k devices in addition to using regulators. >>>>>> >>>>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> >>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> >>>>>> --- >>>>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++-- >>>>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++ >>>>> >>>>> My automation flagged: >>>>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright >>>>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright >>>>> * 2 copyright issues >>>>> >>>>> I'll add these manually in my 'pending' branch >>>>> >>>> >>>> And why is this a problem? You are not here to impose Qualcomm rules, bu >>>> care about Linux kernel. You cannot add copyrights based on what exactly? >>> >>> I am a maintainer that is paid by Qualcomm to perform that role, and hence I >>> have a duty to enforce the legal guidance from Qualcomm when it comes to >>> contributions from other Qualcomm employees. >> >> No, it's not your duty to enforce rules from some other departments or >> business units. Especially not without agreement of that person. You >> cannot just add copyrights to other people's commits just because you >> think that such copyrights should be there. Only the copyright owner - >> which you did not identify here and email address of contributor does >> not imply that (you don't even know what work contract a person has) - >> can add such copyrights. > > In this particular usecase Jeff has enough knowledge about me and my > working place. I will have to resend the series anyway, but otherwise it > was perfectly fine for him to correct the copyright. Fine, but please do not add copyrights yourself to any of my code. It's fine to point is a reviewing comment and expect clarifications on my side, I don't find changing people's code and adding there copyrights as right way. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.