public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Doug Anderson <dianders@chromium.org>
Cc: kvalo@qca.qualcomm.com, ath10k@lists.infradead.org,
	linux-wireless@vger.kernel.org,
	Govind Singh <govinds@codeaurora.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] ath10k: snoc: fix unabalanced regulator error handling
Date: Wed, 24 Oct 2018 15:10:29 -0700	[thread overview]
Message-ID: <20181024221028.GA44244@rodete-desktop-imager.corp.google.com> (raw)
In-Reply-To: <CAD=FV=U0uK25mL9_d1nVB7uBV+vR9YTqGm1iTQgzdNuZO5O5_A@mail.gmail.com>

Hi,

On Thu, Oct 18, 2018 at 10:54:39AM -0700, Doug Anderson wrote:
> On Fri, Oct 12, 2018 at 5:55 PM Brian Norris <briannorris@chromium.org> wrote:
> > +       if (vreg_info->settle_delay)
> > +               udelay(vreg_info->settle_delay);
> 
> Not new to your patch, but this seems like a duplication of what the
> regulator framework is doing for you.  There are plenty of regulator
> properties describing lots of different types delays and that would be
> the place to put it.  Doing so makes it automatically easy for boards
> to specify a different delay if they have different ramp
> characteristics (like someone put a bigger capacitor on the line or
> somesuch).
> 
> At the moment it would be easy for someone to submit a patch to kill
> the settle delay in this driver this since the entire vreg_cfg table
> has 0 for the settle delay.

Thanks! I'll probably take a stab at killing the excessive
specifications in these tables, in a later patch. Would be nice to get
the bugfixes landed first though.

> > +static int __ath10k_snoc_vreg_off(struct ath10k *ar,
> > +                                 struct ath10k_vreg_info *vreg_info)
> > +{
> > +       int ret;
> > +
> > +       ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc regulator %s being disabled\n",
> > +                  vreg_info->name);
> > +
> > +       ret = regulator_disable(vreg_info->reg);
> > +       if (ret)
> > +               ath10k_err(ar, "failed to disable regulator %s\n",
> > +                          vreg_info->name);
> > +
> > +       ret = regulator_set_load(vreg_info->reg, 0);
> > +       if (ret < 0)
> > +               ath10k_err(ar, "failed to set load %s\n", vreg_info->name);
> > +
> > +       ret = regulator_set_voltage(vreg_info->reg, 0, vreg_info->max_v);
> > +       if (ret)
> > +               ath10k_err(ar, "failed to set voltage %s\n", vreg_info->name);
> 
> Not new to your patch, but ick, forcing someone to manually set the
> load / voltage of a regulator that they've turned off is silly.  It's
> only list to try to send a patch to remedy this situation.  Let me try

I'm guessing you meant:

s/only/on my/

> to put that higher on my plate.
> 
> 
> ...just like with the clock patch I suspect that some of this is
> duplicating the "regulator_bulk" APIs.  ...though I guess maybe we
> can't use those too easily until we can avoid setting voltage and
> current so much...  In any case, your patch overall looks good and an
> improvement.

I'll admit I've never used the bulk APIs. But I might give them a try as
a follow-up cleanup. (As before: would be nice to have the simpler
bugfix first.)

> Reviewed-by: Douglas Anderson <dianders@chromium.org>

Thanks,
Brian

  reply	other threads:[~2018-10-24 22:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-13  0:55 [PATCH 1/4] ath10k: snoc: remove 'wcn3990' from generic resource handling Brian Norris
2018-10-13  0:55 ` [PATCH 2/4] ath10k: snoc: fix unabalanced regulator error handling Brian Norris
2018-10-18 17:54   ` Doug Anderson
2018-10-24 22:10     ` Brian Norris [this message]
2018-10-13  0:55 ` [PATCH 3/4] ath10k: snoc: relax voltage requirements Brian Norris
2018-10-18 17:56   ` Doug Anderson
2018-10-18 18:14     ` Brian Norris
2018-10-13  0:55 ` [PATCH 4/4] ath10k: snoc: fix unbalanced clock error handling Brian Norris
2018-10-16 23:53   ` Doug Anderson
2018-11-06 16:14     ` Kalle Valo
2018-10-16 23:43 ` [PATCH 1/4] ath10k: snoc: remove 'wcn3990' from generic resource handling Doug Anderson
2018-10-16 23:47   ` Brian Norris
2018-11-05 13:04 ` Kalle Valo
     [not found] ` <20181105130403.93B6560600@smtp.codeaurora.org>
2018-11-05 21:17   ` Brian Norris
2018-11-06 16:18 ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181024221028.GA44244@rodete-desktop-imager.corp.google.com \
    --to=briannorris@chromium.org \
    --cc=ath10k@lists.infradead.org \
    --cc=dianders@chromium.org \
    --cc=govinds@codeaurora.org \
    --cc=kvalo@qca.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox