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] [day] [month] [year] [list]
Date:	Wed, 10 Jun 2015 16:57:42 +0200
From:	Frans Klaver <frans.klaver@...ns.com>
To:	Sebastian Reichel <sre@...nel.org>
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 v3] sbs-battery: add option to always register battery

On Wed, Jun 10, 2015 at 04:52:05PM +0200, Sebastian Reichel wrote:
> 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.

Thanks.

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

Ouch, sorry about that.

Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ