linux-kernel - Re: [PATCH v2 5/6] MFD MAX8998/LP3974: Charger Support

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: <20101223023659.GC25886@opensource.wolfsonmicro.com>
Date:	Thu, 23 Dec 2010 02:36:59 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	MyungJoo Ham <myungjoo.ham@...sung.com>
Cc:	linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Lukasz Majewski <l.majewski@...sung.com>
Subject: Re: [PATCH v2 5/6] MFD MAX8998/LP3974: Charger Support

On Thu, Dec 23, 2010 at 11:10:41AM +0900, MyungJoo Ham wrote:
> On Wed, Dec 22, 2010 at 10:33 PM, Mark Brown
> > On Wed, Dec 22, 2010 at 03:23:10PM +0900, MyungJoo Ham wrote:

> > Normally I'd expect a battery charger to be exposed via the power supply
> > API - I'd at least expect to see a consumer in the power supply API

> The "CHARGER" regulator is to give the charger control to the user,
> which consists of switching (turn on/off) and current limit, which is
> what a current regulator does. On the contrary, when the charger
> control is implemented by power supply API, we do not have explicit
> control over such features (current limit and turn on/off).

Sure, like I say I'd just expect to see some power supply API visibility
- that could be a driver that provides the control that's needed to
userspace by controlling a current regulator, for example.

> Furthermore, a board may need to support multiple types of
> charger(USB, ACDC-5V-2A, ACDC-5V-1A, ...), which have various current
> limits. Thus, we need to adjust charger current limit out of PMIC
> driver unless the PMIC can detect every type of supported chargers,
> which MAX8998/LP3974 cannot.

Interesting system design - I've not seen that before.  With the system
designs I usually look at the current limiting from the wall/charger
supply is done on the primary system power rail which supplies both
thehcarger and the rest of the system (since the current drains from the
rest of the system also needs to be limited).  Similarly for the
temperature monitoring, I've usually seen that managed by hardware.

> That's why I have implemented charger in regulator framework. In the
> environment described above, the power supply consumer is going to be
> implemented over PMIC driver, USB/TA select driver (e.g., FSA9480),
> and Thermistor driver (e.g., NTC Thermistor). It appears that such a
> consumer driver is going to be a board or policy specification; (or
> full or callbacks that is going to be filled by a mach/board file)

I agree - it'd be a bit like the current GPIO power supply driver, I
think.  It'd probably also specify things like callbacks for voltage
monitoring via auxiliary ADCs in the PMIC or CPU.  My main point was
that it was surprising that the regulator driver for the charger didn't
come along with such a consuner driver, the split does make sense.
--
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/