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]
Date:	Thu, 15 May 2014 15:08:44 -0700
From:	"Mark A. Greer" <mgreer@...malcreek.com>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	linux-kernel@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Anton Vorontsov <anton@...msg.org>
Subject: Re: bq24190: What's the correct API to turn boost mode (OTG) on
 for the battery charger ?

On Thu, May 15, 2014 at 10:29:26PM +0200, Laurent Pinchart wrote:
> Hello,

[Adding Anton Vorontsov to CC list.]

Hi Laurent.

> I'm trying to enable battery charging on an OMAP4 board based on a twl6030 
> PMIC with external bq24190 battery charger and bq27510 fuel gauge.
> 
> The system has an OTG USB port that can be used to charge the battery, and 
> that can also be used in host mode. In that case the bq24190 needs to be 
> switched to boost mode to provide the +5V power supply from the battery.
> 
> The bq24190 has a charge configuration register field that supports charge 
> disabled, charge enabled and OTG (boost mode). The field is set by the bq24190 
> driver in response to setting the charge type : POWER_SUPPLY_CHARGE_TYPE_NONE 
> will disable charing, and POWER_SUPPLY_CHARGE_TYPE_TRICKLE and 
> POWER_SUPPLY_CHARGE_TYPE_FAST will enable it. However, OTG boost mode is not 
> supported.


> 
> The driver exposes most register fields as sysfs attributes (which doesn't 
> sound very safe to me, but that's another story). I can thus enable OTG boost 
> mode directly from userspace through the driver-specific API, but that just 
> bypasses the power supply API. I'm thus not very fond of that solution.

No, its not a good solution.  As indicated in the commit log, the sysfs
entries are there because there are just so many fields that don't map
well to the existing interface.

Maybe we should add support for a DT entry to enable exporting those
fields(disabled by default)?

> Possibly due to my really basic (not to say nonexistent) knowledge of the 
> power supply subsystem I haven't found an API to expose this feature. I was 
> wondering if someone had given a though regarding how to implement this 
> properly.

What if we just added something like POWER_SUPPLY_CHARGE_TYPE_BOOST?

Mark
--
--
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