linux-kernel - Re: [PATCH] sbs-battery: add option to always register battery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150602195036.GD13930@earth>
Date:	Tue, 2 Jun 2015 21:50:37 +0200
From:	Sebastian Reichel <sre@...nel.org>
To:	Frans Klaver <frans.klaver@...ns.com>
Cc:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sbs-battery: add option to always register battery

Hi,

On Tue, Jun 02, 2015 at 03:14:43PM +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. The current advice in this situation is to probe the device
> from userspace if you expect the battery to come on at some point in the
> future. The downside of this approach is that userspace needs to be
> aware of the backend of its powersupply, which is inconvenient and going
> against the point of hardware abstraction.
>
> In some of these cases you do want to register a battery, even if none
> are attached at the moment. To facilitate this, add a configuration
> option to try to talk to the device, defaulting to y, thus keeping the
> current behavior. If unset, the battery will always be registered
> without checking the sanity of the connection.

From my POV registering a power supply driver for an unconnected
chip is wrong.  It implies to the system, that there actually is
a battery connected.

Also how do you know, that a sbs based battery is connected at some
point and not some other battery (e.g. a bq27x00 based)? How does
the system know, that the battery becomes available?

Note, that userspace interaction does not mean missing hardware
abstraction. It means missing support for automatic device
identification. The same is true for serial connected bluetooth
devices.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)