linux-kernel - RE: [PATCH 2/4] power_supply: Introduce generic psy charging driver

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: <20ADAB092842284E95860F279283C56422FBE00C@BGSMSX104.gar.corp.intel.com>
Date:	Fri, 18 Jul 2014 03:38:33 +0000
From:	"Tc, Jenny" <jenny.tc@...el.com>
To:	Sebastian Reichel <sre@...nel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Dmitry Eremin-Solenikov" <dbaryshkov@...il.com>,
	Pavel Machek <pavel@....cz>,
	"Anton Vorontsov" <anton.vorontsov@...aro.org>,
	David Woodhouse <dwmw2@...radead.org>,
	David Cohen <david.a.cohen@...ux.intel.com>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>,
	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>
Subject: RE: [PATCH 2/4] power_supply: Introduce generic psy charging driver

> From: Sebastian Reichel [mailto:sre@...nel.org]
> Sent: Friday, July 18, 2014 7:49 AM
> To: Tc, Jenny
> Cc: linux-kernel@...r.kernel.org; Dmitry Eremin-Solenikov; Pavel Machek; Anton
> Vorontsov; David Woodhouse; David Cohen; Pallala, Ramakrishna;
> myungjoo.ham@...sung.com
> Subject: Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
> 
> Hi Jenny,
> 
> On Tue, Jul 08, 2014 at 11:34:19AM +0530, Jenny TC wrote:
> > The Power Supply charging driver connects multiple subsystems to do
> > charging in a generic way. The subsystems involves power_supply,
> > thermal and battery communication subsystems (1wire). With this the
> > charging is handled in a generic way.
> >
> > The driver makes use of different new features - Battery
> > Identification interfaces, pluggable charging algorithms, charger cable arbitrations
> etc.
> > The patch also introduces generic interface for charger cable notifications.
> > Charger cable events and capabilities can be notified using the
> > generic power_supply_notifier chain.
> >
> > Overall this driver removes the charging logic out of the charger chip
> > driver and the charger chip driver can just listen to the request from
> > the power supply charging driver to set the charger properties. This
> > can be implemented by exposing get_property and set property callbacks.
> 
> this seems to be a superset of charger-manager, which is already in the kernel. I
> would prefer not to have two different charger mangement frameworks in the kernel.
> 
> I suggest to add features supported by charger-manager to power supply charging
> driver and convert users of charger-manager to the improved driver.
> 
> I CC'd MyungJoo Ham, who wrote the charger-manager, so that he can also give
> feedback.

We are back to the initial discussions we had in the list. The initial proposal
was for the charger manager. The charger manager is more aligned to
regulator framework, use private notification
mechanisms(cm_notify_event,fullbatt_vchk etc) and relies more on
platform data (struct charger_desc). This doesn't seems to be good to support plug in
charger drivers, charging algorithms, battery identification drivers at runtime.
Power supply charger driver is introduced to meet all these requirements by
extending the existing power_supply subsystem features like
power_supply_changed event, power_supply_register, power supply thermal
throttling mechanism so that plugging new driver would be
easy. Also the user interfaces would remain the same as power_supply subsystem.

Able to locate link on the discussion. 
http://www.gossamer-threads.com/lists/linux/kernel/1562180.

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