All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Reichel <sre@kernel.org>
To: Frans Klaver <frans.klaver@xsens.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] sbs-battery: add option to always register battery
Date: Wed, 10 Jun 2015 16:52:05 +0200	[thread overview]
Message-ID: <20150610145205.GE11618@earth> (raw)
In-Reply-To: <1433938616-18503-1-git-send-email-frans.klaver@xsens.com>

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Hi Frans,

On Wed, Jun 10, 2015 at 02:16:56PM +0200, Frans Klaver wrote:
> Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
> device") introduced a step in probing the SBS battery, that tries to
> talk to the device before actually registering it, saying:
> 
>     this driver doesn't actually try talking to the device at probe
>     time, so if it's incorrectly configured in the device tree or
>     platform data (or if the battery has been removed from the system),
>     then probe will succeed and every access will sit there and time
>     out. The end result is a possibly laggy system that thinks it has a
>     battery but can never read status, which isn't very useful.
> 
> Which is of course reasonable. However, it is also very well possible
> for a device to boot up on wall-power and be connected to a battery
> later on. This is a scenario that the driver supported before said patch
> was applied, and even easily achieved by booting up with the battery
> attached and removing it later on. sbs-battery's 'present' sysfs file
> can be used to determine if the device is available or not.
> 
> So with automated device detection lacking for now, in some cases it is
> possible that one wants to register a battery, even if none are attached
> at the moment. To facilitate this, add a module parameter that can be
> used to configure forced loading module loading time. If set, the battery
> will always be registered without checking the sanity of the connection.

Thanks, queued.

Please make sure to send patches based upon the correct branches
though. Your branch did not yet contain 297d716.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-06-10 14:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 12:16 [PATCH v3] sbs-battery: add option to always register battery Frans Klaver
2015-06-10 12:16 ` Frans Klaver
2015-06-10 14:52 ` Sebastian Reichel [this message]
2015-06-10 14:57   ` Frans Klaver
2015-06-10 14:57     ` Frans Klaver

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=20150610145205.GE11618@earth \
    --to=sre@kernel.org \
    --cc=dbaryshkov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=frans.klaver@xsens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@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 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.