All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Liam Breck <liam@networkimprov.net>
Cc: Hans de Goede <hdegoede@redhat.com>,
	Sebastian Reichel <sre@kernel.org>,
	Liam Breck <kernel@networkimprov.net>,
	linux-pm@vger.kernel.org
Subject: Re: Moving forward with the patches for using the bq24190 on x86 systems
Date: Mon, 3 Apr 2017 17:56:46 -0700	[thread overview]
Message-ID: <20170404005646.GX8575@atomide.com> (raw)
In-Reply-To: <CAKvHMgR+mvxSRYH69oAyGGL2ppZxO=s1CtUw_N2Cy-tZe-nAUg@mail.gmail.com>

Hi,

* Liam Breck <liam@networkimprov.net> [170403 14:59]:
> On Mon, Apr 3, 2017 at 12:27 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> > 1) The "power: supply: bq24190_charger: Never reset the charger chip" patch.
> >
> > Sebastian you said you would merge this after letting it sit a bit longer
> > on the list, unless any problems with it were noticed. I believe Liam
> > would prefer for this to not get merged as-is. So I see 3 options:
> >
> > a) Merge as-is (AFAIK no problems with it have been noticed)
> > b) Add a "no-reset-on-probe" boolean device property which will
> > make the driver not do a reset on probe (nor on resume)
> > c) Add a "reset-on-probe" boolean device property and make the
> > driver only do a reset on probe (and on resume) if this is set
> >
> > Sebastian, can you please pick one of these 3 options ? Then I
> > will adjust my patch as necessary and post a new version.
> 
> I've solicited Tony's input on this. He's studied the charger/driver a
> lot, and is a guru-level kernel contributor.

Hehehehe I think we're all just-trying-to-make-it-work kernel
contributors on this driver :)

My guess is that the reset is left over from missing handling of
clearing of the EN_HIZ on errors. I recall that EN_HIZ error can
happen when plugging the cable a little bit sideways to a USB hub
with loose tolerance USB connectors.

So it should be safe to limit the reset to only happen if something
like "reset-on-probe" is specified. Not sure we want to remove it
completely, maybe just add notes that reset may misbehave in
some conditions.

On the other issues I bet you guys know more than I do so no
comments from me.

Regards,

Tony

  reply	other threads:[~2017-04-04  0:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-03  7:27 Moving forward with the patches for using the bq24190 on x86 systems Hans de Goede
2017-04-03 21:56 ` Liam Breck
2017-04-04  0:56   ` Tony Lindgren [this message]
2017-04-04  9:04   ` Hans de Goede

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=20170404005646.GX8575@atomide.com \
    --to=tony@atomide.com \
    --cc=hdegoede@redhat.com \
    --cc=kernel@networkimprov.net \
    --cc=liam@networkimprov.net \
    --cc=linux-pm@vger.kernel.org \
    --cc=sre@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.